Good Class, Method, Strut and Interface design centers around an understanding the Roles and the Responsibilities that the calling Method expects the Method to perform.

The calling Method passes, as Request objects, supporting Dependencies that it believes that the supporting Method call requires to deliver the Response it requires to carry out its work.

The Single Responsibility Principles states that a Class, Method, Strut or Interface should have to perform One and Only One Responsibility.

A Software Entity has the Responsibility

… To Manage One Responsibility

…… For all of its Changes in the Future

Software design and implementation is inherently complex. By nature any one component has many “Moving Parts”.

The Single Responsibility Principle states that the Software Entity should have a single, well-defined State or Behavior function.

Data Transfer Objects (DTOs), as State devices, should have collections of Properties that encapsulate a related group of data elements.

It should be clear the viewer, reading the Software Entity code, the “What” and the “How” of the underlying intent of the Software Entity.

SRP helps to manage complexities in the design by encapsulating the design into manageable entities that can be understood much faster and easier.

A Class, Method, Strut and Interface should be lean.

It should be small and easy to read and understand. The name should clearly define its responsibility.

There should not be any complicated logic within the Method being called by a Client Class Method.

Helper Methods, defined by their Single Responsibility, should be abstracted away from the parent class as Private Class Methods or Public Utility Helper Methods created as Reusable Dependencies within other Classes.

Here are the major signs of a Software Entity that has violated SRP:

1. A Vague or Ambiguous Name – If you cannot verbalize the responsibility from the name it may be in violation
2. Constructor or Method Parameters that are not Related to each Other – If there are a large number of parameters that clearly perform different tasks that is a violation of SRP
3. Numerous Regions or Comment Sections – Code should be self-defining. The need for separation by regions for anything other than Private Helper Methods and Private Classes are a clear sign of SRP violation
4. Large Classes – A Class is hundreds or thousands of lines of code almost always is a violation of SRP
5. Large Methods – A method that takes longer than five seconds to understand its intent is more than likely trying to perform Dependency Responsibilities within the Client called Method
6. Algorithms within the called Method – All Units of Work required by a called Class should be refactored into single responsibility Helper Methods. This abstracts the inner workings of the Dependency from the consuming Method. If the details change you do not involve the consumer of that change. This complies with the Open / Closed Principle.
7. An Interface that has Contract Signatures that are Unrelated – This violation is the worst of the SRP violations as it spawns, by its very existence, violations of the Single Responsibility Principle. It forces all implementing Classes or Struts to violate SRP

The Print SRP Violation

The Client had asked for a simple application to print some data from a text file to the computer screen for easy validation of its content.

The Original User Story:

As a Administrator of Documents

I want a quick and easy tool to verify the contents of a selected document on my computer screen

So that I know that I am about to process the correct document

The Original Solution:

The original solution had four responsibilities:

1. Retrieve the data from a selected file on a file server disk drive: An I/O operation
2. Format the data for display: Format for a computer screen
3. Select the output device:  A Console application display
4. Display the Retrieved Data (1) that is Formatted for a Computer Screen (2) from a Console Application(3) to the User’s Computer Screen(4)

The developer chose to create a single Console application class and provide three of requirements stated above in a method that was called by the “Main” method of the Console Application.

Functionally the Solution is Correct, it Worked Fine

… Until a Change Request was Created to Add the New Functionality!

The scope of the project has now changed and the Client wishes to add enhanced capabilities to the original deliverable.

The original code can not support the change. It must now be refactored into its discrete responsibilities so that it is extensible for the new requirements.

The New User Story:

As a Administrator of Documents

I want a quick and easy tool to verify the contents of a selected document on my computer screen and print the results to a printer, if required

So that I know that I am about to process the correct document and can work with a hard copy of the document

Console Display Class – The only root level class: The highest level of application abstraction

The Enums from the Enums Folder: Prevent the use of “Magic Strings”:

The State Data Transfer Object (DTOs) Classes from the ModelDTOs Folder: Encapsulates common state information:

The Behavior Object Classes from the Dependencies Folder: Encapsulates Single Responsibility behavior actions: