For the MicroObjects style I have the driving principle of Represent the Concepts
Have a representation for every concept that exist in the code.
Which is great, but the thing about principles is that they don't tell you have to get there.
All of the practices are the hands on keyboard practices to strive towards this principle. I don't think we ever truely acheive it; but it something that helps guide decisions and helps make the code better.
There's a dozen hands on keyboard practices for MicroObjects... But what are the big ones?
In all the talks I do about MicroObjects; I hammer on "No Getters". I think it's the biggest concept. Mechanically, I think it has the biggest payoff... but it's... fuzzy? It's not clear... Well... None of the practices I promote are /clear/ or else they'd be standards I wouldn't feel the need to blog for 3 1/2 years on it.
What does it do to the code? Encapsulation? Another abstract term that doesn't really DO anything for us. Especially when Get/Set-ers are considered encapsulation.
This is why I've gone with "Represent the Concept". They all swirl around that idea.
I want smaller ones... Smaller targets we can aim for; and feel like we've gotten further.
No Getters... Or No Primitves?
One of the things I'm seeing more and more as I play with code; removing primitives is becoming the primary driver of extracting cohesion and having loose coupling.
The push to not have primitives forces behavior in the code. It forces refactorings that may not have been thought of before.
No Getters helps drive No Primitives. If we don't have primitives, what do we return? More objects... sure... but what do those objects return?... Without Primitives, we can't have getters as we typically use them.
This isn't saying "Getters are OK" - Gawd no. Bleh... Typing it leaves a bad taste in my mouth... It's a recognition that "No Getters" isn't the value. It's object representation. Getters are used (a lot) for either accessing primitives, or for objects in a DTO (such as deserialized JSON) which eventually leads to a primitive.
While I won't argue that's not a class... wait... no ... I will. It's not a class; it's a struct that isn't defined as a struct.
I won't argue that a DTO is a primitive... ... wait... No... I will. I'll argue that a DTO is a primitive on the same order of a List or a Map being a primitive. They aren't a concept of the system. They're simply containers. They don't have any functionality of the concept they /are/ in the system, because we didn't give the concept a representation /in/ the system.
A DTO is like a
string. It isn't a concept /in/ the system, it's data floating around the system. Important meta-data and desired behavior are ... not there. we have to know more and do more to use a DTO/Primitve than if we created the concept and used that.
I've said it in talks; and probably some earlier posts; I see LAYERS of abstraction vanish when concepts are properly represented. I normally use this as an example of the power of "No Getters", but it's also the power of "No Primitives". The example I have in mind was DTO's. All DTO's of classes, not primitive types. By moving the behavior of the manipulation into the DTO (no getters) we stopped it from being a Primitive in our system. It became the concept. It provided the functionality around the concept. Previously that "concept" was spread across at least 3 sets of classes. Maybe 5... It wasn't my code, and a while ago. I know that 3 layers of abstraction got deleted in the hour I sat with them.
Hundreds of lines of code... gone.
It was awesome.
I wonder what the direction things would look if I put my primary driver as "No Primitives"...
I still think that "No Getters" is the easiest to get people to do. It's mechanical... "No Primitives" is much more conceptual to refactor the code.
I enjoy helping others understand how to improve their code - I want to help them get to the conceptual level... Sometimes ya gotta go through the motions...
Shu - Ha - Ri
It's funny how often that comes up.
I'll be playing with this idea in my head. It's... Interesting. Not sure what applying the emphasis on "No Primtives" will be... I think I've kinda been doin that... pretty sure that's what I've actually transitioned to doing.
I'm doing it all as "Represent the Concept" but... I think the biggest emphasis has been on getting rid of Primitives. Haven't thought about it like that before. Maybe it's why the few primitives that do exist have rubbed me the wrong way; even though the concept is well represented.
I know that I go to the extreme as a way to prevent a slippery slope of "well, this time..." :)
It's giving me something to ponder while I play in code.