OOP paradigm - Githubissues

I recently posted to a colleague that in nearly every "er" object case, there was a better name for it. And that giving it a better name would tend to make the design more encapsulated, less spaghetti code, in short more object oriented. It's not a hard and fast rule, but there are a lot of cases where it can improve things.
Take some sort of "Loader" for example. The focus here is on the unit of work it does. It'll have lots of instance variables, lots of arguments, and pass lots of data around probably. Now instead replace that with a LoadRecord and a LoadStream. I'm reasonably confident you'll end up with something that is more akin to what the original Founding Fathers of OOP had in mind.
We want to create objects that describe what they are, and then bind behaviour to them, rather than focus on what they do, and then figure out what data they'll need to do that.

In classic structured/programming, we concentrate on behaviour (verbs), and then figure out what data (nouns) we need to make it all work. In other words, we bind data to behaviour.

But in OOP, we make the locus of programs be the nouns, the data, and then we figure out what kind of behaviour we can bind to them, and hope that the problems we hope to solve gel out of the emergent behaviours.

Manager to probably one of these:
- Registry
- Log
- Factory
- NOTE: It is okay to have a Manager subclass of Person, who is the specialised person
Organizer to Organization
Analyzer to Analysis
Renderer to Rendering

I have always thought about inverting the problem by moving the locus to the property of a -er class
The property is mostly a noun
Turning a property into a class & then assembling behaviour when they arrive (due to a requirement) is a simple & effective way to code
- This is same as what has been told by above gurus
This has helped me to write clean code without burying myself into writing code that suits a design pattern

The next approach that I implement is writing unit tests.
I avoid the third party mock libraries
The moment I am stuck with writing a unit test it is an indication to improve the source code
The key is not to get obsessed with writing unit tests for 100% code coverage

AmitKumarDas / Decisions