Skip to content

Separation of Concerns (SoC)

Mehmet Özkaya edited this page Mar 25, 2019 · 2 revisions

SoC says that the elements in the software should be unique to them, not to share their responsibilities with other staff members. The necessity of separate responsibilities is the basic point that this principle underlines. While developing the software, the concepts we can call an boundaries “may be the clearest words that distinguish these responsibilities from one another. From the simplest, we distinguish between the concepts of layer and tier and certain responsibilities. If we enter a little more, the namespaces of our software components can also be used as limits to allocate responsibilities. The degree of adherence to the components within the software and the cohesion within the components are two important concepts for the SoC principle. It should always be preferred that the degree of commitment of the components is low and that the relationship of responsibility in a component is high. So low-coupling, high-cohesion is indispensable olac If the degree of commitment is low, then the control of the software will be easier in our hand, since the liability will be distributed per component. Being close to each other in their responsibilities within the components will reveal re-usability.

We can give an example of SoC that development of Web UI. As you can see that UI element i.e. button needs to configure by 3 structure; html - css - js.

Dcl2jTiWkAA0hnp

Clone this wiki locally