World Library  
Flag as Inappropriate
Email this Article

Separation of concerns

Article Id: WHEBN0000234273
Reproduction Date:

Title: Separation of concerns  
Author: World Heritage Encyclopedia
Language: English
Subject: Service-orientation, Separation of presentation and content, MonoRail (software), Spring Roo, Component-based software engineering
Collection: Programming Principles, Reductionism
Publisher: World Heritage Encyclopedia

Separation of concerns

In computer science, separation of concerns (SoC) is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern. A concern is a set of information that affects the code of a computer program. A concern can be as general as the details of the hardware the code is being optimized for, or as specific as the name of a class to instantiate. A program that embodies SoC well is called a modular[1] program. Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. Encapsulation is a means of information hiding.[2] Layered designs in information systems are another embodiment of separation of concerns (e.g., presentation layer, business logic layer, data access layer, persistence layer).[3]

The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.


  • Implementation 1
  • Origin 2
  • Examples 3
    • Internet protocol stack 3.1
    • HTML, CSS, JavaScript 3.2
    • Subject-oriented programming 3.3
    • Aspect-oriented programming 3.4
    • Software build automation 3.5
    • Levels of analysis in artificial intelligence 3.6
    • Normalized Systems 3.7
    • SoC via partial classes 3.8
      • SoC via partial classes in C# 3.8.1
      • SoC via partial classes in Ruby 3.8.2
  • See also 4
  • References 5
  • External links 6


The mechanisms for modular or object-oriented programming that are provided by a programming language are mechanisms that allow developers to provide SoC.[4] For example, object-oriented programming languages such as C#, C++, Delphi, and Java can separate concerns into objects, and architectural design patterns like MVC or MVP can separate content from presentation and the data-processing (model) from content. Service-oriented design can separate concerns into services. Procedural programming languages such as C and Pascal can separate concerns into procedures or functions. Aspect-oriented programming languages can separate concerns into aspects and objects.

Separation of concerns is an important design principle in many other areas as well, such as urban planning, architecture and information design.[5] The goal is to more effectively understand, design, and manage complex interdependent systems, so that functions can be reused, optimized independently of other functions, and insulated from the potential failure of other functions.

Common examples include separating a space into rooms, so that activity in one room does not affect people in other rooms, and keeping the stove on one circuit and the lights on another, so that overload by the stove does not turn the lights off. The example with rooms shows encapsulation, where information inside one room, such as how messy it is, is not available to the other rooms, except through the interface, which is the door. The example with circuits demonstrates that activity inside one module, which is a circuit with consumers of electricity attached, does not affect activity in a different module, so each module is not concerned with what happens in the other.


The term separation of concerns was probably coined by Edsger W. Dijkstra in his 1974 paper "On the role of scientific thought".[6]

Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained —on the contrary!— by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.

Fifteen years later, it was evident the term Separation of Concerns was becoming an accepted idea. In 1989, Chris Reade wrote a book titled "Elements of Functional Programming"[7] that describes separation of concerns:

The programmer is having to do several things at the same time, namely, 1. describe what is to be computed; 2. organise the computation sequencing into small steps; 3. organise memory management during the computation.

Reade continues to say,

Ideally, the programmer should be able to concentrate on the first of the three tasks (describing what is to be computed) without being distracted by the other two, more administrative, tasks. Clearly, administration is important, but by separating it from the main task we are likely to get more reliable results and we can ease the programming problem by automating much of the administration. The separation of concerns has other advantages as well. For example, program proving becomes much more feasible when details of sequencing and memory management are absent from the program. Furthermore, descriptions of what is to be computed should be free of such detailed step-by-step descriptions of how to do it, if they are to be evaluated with different machine architectures. Sequences of small changes to a data object held in a store may be an inappropriate description of how to compute something when a highly parallel machine is being used with thousands of processors distributed throughout the machine and local rather than global storage facilities. Automating the administrative aspects means that the language implementor has to deal with them, but he/she has far more opportunity to make use of very different computation mechanisms with different machine architectures.


Internet protocol stack

Separation of concerns is crucial to the design of the Internet. In the Internet Protocol Suite, great efforts have been made to separate concerns into well-defined layers. This allows protocol designers to focus on the concerns in one layer, and ignore the other layers. The Application Layer protocol SMTP, for example, is concerned about all the details of conducting an email session over a reliable transport service (usually TCP), but not in the least concerned about how the transport service makes that service reliable. Similarly, TCP is not concerned about the routing of data packets, which is handled at the Internet Layer.

HTML, CSS, JavaScript

HyperText Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript (JS) are complementary languages used in the development of webpages and websites. HTML is mainly used for organization of webpage content, CSS is used for definition of content presentation style, and JS defines how the content interacts and behaves with the user. Historically, this was not the case though. Prior to the introduction of CSS, HTML performed both duties of defining semantics and style.

Subject-oriented programming

Multi-dimensional Separation of Concerns allows the analysis and composition of concerns to be manipulated as a multi-dimensional "matrix" in which each concern provides a dimension in which different points of choice are enumerated, with the cells of the matrix occupied by the appropriate software artifacts.

Aspect-oriented programming

Aspect-oriented programming allows cross-cutting concerns to be addressed as secondary concerns. For example, most programs require some form of security and logging. Security and logging are often secondary concerns, whereas the primary concern is often on accomplishing business goals. However, when designing a program, its security must be built into the design from the beginning instead of being treated as a secondary concern. Applying security afterwards often results in an insufficient security model that leaves too many gaps for future attacks.[8]

Software build automation

Most project organization tasks are seen as secondary tasks. For example, build automation is an approach to automating the process of compiling source code into binary code. The primary goals in build automation are reducing the risk of human error and saving time.

Levels of analysis in artificial intelligence

In cognitive science and artificial intelligence, it is common to refer to David Marr's levels of analysis. At any given time, a researcher may be focusing on (1) what some aspect of intelligence needs to compute, (2) what algorithm it employs, or (3) how that algorithm is implemented in hardware. This separation of concerns is similar to the interface/implementation distinction in software and hardware engineering.

Normalized Systems

In Normalized Systems separation of concerns is one of the four guiding principles. Adhering to this principle is one of the tools that helps reduce the combinatorial effects that, over time, get introduced in software that is being maintained. In Normalized Systems separation of concerns is actively supported by the tools.

SoC via partial classes

Separation of concerns can be implemented and enforced via partial classes.[9]

SoC via partial classes in C#

The following Bear class, written in C#, has different aspects implemented in different parts.

public partial class Bear
   private IEdible Hunt()
       // returns food...
public partial class Bear
   private int Eat(IEdible food)
       return food.Nutrition.Value;
public partial class Bear
   private int hunger;
   public void MonitorHunger()
        // Here we can refer to members of the other partial definitions
        if (hunger > 50)
            hunger -= this.Eat(this.Hunt());

For example, if we want to compile a version without support for hunger management (it could be a feature that costs extra for your customers), we simply remove the partial declaration in Bear_Hunger.cs.

Now, if a program also supported hunger management in other classes all those partial class definitions could go in a separate 'Hunger' directory. This is what is usually called multidimensional separation of concerns, and it helps programmers update the code and add new features, even the first time anyone started working with this code.

SoC via partial classes in Ruby

class Bear
  def hunt
    # TODO: return some food
 class Bear
   def eat( food )
     raise "#{food} is not edible!" unless food.respond_to? :nutrition_value
class Bear
  attr_accessor :hunger
  def monitor_hunger
    if @hunger > 50 then
      @hunger -= self.hunt )

See also


  1. ^ Laplante, Phillip (2007). What Every Engineer Should Know About Software Engineering. CRC Press.  
  2. ^ Mitchell, Dr. R. J. (1990). Managing Complexity in Software Engineering. IEE. p. 5.  
  3. ^ Microsoft Application Architecture Guide. Microsoft Press. 2009.  
  4. ^ Painter, Robert Richard. "Software Plans: Multi-Dimensional Fine-Grained Separation of Concerns". Penn State.  
  5. ^ Garofalo, Raffaele (2011). Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern. Microsoft Press. p. 18.  
  6. ^  
  7. ^  
  8. ^ Jess Nielsen (June 2006). "Building Secure Applications" (PDF). Retrieved 2012-02-08. 
  9. ^ Tiago Dias (October 2006). "Hyper/Net: MDSoC Support for .NET" (PDF). DSOA 2006. Retrieved 2007-09-25. 

External links

  • The Art of Separation of Concerns
  • Multi-Dimensional Separation of Concerns
  • Tutorial and Workshop on Aspect-Oriented Programming and Separation of Concerns
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.