# Programming Fundamentals Part 5: Separation of Concerns  URL:: https://medium.com/@rkay301/programming-fundamentals-part-5-separation-of-concerns-software-architecture-f04a900a7c50 Author:: Ryan Kay ## Highlights > I found myself briefly wondering what the benefit of separating a continuous sidewalk into sections might be: > Supposing that a section was to become cracked or destroyed, one would only need to replace a single section to restore the sidewalk to its former shape and function > One could build each segment of the sidewalk in isolation of the others > the common thread in most of these architectures (although plenty of programmers contradicted this idea), was a separation of three kinds of code: > User Interface/View: Code which interacts with what the user sees, and can interact with > Logic: Code which handles events and coordinates the flow of data between various parts of the program > Data/Model: Code which is pri > In any case, I will now discuss the separation of concerns as applied to three different perspectives of software architecture: > Functions/Methods/Algorithms > Things/Classes/Objects > Modules/Components/Sub-systems/Packages > Separation of functions can be summarized by the following statement: Try not to write giant functions. > it is not that we have gotten rid of the ugly validation and evaluation logic; we have hidden the ugly stuff behind helper functions based on what that logic is concerned with. This allows solveBinomialExpression(…) to act as a control logic based function which delegates computational logic to helper functions. > Separation Of Things > The previous section took a more functionally based approach to solve that particular problem, but we can apply this same principle in a more object-oriented approach. > we have separated all of the conceptually different functions which we must perform, and created a class to encapsulate them. Each class is concerned with a particular operation, such as printing the result to the console (via println()), validation logic, evaluation logic, and our primary function still coordinates the flow of data between these different things. > The majority of programmers, unfortunately, do not observe separation of concerns: > At the level of Functions, they write Spaghetti Code > At the level of Things, they write God Classes/Objects > At the level of the entire architecture of their systems, they write Monoliths > This is regrettably the most common way of doing things, and the general rationale for doing so is that it can actually be really difficult to achieve separation of concerns and to build modular systems. > They are easier to read, which will save you and your team plenty of time which would otherwise be spent deciphering code which you wrote even days prior. > They are easier to modify, fix, and update, as you are working with individual units of code (we could be talking, functions, things, or modules); as opposed to continuous and amorphous blobs of code. Think back to my sidewalk analogy. > They are easier to test. > They actually are easier to design and build. This is perhaps the greatest irony: Some people actually think it is easier to build complex programs without any architecture (it makes sense if do not think about it). > Separation of concerns, which is the key to any good software architecture (whatever you choose to call it), is worth it, and I strongly encourage you to apply it as often as possible in your code bases. --- Title: Programming Fundamentals Part 5: Separation of Concerns Author: Ryan Kay Tags: readwise, articles date: 2024-01-30 --- # Programming Fundamentals Part 5: Separation of Concerns  URL:: https://medium.com/@rkay301/programming-fundamentals-part-5-separation-of-concerns-software-architecture-f04a900a7c50 Author:: Ryan Kay ## AI-Generated Summary None ## Highlights > I found myself briefly wondering what the benefit of separating a continuous sidewalk into sections might be: > Supposing that a section was to become cracked or destroyed, one would only need to replace a single section to restore the sidewalk to its former shape and function > One could build each segment of the sidewalk in isolation of the others > the common thread in most of these architectures (although plenty of programmers contradicted this idea), was a separation of three kinds of code: > User Interface/View: Code which interacts with what the user sees, and can interact with > Logic: Code which handles events and coordinates the flow of data between various parts of the program > Data/Model: Code which is pri > In any case, I will now discuss the separation of concerns as applied to three different perspectives of software architecture: > Functions/Methods/Algorithms > Things/Classes/Objects > Modules/Components/Sub-systems/Packages > Separation of functions can be summarized by the following statement: Try not to write giant functions. > it is not that we have gotten rid of the ugly validation and evaluation logic; we have hidden the ugly stuff behind helper functions based on what that logic is concerned with. This allows solveBinomialExpression(…) to act as a control logic based function which delegates computational logic to helper functions. > Separation Of Things > The previous section took a more functionally based approach to solve that particular problem, but we can apply this same principle in a more object-oriented approach. > we have separated all of the conceptually different functions which we must perform, and created a class to encapsulate them. Each class is concerned with a particular operation, such as printing the result to the console (via println()), validation logic, evaluation logic, and our primary function still coordinates the flow of data between these different things. > The majority of programmers, unfortunately, do not observe separation of concerns: > At the level of Functions, they write Spaghetti Code > At the level of Things, they write God Classes/Objects > At the level of the entire architecture of their systems, they write Monoliths > This is regrettably the most common way of doing things, and the general rationale for doing so is that it can actually be really difficult to achieve separation of concerns and to build modular systems. > They are easier to read, which will save you and your team plenty of time which would otherwise be spent deciphering code which you wrote even days prior. > They are easier to modify, fix, and update, as you are working with individual units of code (we could be talking, functions, things, or modules); as opposed to continuous and amorphous blobs of code. Think back to my sidewalk analogy. > They are easier to test. > They actually are easier to design and build. This is perhaps the greatest irony: Some people actually think it is easier to build complex programs without any architecture (it makes sense if do not think about it). > Separation of concerns, which is the key to any good software architecture (whatever you choose to call it), is worth it, and I strongly encourage you to apply it as often as possible in your code bases.