Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
I try to think Single Responsibility Principle, a class should have only one reason to change.
If your change doesn't break this, then it can be a method, otherwise a new class.
Maybe this is where final programming comes in.... Writing so many single method interfaces would be a PITA...
@nibor hmm... So you create the new classes on refactoring?
But say we're starting from scratch? The main class is to generate a Report.
Top level: have get data, do calculations/fill in fields, output.
These are single responsibilities?
But then every field calculation/data source needed can also be single responsibilities?
Which means you would pass in all these smaller classes from the main class?
But they just makes the main class very big instead? Since it has to create all of them?
Step 1: Become contributor to major NPM package like FS or Request.
Step 2: Burn the entire world to the ground by pushing a single breaking change.
Step 3: ???
Step 4: Profit
@donuts if you are using a DI container, this should be handling the instantiation of the classes, you should be injecting the dependencies, preferably in the constructors. Also you wouldn't necessarily inject every dependency into the top level, you'd have a hierarchy of broken down responsibilities.
This guy's book on Dependency Injection helped me a lot, there are a lot of articles on his blog, there might be something useful in there. I'm not a java dev, so I'm not sure about spring, my experience has been using containers like unity in .Net and in Angular.