{"id":4917,"date":"2018-11-14T23:01:04","date_gmt":"2018-11-14T22:01:04","guid":{"rendered":"https:\/\/monodes.com\/predaelli\/?p=4917"},"modified":"2018-11-14T15:20:05","modified_gmt":"2018-11-14T14:20:05","slug":"single-responsibility-principle","status":"publish","type":"post","link":"https:\/\/monodes.com\/predaelli\/2018\/11\/14\/single-responsibility-principle\/","title":{"rendered":"Single Responsibility Principle"},"content":{"rendered":"

Writing Flexible Code with the Single Responsibility Principle<\/a><\/em><\/h1>\n

Mhmhmm… where have I heard of that SOLID principle? Ah, Eiffel!<\/p>\n

<\/p>\n

\n
\n
\n
\n
\n
\n
\"Go<\/p>\n
<\/div>\n<\/div>\n<\/div>\n
\n
Severin Perez<\/a><\/div>\n
Writer | Developer | Information Specialist<\/div>\n
\n
\n
\n
\n

Writing Flexible Code with the Single Responsibility Principle<\/h1>\n

SOLID Principles and Maintainable Code<\/h2>\n<\/div>\n
\n
\n
\n
<\/div>\n
<\/div>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n<\/div>\n
\n
\n
\n
\n
\n
<\/div>\n<\/div>
Photo by NASA<\/a> on Unsplash<\/a><\/figcaption><\/figure>\n<\/div>\n
\n

If<\/span> you\u2019ve been around software for a while, then you\u2019ve almost certainly heard of the SOLID principles. In short, these are a set of principles intended to help developers write clean, well-structured, and easily-maintainable code. In software, as in any intellectual and creative endeavor, there is quite a bit of debate about the \u201cright\u201d way to do things. Different practitioners have different ideas about what is \u201cright\u201d, depending on their individual experiences and inclinations. However, the ideas prescribed by SOLID adherents have been widely adopted in the software community, and agree with them or not, they\u2019re a useful set of principles from which to draw best practices. Moreover, SOLID has been thoroughly integrated into a broader set of Agile development practices and understanding them is thus a virtual requirement in the modern software industry.<\/p>\n

Developers and bloggers have written seemingly ad infinitum about SOLID in various places across the web. In researching this article, I encountered many such resources, some of which are cited at the bottom of this article for your reference. So, if the SOLID principles are well-covered elsewhere, why write yet another article about them? In short, for my own edification. Writing about complex topics is one of the best ways to learn them yourself. And for that reason, I am planning a series of five articles\u200a\u2014\u200aone on each of the SOLID principles. What follows is the first such article and focuses on the single responsibility principle<\/em>. Although I don\u2019t expect my addition to the corpus on this topic will be particularly unique, I hope that it will prove useful to some readers. And with that, let\u2019s dive in.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

A Quick Refresher on SOLID<\/strong><\/h4>\n

SOLID is an acronym for a set of five software development principles, which if followed, are intended to help developers create flexible and clean code. The five principles are:<\/p>\n

    \n
  1. The S<\/strong>ingle Responsibility Principle\u200a\u2014\u200aClasses should have a single responsibility and thus only a single reason to change.<\/li>\n
  2. The O<\/strong>pen\/Closed Principle<\/a>\u200a\u2014\u200aClasses and other entities should be open for extension but closed for modification.<\/li>\n
  3. The L<\/strong>iskov Substitution Principle\u200a<\/a>\u2014\u200aObjects should be replaceable by their subtypes.<\/li>\n
  4. The I<\/strong>nterface Segregation Principle<\/a>\u200a\u2014\u200aInterfaces should be client specific rather than general.<\/li>\n
  5. The D<\/strong>ependency Inversion Principle<\/a>\u200a\u2014\u200aDepend on abstractions rather than concretions.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/section>\n
    \n
    \n
    \n<\/div>\n
    \n
    \n

    The Single Responsibility Principle<\/strong><\/h4>\n

    The single responsibility principle (SRP) states that every class or module in a program should have responsibility for just a single piece of that program\u2019s functionality. Further, the elements of that responsibility should be encapsulated by the responsible class rather than spread out in unrelated classes. The developer and chief evangelist of the SRP, Robert C. Martin, describes a responsibility as a \u201creason to change.\u201d So, another way of putting the SRP is to say, as Martin does, that \u201ca class should have only one reason to change.<\/span>\u201d<\/p>\n

    Before going any further it\u2019s worth taking a look at the history of the SRP. Martin originally introduced the term in as part of his Principles of Object Oriented Design<\/em> [1]. According to Martin, the SRP has origins in Tom Demarco\u2019s idea of cohesion<\/em>, which describes the extent to which elements in a given class\/module are related and relevant to one another. Furthermore, it builds on David Parnas\u2019 description of encapsulation<\/em>, or information hiding<\/em>, which says that attributes and behavior relevant to a given object should be bundled together and hidden from outside access [2]. Taken together, these ideas lead naturally to the principle that a given piece of software functionality (aka, a responsibility) should be bundled into a single class and hidden from other elements of the program\u200a\u2014\u200aexposing only those pieces necessary to the functionality of the program as a whole.<\/p>\n

    On its face, this seems relatively straightforward. Individual pieces of a program\u2019s functionality should be distributed to distinct entities that are capable of handling them without outside assistance. But how do you define an \u201cindividual piece\u201d of a program? What, exactly, is a \u201cresponsibility\u201d and how do you reason about it from a business perspective? Martin, popularly known as \u201cUncle Bob,\u201d clarified just this concern in a 2014 blog article where he tied \u201cresponsibility\u201d to the idea of interested actors [3]. Martin\u2019s article is well worth a read, but to summarize, he argues that if a piece of software has several different kinds of users (aka, actors), then the disparate interests of each of those users defines a piece of that software\u2019s responsibilities. Martin uses the example of C-Suite executives (COO, CTO, CFO), each of whom uses some piece of business software for different reasons. Moreover, when considering how software should be changed, each of those actors should be able to dictate changes in the software without affecting the interests of the other actors.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

    \n
    \n
    \n<\/div>\n
    \n
    \n

    The \u201cGod Object\u201d<\/strong><\/h4>\n

    Per usual, probably the best way to learn about the SRP is to see it in action. But to do that, we should perhaps first see what a program looks like when it does not<\/em> adhere to the SRP. Let\u2019s take a look at a simple program and see if we can break down its responsibilities. What follows is a brief Ruby program that outlines a class that describes the behaviors and attributes of space stations. Read through it and see if you can identify: a) the various responsibilities of objects instantiated by the SpaceStation class; and, b) the types of actors who might have an interest in an a space station\u2019s activities.<\/p>\n

    \n
    \n
    <\/div>\n
    <\/div>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n
    \n
    \n
    \n
    \n
    \n
    \n