One of the big things with Object Oriented Programming is to "Encapsulate what Varies".
If it's something that can change between objects, we want to encapsulate that into a new object and use composition.
This is part of what I think drives MicroObjects. It's "pre?"-encapsulation of what varies. Even if it's not significantly varying, or doesn't vary, it's the recognition that it could.
Is this an early optimization? Maybe. I lean towards no. This is a 'optimization' that is easy to undo. Just inline the information and bam; encapsulation gone. Especially way it happens with MicroObjects.
I'm working through my PizzaShop OOP exercise, which you can find the videos of on my youtube.
As I'm doing this, and the inspiration for this post, is that I realized I'm encapsulating things that can vary. Not always things that DO vary.
Part of this is tied to an earlier post about why some aspect of inheritance bothered me. The variance is not part of the object, but a new object to vary. I lean very heavily towards Composition, not inheritance and my inclination to encapsulate shows that.
Abstract classes allow us to sorta encapsulate the variance in the derived classes. I'm saying to ACTUALLY encapsulate the variation and no need for the abstract class. Unless of course the derived classes become knowledge classes... which is almost always what happens when I actually put some refactor effort into my inheritance.
I don't have a big plan for this post... Just interesting working through the PizzaShop how much I feel like I'm able to identify the pieces that can readily vary and getting those into objects.
Maybe it's because I know the requiremetns coming... probably a bit of that. I try not to unless there's a clear need though. Creating objects for fun... ok... I kinda do that...
OK... yep... all I got. Just some quick thoughts around encapsulating things that vary.