The Zen of Coding - Separation of Concerns

Continuing with my series on the Zen of coding, meta rules that apply universally regardless of coding language or style in use, today I want to discuss Separation of Concerns. 

Separation of Concerns is a design principle for partitioning a system into discrete logical elements. Each part of the system should focus on a single concern, which is not shared with other parts of the system. The term Separation of Concerns was probably coined by Dijkstra in 1974. This principle applies at all levels of a system, from the conceptual and logical models, down to the physical level. Again here, as with Magic Numbers, the benefit of following this design principle at the code level is more readable, and hence more maintainable code. 

Robert Martin's Single Responsibility Principal, is another wording of the same design principle. When you properly separate concerns each component, class, or module has a single responsibility.

If you don't follow the principle of Separation of Concerns over time you end up with a monolithic design, which are harder to read, harder to refactor, and harder to maintain. The answer is of course to refactor when you find there is no longer a separation of concerns. This is just one more refactoring pattern that you should be applying daily as part your work. It is part of the reason why refactoring needs to be part of the daily development cycle and not a separate story or event

Separation of concerns applies at all levels of the design from the details of the code, to classes, as well as to how the system is partitioned into executable modules.

Separation of concerns strongly relate to the concepts of Coupling and Cohesion. Coupling and Cohesion are concerned with the degree of dependency within and between modules. We should always minimize dependencies between modules (Coupling), and we should be looking for high inter-relationship of functionality within a module (Cohesion). Module may be a class construct or something higher level. Again here, Separation of Concerns is going to lead to low Coupling and High Cohesion by keeping single concerns focused together and separate ones independent.

Zen of Coding Rule: Always separate concerns. 

Happy Coding.

Previous posts in this series:

• The Zen of Coding - Magic Numbers

The Zen of Coding - Magic Numbers

I have been coding professionally now for over 30 years in a large variety of languages. There are a number of practices that I have found to be universally best practices regardless of the programming language or programming style in use. Many of these relate to how readable code is, which is the 2nd most important aspect of code, right behind correctly functioning code.

Readable code is more easily maintained, and I have yet to run into the app that I didn't need to revisit and update. In general, code is read an order of magnitude more often than it is written. It is one of the reasons why coding style guidelines are important if there is more than one author working on a project, either concurrently or across time. With the growth of open source and more companies using agile teams, it is rarer and rarer to be the sole author on a project. 

The Zen of coding are these meta rules that apply universally. Many of these items are noted in other places on the internet and in books. You can look at this as my list of favorite coding pet peeves to avoid. Let's, start with the first one magic numbers.

What is a magic number?

A magic number is a literal numeric value in code, outside of a assignment of that value to a named constant. For example 22/7 in the following code is a magic number.

float circularArea = radius * radius * 22/7;

Looking at this code, most people are not going to know what 22/7 is. A better way to write the code would be

float circularArea = radius * radius * Math.Pi;

Here we can use a predefined constant as opposed to defining one ourselves. Let's consider a program dealing with force and acceleration. When you find 9.8 sprinkled all over the code you might be able to deduce from the code that it is the value of gravitational acceleration. It would be much better to declare the constant and use the name of the constant everywhere else in the code. For example:

const float gravitationalAcceleration = 9.8;

Doing this not only increases the readability of the code, but also has the added benefit of increasing maintainability. When a more precise value for gravitational acceleration is needed, such as 9.80665, the code only needs to be changed in one place.

Some people have raised a concern that the extra assignment can affect performance. I have yet to run into the case where this is the case. I have gone so far as to prove this by looking at the compiled assembly language to prove it.

Zen of Coding Rule: Use constants whose name has semantic meaning instead of numeric literals. 

Happy Coding.