The other day a dear colleague asked me where I got my software modelling ideas from, and that led me to think about how I worked on system design principles. I learned a lot about my own process, and would like to share with you.
You see, I've always had an "always be learning" approach to software development, and the way I usually do it is that I try to impose myself some constraints in order to exercise some principle, and to force myself to learn thinking in different ways.
Otherwise I would always be tempted to go the way I’m more used to, and I think it would really slow down my learning curve.
I will share some examples of how that works for me, I’m pretty sure I didn’t invent it, but I hope you might find it useful.
The "composition over inheritance" case
One example is the "favor composition over inheritance" principle. I was pretty happy with my abstract classes and inherited methods, so why would that be attractive? I wanted to find out, so I put in place a constraint not to use any kind of inheritance anymore, even in cases where I thought it could make sense.
After some very awkward times where I had to think a lot to model requisites with composition that I could easily model with inheritance, the result was pretty awesome: I learned a very different way of structuring my code and saw clearly all the benefits of favouring composition over inheritance.
Today I’m a lot faster at designing with that principle in mind, and actually I haven’t felt the need for inheritance in a while.
The “immutability” principle
The same was true for immutable objects. After reading about it and playing with it for a while, I decided to focus on it, and since then all my objects “have” to be immutable.
Since I got used to this principle, immutability comes very naturally to me, and I the benefits are so great I just don’t use setters at all anymore (except in DTOs for parsing libraries compatibility).
The code is far easier to debug and to implement new features, as I don’t have to keep in mind the code parts in which a object’s state changes... It just doesn’t!
The point being that it started as a constraint, and evolved into a new way for me of thinking and designing software.
The "let's wrap it up and keep it short" momentum
This approach has helped me a lot in my journey as a developer, and has made work never boring.
What about you, how do you keep learning software development principles? Have you ever used such a constraints-based approach? Let us know in the comments!
Top comments (5)
I can't support composition >> inheritance enough. From my experience it's such a classic error in OO programming, as junior and even intermediate devs keep thinking that inheritance is the default way to add reusability and encapsulation. And the worst part is I remember when I thought the same!
Especially as I've moved to a more TDD and CI approach I've found this principle to be one of the most important to writing quality, maintainable code.
Thanks for writing this, and I hope others can learn from it now instead of waiting for their own mistakes...
Thanks a lot for your input Simon! I think of this principle as the common case where something used to be an acceptable solution, but since then evolved into a bad design practice...
With composition you get rid of the "hidden magic" inheritance provides, and oh, does it make life better!
Perhaps I'll write a post exclusively about this principle sometime soon...
Thanks again for sharing!
I'm really glad you enjoyed it, thank you!
Would be good to see some examples if poss
Sure, I’ll be working on that soon! Thanks for your interest!