1. Create a Single Interface for the Fat Class – Using the IDE tool or a tool such as ReSharper extract all of the Method Signatures into a Single Interface
2. Implement the Interface in the Fat Class – The implementation, with a good compile, will validate that the Fat Interface is correct
3. Create All Single Responsibility Interfaces – Group the Contract Signatures into related responsibility groups as Segregated Interfaces
4. Replace the Single Interface with the New Interface Collection – String all of the Interfaces as the replacement for the Fat Interface
5. Successfully Compile the Assembly – Verify that all of the Interface Contracts were migrated to the new Interface collection. Use the IDE, or a tool such as ReSharper, to confirm that each method is fulfilling a contract in its related Interface by inspecting the method signature lines for each method
6. Create a New Concrete Class that Implements Your Interface Responsibility – The new concrete becomes your solution to the problem. Place your new code into this class and use it as your code solution, not a new method in the violated Fat Class
7. Verify that All Usages function as Expected – Make sure that you have not introduced an bugs into the solution

The beauty of this solution is that as long as the Fat Class compiles with the Interface collection stringed together, no legacy code will break. You have created abstractions for all future developers to create new concretes as part of the solution, as you did.

You MUST document your changes … Into a Developer Common Knowledge Repository …… And pass the information Location to ALL Developers

Code review must not allow any future violations to this Class

It is possible to fix this class at this time if you have access to all assemblies that consume the methods. Create a separate Concrete Class for each Interface and point all usages to the new classes. Take the Fat Class out of the project and fix any compilation errors. Always comply with the Boy Scout Principle Always leave a Software Entity in Better Shape … Than it was in when you entered the Legacy Code Environment

The primary concept of ISP is to create Class and Struct contracts that comply with the Single Responsibility Principle (SRP) by defining only the signatures that the Class’s responsibility requires.

If an Interface Violates SRP

… Then ALL Implementations of that Interface

…… will be Forced to Violate SRP

An implementing Class should require that its abstraction only contract the concrete implementations that it knows it needs to support the responsibility of its Client method calls

One of the most expensive Code Smells in development is the violation of SRP through Fat Classes.

Fat classes are very hard to understand in a reasonable amount of time. They tend to be “Responsibility Repositories” that reside in “Filing Cabinet” code files.

They are generally the results of many developers working on code without a clear understanding of the overall intent of the code file.

The primary justification of ISP is to create a contract vehicle that forces a Class or Struct to comply with the Single Responsibility Principle by defining Software Entities that support a single purpose.

Compliance with ISP

… Forces the Implementing Class to Comply with SRP

The Interface Segregation Principle provides a “Bridge to Compliance”

for refactoring of violations within “Fat Classes”

1. Contract Entities that have no implementation or use within a Class or Struct
2. A variation violation is in Class Inheritance where a Base Class violates Liskov Substitution Principle and requires a derived class to have knowledge of Properties and Methods it does not require.

If a Class has to use a #region Tag to Hide Contracts … Then ISP has been Violated

1. Not Implemented Exceptions within a Method – Default implementation for IDE Interface compliance support
2. Empty Methods – Unused signatures.
3. The Use of #regions to Hide the Unimplemented Contracts – Reduction of Code Noise using Regions to hide the ISP violation.

This code example will demonstrate the “Fat Class” violation in our sample Print Data Console application.

The legacy code version will violate Single Responsibility Principle in the Console application by showing a class that has four responsibilities contracted to a “Fat Interface” that forces the class to violate SRP.

The Console Display Code:

The Fat Interface Code for the DataPrintingFatClass :

The Fat Class Code Implementing the Fat Interface IDataPrintingFatInterface :

 The Class Diagram for the Legacy Violation:

 The Console Display for the Legacy Violation:

This code is a simple example of a Class that is being used as a Class Method “Filing Cabinet“.

The DataPrintingFatClass has four responsibilities that are being defined by the IDataPrintingFatInterface.

This forces the implementing Class to violate SRP 

The refactored version of the console application above with solve the violation by extracting an Interface from the “Fat Class” and creating Interfaces that have a Single Responsibility.

The “Fat Class” is then refactored into four single responsibility classes that implement the new single responsibility Interfaces.

The Console Display Code:

The Fat Interface Code refactored into Four Interfaces:

The four new classes that implement the ISP Interfaces:

The Class Diagram for the ISP compliance solution:

The console display for the compliant code base:

The refactored solution supports SRP and ISP. It is also extensible through its interfaces.