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?