Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
A few days ago, I was talking to a Software Engineering PhD candidate and at some point she said to me:
Keep your classes and methods as small as possible
And I wonder if this is always a good practice.
I mean for example, is it worthy to have a class with only 2 attibutes in it? For instance, In some methods I need pairs of integers to work with. Should i write a "PairOfIntgers" class?
Could this way of thinking "break" the code in too many pieces?
There is a grain of truth in that advice, but IMHO it is not very well expressed, thus easy to misunderstand and/or to take to a stupid extreme. At any rate, this should be a rule of thumb, rather than hard law. And you should always imply in such rules the clause "within reasonable limits", or "but don't forget to use your common sense" :-)
The grain of truth is that in practice, classes and methods always tend to grow by nature, not shrink. A bug fix here, a little feature extension there, handling a special case over there... and voila, your once neat and small class starts to bloat. Over time, your code almost inevitably tends to become a monstrous mess of spaghetti - unless you actively fight this tendency via refactoring. Refactoring almost always produces many smaller classes / methods from a few big ones. But of course, there is a sensible limit to miniaturizing. The point of refactoring is not to have smaller classes and methods per se, but to make your code cleaner, easier to understand and maintain. At a certain point, making your methods / classes smaller starts to decrease readability, rather than increasing it. Aim towards that optimum. It is a blurry and moving target area, so you don't need to hit it spot on. Just improve the code a little whenever you notice some problem with it.
The more important issue to stress here is creating good abstractions. Small classes that are loosely coupled and have high cohesion are the product of good abstractions.
Sometimes it makes perfect sense to encapsulate two integers in a class. Especially if you want to have methods 'attached' to this class to also encapsulate how one can manipulate these attributes and to make sure you protect them from other parts of the program changing them.
Another positive to create a class in this case is that the class can evolve a lot better/nicer than let's say a lower level data structure like a Map or List can.
Third, a good abstraction can improve readability a great deal. Classes that adhere to SRP are usually a lot easier to understand by a human than classes that do not.
And just as a final note... no matter how good of a student you are... to understand OOP and good abstractions and when to use them, you need experience. You need to write bad code and go through the pain to maintain it. You need to see others write good code to build up your knowledge about what is 'good' and what will be a problem down the line... So do not beat yourself up if you just do not get it right away.
The God Object anti-pattern is what she was probably alluding to. I do tend to think that if I have an "and" in my class description, I should have two classes. If I have more than ten lines of code in a method/function, then I should break it up. As the pirate code, those are more guidelines than rules.
In object-oriented programming, the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. Usually you are doing more than one thing if your class gets too big. In your case the class is just a data class which holds data which is totaly ok. You shouldn't name the class PairOfInteger. What does the integers describe? Depending on your scenario a Tuple (like in C#) might be sufficient, too. And you may want to think about a strut instead of a class.
Try to hold you classes small. And methods even smaller. Maybe 10 Lines?!? Currently I'm trying to use flow design and event based components which seems to help to hold classes small. First I was worried to get to many classes but it really works!!! http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/20/flow-design-cheat-sheet-ndash-part-ii-translation.aspx
Make things as simple as possible, but not simpler. That's the rule I try to go by. Sometimes, it actually makes sense for a class to do what strictly speaking amounts to more than one thing, if those things are related on some common theme. Look at .NET; there are tons of classes that implement a large number of interfaces, each with its own list of required members. A method might end up needing to become somewhat long if it does something complex with a number of intermediate steps which are all interconnected and thus don't lend themselves very well to further refactoring. (Refactoring to keep methods short should ultimately be about readability and maintainability; if the long method is more readable and/or maintainable than a short one, all else equal, I will take the long one any day.)
To only "make classes and methods as small as possible" is, in my opinion, misguided. The real challenge is, as @c_maker points out, to provide good abstractions. Your example of grouping two numbers together is great, for example, if you are working on an implementation of complex numbers arithmetic, or if on a Unix system you need to refer to a user/group context. It makes very little sense if the numbers represent, say, an invoice ID and a product ID to be added to that invoice.
That is OK advice, but it needs to be implemented somewhat intelligently. Definitely don't follow it blindly.
When I look at my code I know if a method is too big. If it is doing too much, and would be too hard to read, then it is refactor time.
Here's a good example: you have a loop, and you have maybe 60 lines of code in that method. In that case, it is probably time to refactor because you are likely doing too much in that method.
But, it isn't a hard and fast rule. It's only something you get to learn by doing. And, other developers you are working with my not always agree and may call you out in a code review or whatever.
Uncle Bob says you should refactor/split/extract your methods until it is impossible to make them smaller. This usually ends in having several methods with 3 or 4 lines each. When you get too many methods, you have to make more classes.
If you try to follow SRP and one level of abstraction per method, these rules serve you well. At least they serve me well. Aiming for "as small as possible" gives me reasonable small methods, as I usually fall short the aim.
And it's always easier to understand smaller classes. Go ahead, read "Clean Code"
"As small as possible, but no smaller."– StuperUser Dec 15 '11 at 14:30