Approaching software design principles

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!