The concept is closely related to the Single Responsibility Principle introduced by Robert C. Martin in his principles of Object Oriented Design (butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod), which state that:

In this respect, concerns have a wider scope than responsibilities, typically influencing your application's design and architecture rather than individual classes or interfaces. Separation of concerns is essential in a graphical application to correctly detach your easily-tested logic from the presentation code, which manages user interaction.

By separating the concerns of an application, it is easier to test subcomponents and check the validity of our software without even needing to run the application. In doing so, we create more robust applications that can adapt to changes in requirements or technology over time. For example, the graphical toolkit that you choose for your application should not be incorporated into, or impact the design of, your business logic. Consider the GoMail examples that we built in previous chapters; we were able to use different toolkits to display our emails, but the code to manage accessing them was never changed. In this way, we kept the software open to change without a huge impact on unrelated areas.