Software design myths

If a software product is to be further developed over a longer period of time, the Costs increase with increasing complexity often one of the most important constraints. Various software design practices and principles that are intended to keep the costs of new functionality fairly constant help to manage complexity.

Unfortunately, there are also Misunderstandings and myths around some of these design principles, often spread faster than the intended interpretation and can thereby make the complexity and cost problems even worse. By taking a closer look at the original sources, these myths can be easily debunked.

Below I will introduce you to three of these principles and their most common myths.

DRY – Don't Repeat Yourself

This policy states that every piece of information or “knowledge” should have a single, unique representation. Especially in the code, but also, for example, in the documentation and in the automated tests.

The common misinterpretation, which is quite understandable based on the name alone: ​​Each piece of code can only exist once - even if it occurs in different parts of the code that shouldn't know anything about each other. Anyone who only knows this incorrect interpretation should forget it as quickly as possible, because it leads to increased coupling (coupling) in the program code. This not only makes changes more complex, but also makes it easier for errors to occur.

Single Responsibility Principle (SRP)

This principle is probably the most misunderstood of all known SOLID Principles. According to the author Robert C. Martin, who formulated the principle, it is probably due to the inappropriate name: Many software developers interpret this as meaning that every module or class only one thing supposed to do. There is also the principle that... every function should only do one thing, which has nothing to do with the SRP. On the contrary: one goal of the principle is cohesion, i.e. bringing together functionality that belongs together professionally or technically and is changed for the same group of (professional or technical) “users”. Anyone who separates related code based on this misunderstanding so that each class or module supposedly only “does one thing” achieves exactly the opposite - and violates several other principles in addition to the SRP. The “responsibility” does not lie in was a class does, but fur wen.

Open-Closed Principle (OCP)

The aim of this principle (the O in SOLID) is to allow new functionality to be added without having to adapt large amounts of existing code. The common mistake: “guessing” possible future functionality and making the code as flexible as possible in advance. Because of this Overengineering The code often becomes more difficult to understand, and much of this flexibility may never be needed. Instead, Robert C. Martin speaks of one strategic closure (“strategic shell”) certain parts of the code that comes through certain code changes should not be influenced. This keeps code changes local instead of propagating through the code base.

Conclusion

The whisper effect can often be observed in software design principles: information is lost, people add their own interpretations, and so misunderstandings often spread faster than correct information. That's why when you hear new principles, it's advisable to occasionally read the original source to check your understanding - for example, timeless classics like The Pragmatic Programmer. And as with any skill, software design requires sensitivity and a goal-oriented approach - blindly following subjective “principles” is rarely helpful. The best software designs are created through close collaboration in diverse teams.

Author 
Raimund Kramer

Advanced developers