Stupid or Solid?

This week, we read “From STUPID to Solid Code!” by William Durand. This article is packed with high-level do’s and dont’s of programming. The “dont’s” are condensed into the acronym STUPID and the “do’s” are represented by the acronym SOLID.

In the STUPID category, the article warns of tight coupling, especially. It notes in the conclusion that fixing this alone will improve your code immensely. I had never heard of this issue before reading the article. In a nutshell, loose coupling - reducing (and avoiding) dependencies between modules - is the better practice. You can test whether your program has tight coupling or not by whether changing one piece requires you to change any others. I read this article soon after working on our team’s first pull request. With that fresh in my mind, I recognized several of these principles (or lack thereof) in our chosen project. I abandoned one of the I claimed because, after digging into it, I found that dozens of components would need to be altered to alter a checkbox. This deterred me from working on the issue. Why would the project use tight coupling if it makes it hard to work on issues? After doing a bit of outside research, it seems the drawback of loose coupling (keeping components independent) is added complexity. Nonetheless, this is considered the best software engineering practice.

One of the standout principles in the SOLID category is the Liskov Substitution Principle. Dr. Bowring assigned an additional article on this principle. This principle requires subtypes to be substitutable for their base types. We all learned the “IS-A” idea within inheritance. This principle wants us to go beyond that and implement the “IS-SUBSTITUTABLE-FOR” relationship. The example provided by both articles is the rectangle-square relationship. A square is an ancestor of a rectangle. It’s easy to say a square is a rectangle “IS-A” square and let this object inherit from the square object. However, once we start implementing methods in the square class that force it to be a square - for example, if one dimension is changed, the other should be changed to match - we create issues in the code. This is why it’s more appropriate to say that “one object can be designed to inherit from another if it always has an “IS-SUBSTITUTABLE-FOR” relationship with the inherited object”.

The Liskov Substitution Principle caught my attention because the “IS-A” principle is something that’s always taught in introductory programming classes with inheritance. I can see how this would cause a lot of confusion about how classes should be designed to relate to and inherit from each other. In the long run, teaching this way can result in programmers who are more prone to writing bugged code.

One idea I didn’t quite understand is premature optimization. The author of “From STUPID to Solid Code!” warns of this and even goes so far as to call it the “root of all evil”. He argues that optimization makes code more complex and unreadable. According to him, even the best programmers should avoid it. This was a bit counterintuitive to me, but his reasoning around unreadability makes sense.

Some other principles within the STUPID and SOLID acronyms are givens within software engineering - using naming, avoiding duplication, etc. One pattern within the principles is their relation to how different parts of the program talk (or don’t talk) to each other. Best practice seems to keep classes as separate and as focused on a single responsibility as possible.

• 2021 11
• 2020 22