Error Handling Pattern Using Interface Inheritance to Support Composition Inheritance

Composition Inheritance creates a “Has A” inheritance relationship by embedding dependent Entity Types within the functional type.

Composition over inheritance in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

An implementation of composition over inheritance typically begins with the creation of various interfaces representing the behaviors that the system must exhibit.

– Wikipedia

This advanced inheritance model eliminates the need for complex Class Inheritance schemas that tend to degrade over the life cycle of the application.

This generally happens due to change requests and feature/functionality updates.

When designing to Interface Abstractions rather than only the Concrete Class Compositions, the Interface Inheritance Model create a “Behaves Like” relationship to the Composition Classes “Has A” relationship.

This relationship compliments the overall decoupling state of the design that Composition and Interface Inheritance provides

Class Versus Interface Inheritance

The Class Diagram Using Class Inheritance for the Enterprise Messaging System:

The Class Inheritance Model Description:

The choice to implement Class Inheritance should be considered if the relationship between the Base Class and the Derived Class can support an “Is A” relationship. The Child Class must be an enhanced or variation version of the Parent Class.

The Derived Class must be substitutable for the Base Class without breaking the functionality from the substitution. This is the Liskov Substitution Principle (LSP)

The Inheritance structure of the Classic Enterprise Error Handling Pattern above violates the Behavior Versus State Principle as a Design Pattern.

By mixing state DTO, “ResponseCommon”, and the behavior method Class, “ErrorHandling”, to process the Errors and then deliver a common “ErrorInfo” DTO, as a list of Error Objects, as the return the “Is A” Relationship is violated.

You Cannot Substitute “ResponseCommon” for “MessageInfoResponse” …

… Nor Can You Substitute “ErrorHandling” for “ResponseCommon”

The desired Application functionality is achieved at the expense of LSP. This also creates a very messy inheritance structure that is hard to justify in Best Practice Object Oriented Programming (OOP).

The Class Diagram Using Interface Inheritance with Interface Method Extensions:

The Interface Inheritance Model Description:

The choice to implement Interface Inheritance removes the “Code Smell” associated with the requirement for State Objects and Behavior Objects within the Error Handling Design Pattern inheritance structure.

This design pattern uses an inheritance structure that creates a “Behaves Like” relationship between the Interface and the implementing Software Entities.

The Modern Developer’s Error Handling Design Pattern Can Extend this Error Handling Design Pattern to the Value Type: Struct.

A Struct is Restricted from Participating in Class Inheritance but it can Implement Interfaces.

The Design Pattern has Three Software Entities:

1. IErrorCommon – This Entity is the Interface Contract that the Consuming Response State DTO implements.

2. ErrorHandling– This Static Class contains all the Method Extensions for IErrorCommon within the Namespace: [AssemblyName].ErrorHandlingExtensions.

   This Namespace must be referenced in a ‘using’ statement within the implementing Response DTO for the extensions to be available for consumption.

3. ErrorInfo – This Class DTO State Object is the Strongly Typed POCO Object instantiated for each error in the Collection of Error Messages and Stack Trace Information. The “ErrorList” property in the Interface is a List<ErrorInfo>.

As with System.LINQ, which extends IEnumerable and IQueryable Interfaces, [AssemblyName].ErrorHandlingExtensions extends the IErrorCommon Interface

If you fail to bring in the ErrorHandlingExtensions namespace then the implementing Response DTO will be forced to implement the ErrorList property, List<ErrorInfo>, and the Boolean Success flag without any Method support for these Interface Signature Types. Obviously this eliminates the functionality of this design pattern.

 The ErrorHandlingExtensions Namespace adds the Extension Methods to the Implementing Response State DTO

The recommended usage of the Modern Developer’s Error Handling design pattern is to encapsulate it within its own “Infrastructure” Project Assembly.

It is a “Cross Cutting Concern” reusable Enterprise Component that supports all solution assemblies as a common module.

The Modern Developer’s Error Handling Design Pattern, using Interface Extensions, creates an Inheritance Model that complies with Best Practices for Object Oriented Programming.

By not creating a “False Is A” relationship between the implementing Response State DTO, as it would with a Class Inheritance model, the Modern Developer’s Error Handling Design Pattern maintains its Programming Inheritance Integrity.