Destruction of a large, cohesive class

I have a class that I think is too long. I really don't know what it means for too long, but it's about 2500 lines of code. However, all methods use at least one or more variables, so I think it's pretty cohesive. I am thinking about still breaking up this class into several smaller classes that would use three of the same variables. Is this a bad design or is it a pattern?

class MyClass { ... MyVar1 myVar1; MyVar2 myVar2; public void DoStuff() { ... MyPart1 myPart1 = new MyPart1(this,myVar1,myVar2); myPart1.DoStuff(); MyPart2 myPart2 = new MyPart2(this,myVar1,myVar2); myPart2.DoStuff(); } } 
+5
source share
3 answers

You cannot say that 2500 lines of code is too much for one class.

You can say that the class that is used for 10 different actions is pretty monolithic. Some people say that each class should have only one functionality. These people read "10" as binary ...

Now, if you don’t see the possibility of splitting your class in half, perhaps start by separating the smaller functional parts instead. This way you can get a better idea of ​​what is really important for the functionality of your classes.

Start by looking at your methods: if your class has several methods that basically relate to the same area (for example, XML-I / O or something like the Play / Pause / Stop / Reset function), you can create a subclass for them.
If all your methods are on the same level with each other (i.e., the opposite is higher), I would say that your class is not too big.

The most important thing, however, is that you do not lose orientation in your code. Try structuring your class and ordering your methods as it seems best. And do not forget to comment on this order so that you get into it again ...

+7
source

Think of “One Responsibility” (SR). I bet that a class with 2500 lines of code has at least 20 different things that can be easily divided.

First, all private methods typically represent a new SR class that awaits a break. Secondly, that a variable is used in many places does not mean that someone else (another class) cannot hold and process it. Thirdly, such a large class should be almost impossible to verify. Class SR is usually very simple.

So, the only thing I can recommend is to start cannibalizing your class of monsters and letting dozens of pretty little one-time wonders see the light of day :-)

Regards, Morten

+4
source

If the parts you share have an easily defined, reasonable single responsibility, I would not share it. If you can describe a subdivided class in only one line, and this line is not used to control var1 and var2, you can move on to something.

2,500 lines are not so big - sometimes it requires very clear and cohesive code.

Edit: There are some ways in which you might find that something is suspicious in the class.

  • If you repeat the same or very similar code several times in a class, you can account for the repeating part by making the class shorter (and probably more self-describing)
  • If there are clear sets of member functions that use a specific subset of variables and they don't overlap (i.e., member functions 1-10 use var1, member functions 2-20 use var2 and var3), you may have an implied double responsibility. Finding out what it is and separating it may not be easy, but at least you can figure out what to look at.
  • If some of the functions are minor variations for other functions, then the class interface may be too wide. Could you do the same thing as a member function by calling the other two member functions? If so, consider removing the redundant member function, maybe just document how to do this with the other more basic member functions.
+3
source

Source: https://habr.com/ru/post/987584/


All Articles