Street Coder: The rules to break and how to break them

by Sedat Kapanoglu

On SOLID principles There is a famous acronym, SOLID, that stands for five principles of object-oriented programming. The problem is that SOLID feels like it was invented to make a meaningful word rather than to make us better programmers. I don’t think all its principles carry the same importance, and some may not matter at all. I strongly oppose embracing a set of principles without being convinced of their value. The single-responsibility principle, the S of SOLID, says a class should be responsible for one thing only as opposed to one class doing multiple things, aka God classes. That’s a bit vague because it’s we who define what one thing entails. Can we say a class with two methods is still responsible for one thing anymore? Even a God class is responsible for one thing at a certain level: being a God class. I’d replace this with the clear-name principle: the name of a class should explain its function with as little vagueness as possible. If the name is too long or too vague, the class needs to be split into multiple classes. The open-closed principle states that a class should be open for extension but closed for modification. It means that we should design our classes so that their behavior can be modified externally. This is, again, very vague and can even be unnecessarily time consuming. Extensibility is a design decision and may not be desirable, practical, or even safe at times. It feels like the advice to “use the racing tires” of programming. I would instead...