OO - are large classes acceptable? [duplicate]

Question

This question already has answers here:

How would you know if you've written readable and easily maintainable code? [closed] (19 answers)

Closed 7 years ago.

Despite many years in IT, I still struggle with OO design. One particular problem I seem to keep ending up with is large classes, often containing many hundreds of lines of code.

The OO world talks a lot about SRP, and I could argue that these large classes I end up with are each handling a single responsibility. The complex nature of the app (a scientific data processing system) means that one of these responsibilities requires an awful lot of code! E.g. a class might have a single public method Calculate(), but there could be 15-20 or more private methods to support this operation.

Where possible I will extract methods into separate classes for re-usability, but often there is little or no scope for this. Part of me says I should split these large classes up purely to improve readibility (e.g. grouping similar methods into their own classes), but the times I've done this feels like a wasted exercise - all I've really done is spread the methods around, created more class dependencies, and made things a little more difficult for other devs to find stuff.

But then I read articles where developers talk about how all their classes are small enough to fit on the screen without scrolling, and I worry that I'm doing something wrong! In a previous job, I worked on a system where it had been OO'd to the extreme, and it was common to see classes containing just one method, often with no more than one or two lines of code. Personally I found this difficult to find my way around the code-base and to debug, and for this reason (and sheer number of classes) I could argue that it becomes more difficult to maintain - not the aim of good OO design. I guess it's down to personal taste.

So, is it acceptable to have large classes, or can you suggest other ways that I could deal with them?

Answer 1

have a single public method Calculate(), but there could be 15-20 or more private methods to support this operation.

That does not sound very "large" to me - as long as your 15-20 methods have a reasonable size. At least, not in general. However, to find out if your classes are reasonably-scoped, you will have to show them to another experienced developer and discuss it with him.

But then I read articles where developers talk about how all their classes are small enough to fit on the screen without scrolling, and I worry that I'm doing something wrong!

Don't worry: as long as your methods are small enough to fit on the screen. Okay, some people, including myself, think that's still too long. If you apply SRP and SLA ("single level of abstraction" principle, see, for example, here) to methods, they will typically become shorter than 20 lines.

The more important thing you should ask yourself is: do you suffer from maintainability problems? Do you often need days to find a specific bug because you have trouble isolating the problem due to the complexity of your code? If the answer is "yes", then your classes are probably too large. If the answer is "no", then don't worry about the size of your classes just because you "read some articles of some OO experts". Find our what works for your case.

Answer 2

Some classes are inevitably larger than others so this wouldn't immediately set any alarm bells ringing. However, you may wish look at your class design again if any of the following are true:

• You have a class that forms the whole (or large part of the) program
• There are large chunks of code within the class relating to a specific concern
• Similar code is present in other classes
• The same parameters with basic data types are being passed around from method to method e.g.

DoSomethingToThis(string name, int rating, datetime when, bool flag) {...}

DoSomethingToThat(string name, int rating, datetime when, bool flag) {...}

DoSomethingToTother(string name, int rating, datetime when, bool flag) {...}

Depending on your implementation language there may also be other ways of breaking up the code e.g. code regions and namespaces.

Answer 3

Do you write tests to maintain your code? If not, then you'll find your code will probably become much more atomic. However, I'd really focus on what 'Doc Brown' says regarding maintainibility. That's the key thing.

One large class with lots of small methods is probably easier to work with then lots of small classes each with one method. I've recently done a re-write at work taking one large God class of almost 9,000 lines of code and splitting it down. There are still classes that have almost a thousand lines of code in them. It sounds pretty dire when written down like that but at work we're finding it much easier to find and understand things. There are more classes now and more folders but it's tidier.

There is a gap between theory and practice. What looks and sounds right in theory, and usually demonstrated with a simple example, doesn't work when applied to a large real application.