Separation of Concerns
In programming, especially in professional development, there are certain ways that we can write code that enables a more efficient way of working on projects. One of these ways is understanding the separation of concerns. The main goal of separating your code by concerns is by giving each asset of code a single specific task.
Firstly, it would help to know what exactly a concern is. A concern at its most basic is anything that affects the code of a computer program. Our goal is to separate our concerns by giving each asset a specific job that will make it not only independent but also interchangeable. Think of this as a car that has many different parts that work by themselves yet also work with the whole. Let say your engine goes out. You naturally would get it fixed without interfering with other parts like your brakes or gear-shift. This is in essence how a program that is using a modeled using this principle should function.
One way we can do this is by implementing a modular design. A modular design is helpful as it effectively makes our code separated. This is achieved by putting or code into a module which is a group of code that can perform one specific task and be independent yet interchangeable. In modular designs, programmers should decompose their code to be simple enough to solve a single problem, one step at a time. There are many pros to this design such as :
- Cleaner code
- Easier debugging
- Increased reusability
- And a more effective workflow
Since modular programming and separation of concerns are abstract concepts, there are multiple ways to introduce these concepts to our code. A few ways to introduce modular programming are by following:
- The rule of three
- The D.RY. principle
- And the single responsibility principle
The rule of three is that if you need to use a section of code more than two times then that code should be refactored. This is important as this will counter duplication which isn’t necessarily bad, hence why we only want to refactor after using a section of code two times, and the benefit of refactoring is questionable if refactored too early.
The D.R.Y principle also known as don’t repeat yourself is the way programmers can reduce redundancy in code and make the modification of code easier. An example of this is pseudoclassical instantiation. In the code snippet, there is a car being made in the functional pattern and pseudoclassical pattern. The functional pattern would require more work to modify and to create new methods and objects whereas the instantiation by pseudoclassical patterns allows easy modification and declaration of new methods through the prototypial chain.
Lastly is the single responsibility principle which states that any blocks of code should be made to fit one problem, and bigger problems should be broken into smaller ones. This allows massive capabilities for reusability as one could effectively pick and choose which specific code sections they would like rather than having to re-write or modify existing code. Though this process can be lengthy, it is a tradeoff for more manageable code.
In conclusion, there are many ways to introduce modular coding to our code which helps in following the separation of concerns, which in turn can increase the efficiency of our code.
