What is separation of concerns? And why should you concern yourself with separation? Well, I am going to try to break this concept down a bit. Separation of concerns is the (really great) idea that each module in a computer program should deal with only one feature or behavior and should not contain code that deals with other things.
Realistically speaking, this makes total since. When working at your job, you are not expected to know every single thing about the company. Instead, you are solely responsible for your own role, the one you were hired for. In this way, it is easy to keep track of who is doing what to make the whole place run, right?
You can think of your code in the same way. If your entire project is stored in a single file, how easy would it be to find out what each function is doing? The answer is that it would not be easy at all. It's hard enough to catch spelling errors, but to figure out which part of this massive file is doing the thing that might not be working now? This could generate some (more than some) frustration.
The solution is to break down the application into smaller units of encapsulated functionality. You've probably done this already without realizing it. The most classic example of separation of concerns is having an HTML, CSS, and JavaScript file. These things all relate to each other, but often times having them all together in one file is clunky. It's so much easier divvying them up into their own files.
But that JavaScript file by itself can get pretty ridiculous in length once you start laying down the blueprints for your amazing app. That's where design patterns come in. A design pattern is just a way of separating these files, and you can choose Model View Controller, Model View Adapter, or Model-View-ViewModel, just to name a few. Which one is best to use? That depends on you!
Now, you might be thinking, "Why bother?" It's true that you can code away in a single file and get a fully functional app working. My point isn't really about functionality, though. This is more about organization, and what that means for the people you'll be working with, and the clients you'll be dealing with.
When working on an application with a team, wouldn't you be frustrated if they had everything just thrown together willy-nilly, and you had to figure out what's going on and what each part of the code is doing? Most likely. In fact, I think we can agree no one would appreciate this scenario.
A job in coding is complicated and stressful in its own right, there's no reason to make it harder for yourself. Let's think about this in a Model View Controller point of view for a second. 
If a user clicks a button on your app and nothing happens, we can pretty easily narrow down the problem, yes? A button a user can see and interact with in MVC is called a controller. So we can pretty confidently assume the button created in the controller file is where the problem is. The ease in which you can then debug the error is clear. And even if that wasn't where the problem was, following the trail from the controller to the view or to the model is just as simple. Staring at an all encompassing file to figure out where the button was defined and what it's supposed to be interacting with to make a change is in comparison, much less practical.
So, do this for your own sake, and in doing so, the sake of everyone you will ever work with. It's a great practice for efficient coding, and will help cut your work in half when it comes to making changes and debugging.
Top comments (0)