I'm often finding that my classes end up with many (10-15) dependencies being injected. I realise there is no hard and fast rule, but someone once told me that more than 4 or 5 can be a code smell. The classes themselves typically aren't that large, at least in my opinion (1000-1500 lines).

Such classes aren't your typical business logic class; instead each one handles a complex industrial process, orchestrating the control of various hardware components, reading data and saving this to file, and so on. Each of these processes is quite different from the last, and there is virtually no common functionality across these classes (beyond those dependencies that I'm already injecting in).

These classes often only have a couple of public methods, with the rest being private. Now, I could take one of these classes (ClassA) and move the private methods with similar/related functionality into a class of their own (ClassB), satisfying SRP. I can then inject ClassB into ClassA, reducing the number of ctr parameters (assuming some of these are only needed by the methods now in ClassB).

However registering ClassB with my DI framework doesn't feel right, as it will only ever be referenced by ClassA. I could instead instantiate ClassB from ClassA, but then I'm back to having many ctr parameters (although on the plus side, ClassA is smaller).

Another problem in doing this is that I have to make those once-private methods internal, so ClassA can call them.

Considering all these disadvantages, is it still advisable to split the class up?

  • 1
    What does your pragmatist self tell you about all this? Does satisfying SRP in the scenario you cited improve your software in any way, other than satisfying a principle? Also, note that SRP doesn't always mean what people think it means. SRP is a role, like a restaurant manager. A restaurant manager may do many things, but it is still a single role, that of managing a restaurant. – Robert Harvey Jun 27 at 14:43
  • Hey Andrew, I suggested an edit that should take care of the question being "too broad". – R. Schmitz Jun 27 at 16:25
  • 1
    Not a direct answer, but on a side note, classes of 1000-1500 lines do actually seem quite large to me. My classes are usually under 200 lines and just overall, there's no "too short to be a proper class". An extreme case is Kotlin, where you can write a perfectly sensible data class in literally 1 line. Like Robert Harvey already mentioned, the question is if SRP would actually improve your software. Making reasoning about the code easier because you only have to think about 500 lines at once instead of 1000 certainly is an improvement. – R. Schmitz Jun 27 at 16:47

However registering ClassB with my DI framework doesn't feel right, as it will only ever be referenced by ClassA.

That is fine. In fact it's typical. Code reuse is something you aspire to do. Not something you insist on achieving every time you create a class.

What you need is to do is focus the interfaces of what you ask to be handed to you solely on what you need. Push details and responsibilities away so that you are working on one idea at one level of abstraction. Do that and what you ask for shouldn't be that many things. If it still is you likely need to put something between you and those things that simplifies what you are saying you need.

If we're talking about data, a parameter object works to keep the argument count down. If we're talking about methods a facade pattern works as well.

Let your needs drive creation of things you can use to get the job done. Don't let what you happen to already have drive what you ask for. Ask for what you need. Even if it doesn't exist yet.

Not the answer you're looking for? Browse other questions tagged or ask your own question.