No Fear Legacy “Fat Class”  Refactoring

using S.O.L.I.D.’s Interface Segregation Principle (ISP) 

A Class Weight Loss Program

Brown Field code in Legacy Projects offers the Modern Developer the opportunity to add real value to the project for the Client.

Older Legacy Code rarely complies with the Design Principles, Design Patterns and Code Standards of the Modern Developer’s Manifesto.

The Modern Developer’s Boy Scout Principle States:

“The Modern Developer should always leave a Software Entity in better shape than it was in when they entered the Legacy Code environment”

This is Easier said than Done in most Environments

Most Brown Field projects may not have the benefits of Test Driven Development’s with its Unit and Integration tests for assembly components.

The Lack of Unit and Integration Tests

… Creates a ‘Culture of Fear of Refactoring’

Within the Maintenance Community

This fear inhibits a good developer from exercising the Boy Scout Principle for fear of “Breaking Code” that caused bugs that cannot be easily be regressively tested and validated.

The Biggest Object Offenders
are Fat Classes and Fat Methods

What is a Fat Class?

A Class Object is Fat if it Violates the
Single Responsibility Principle (SRP)

If a Class Object it trying to provide more than One Responsibility, for the Calling Client’s Method, then it is considered a Fat Class.

The developer should clearly define the Business Semantic in the naming of the Class Object and ensure that any dependencies are abstracted from the Class’s Responsibility.

This Does Not Mean the Class
Can Only Do One Thing!

What this means is that the class understands the difference between its Responsibility and its required Dependencies. 

The Responsibility and Dependency Principle
is used to support its Single Responsibility

What is a Fat Method

A Method is Fat if it
Violates the Single Responsibility Principle
Or the Open / Closed Principle

A Class Method has One Responsibility and that is to Service the Calling Class Method’s Request.

The Class Method consumes the parameters, as dependencies, to produce the calling method’s expected return results.

The Class Method does not have the responsibility to Create the Requirements to deliver the expected results: Just to deliver the expected results.

A Class Method that Complies with the
Single Responsibility Principle
Delegates its Dependency Responsibilities

Responsibility delegation is accomplished through Private Class Helper Methods or Public Utility Classes.

If a Dependency has a One and Only One Usage then it is encapsulated within a Class Helper Region.

An extracted refactored method is created with a Private Access Modifier.

This method is only available within the Current Class.

If the Dependency can be used in Two or More Classes it is refactored to a Common Utility Class as a Public Helper Method. 

The ISP Weight Loss Program

The Interface Segregation Principle states:

“Clients of Interfaces should not be forced
to Implement Interface Contracts
they do not require”

This principle is violated, in spirit, by every Fat Class.

These Fat Classes violate the Single Responsibility Principle even if Interfaces are implemented in the Class.

You use an IDE  tool, like ReSharper or Visual Studio, to create an Interface that represents all of the responsibilities currently in the Class.

The Fat Class then implements all of its Method Signature Contracts as a validation of the Fat Interface.

This Interface would Show the
Violations in Responsibilities

There would be many Interface Contracts that clearly are not related to the original intent of the Class Object.

The ISP Refactoring Trick

You really don’t really want to copy and propagate bad code and bad practices.

If you feel you need to add additional Code Smells to a Fat Class use the ISP Refactoring Trick.

You can use the IDE Extract Interface refactoring
as your Weight Reduction Tool

You will create an Interface that will be implemented in a New Class that consumes a copy of the related methods and other Software Entities within the “Fat Class”.

You code will Implement the Interface and you will build the contract’s concretes, as required.

The ISP Refactoring Trick

… Allows you to Comply with your Deliverable Request

…… Without Adding to the Current Code Smell

How the Class Weight Loss Program Works

The Class Weight Loss Program works using the ISP Refactoring Trick:

1. Open the Fat Class for Refactoring

2. Use ReSharper to create the Interface Abstractions

3. Organize the collection of contracts into separate Interfaces

4. Separate Interface contracts signatures into responsibilities

5. Create a new Interface file for each responsibility collection

   1. Add all the new Interfaces to the Fat Class

   2. Compile the Class

   3. Run the application / tests to validate normal functionality

At this point you have defined the
Single Responsibilities that the Fat Class
is providing to the calling Classes

You have two choices at this point:

1. Extract all the related dependencies into New Classes, implement the single Interface and fix all compile errors caused by the incorrect Namespace and Class Type pointers:

   Best Choice but can time-consuming in some situations

2. Extract just the dependencies you require into a New Class and implement the single Interface. Use this new Class as the Type for your new design solution:

   No regressive issues as legacy code uses the “Fat Class” and your code uses the new implementation requirements
   

Choice number two creates a bridge for future refactoring though the organization of related dependency signature contract Interfaces.

As new requirements require changes to the Fat Class then solution choice two can be implemented and validated during Code Review.

You have now Complied with the
Boy Scout Principle
as you have left the Environment
Better than when you Entered It

Compliance with the Interface Segregation Principle supports a lower Total Cost Of Ownership

Creating “Skinny” Classes and Methods
Reduces the Cost of Maintenance and the
Learning Curve of a New Developer and
that Developer May be You in Six Months

Wisdom Pearl #131: Don’t Propagate Bad Code

Be Part of the Solution … Not Part of the Problem

… Don’t add to a Fat Class … Use Interface Refactoring