cimplBlog_banner.png

Cimpl Blog

Your Weekly Insights on How to Manage your Enterprise Digital Footprint.

Always try to be DRY and SOLID (Part 3)

Posted by Caroline Le Brun | December 12, 2012 9:30 AM

In the second part of this post I started talking about being SOLID so if you didn’t see it, I recommend that you take a few minutes and read it.

Just to recap here is the table that represents the SOLID acronym:

S

SRP

Single Responsibility Principle

O

OCP

Open/Close Principle

L

LSP

Liskov Substitution Principle

I

ISP

Interface Segregation Principle

D

DIP

Dependency Inversion Principle

We’ve already covered the first two. So let’s get going.

The Liskov Substitution Principle

“In a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may substitute objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).”

This principle was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled “Data Abstraction and Hierarchy”. It is a semantic principle rather than merely syntactic relation because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular.

It says that if an object X of type T has a property (or method) P that behaves in a defined way, the object Y of type S, where S is a subtype of T, should have the same property (or method) P behaving the same way.

Always try to be DRY and SOLIDThis principle is well aligned with the open/closed principle because it clearly states that a subtype cannot change the behavior of the original type (closed for changes) but you can use the subtype to extend the original type with new methods or properties (open for extensions).

 

 

*Please note that Etelesolv changed its company name to Cimpl in 2016.

Liskov’s principle imposes some standard requirements on signatures that have been adopted in newer object-oriented programming languages, like Contravariance, Covariance and Invariance (those concepts are out of the scope of this post but I strongly recommend reading about them). Liskov’s principle also is an excellent tool for the design of class hierarchies in a system.

The Interface Segregation Principle

“Many purpose specific interfaces are better than a general purpose one.”

This principle was first used and formulated by Robert C. Martin when doing some consulting for Xerox. The fact is mentioned in 2002 Robert’s book Agile Software Development: Principles, Patterns and Practices. Here is a short version of the history:

Xerox had created a new printer system that could perform a variety of tasks like stapling a set of printed papers and faxing. The software for this system was created from the ground up and performed its tasks successfully. As the software grew, making modification became more and more difficult so that even the smallest change would take hours to be applied.

The design problem was that one main Job class was used by almost all of the tasks. Anytime a print job or a stapling job had to be done, a call was made to some method in the Job class. This resulted in a huge or 'fat' class with multitudes of methods specific to a variety of different clients. Because of this design, a staple job would know about all the methods of the print job, even though there was no use for them.

The solution suggested by Martin is what is called the Interface Segregation Principle today. Applied to the Xerox software, a layer of interfaces between the Job class and all of its clients was added. Instead of having one large Job class, a Staple Job interface or a Print Job interface was created having only the methods relevant to that particular class. Therefore, one interface was created for each job, which were all implemented by the Job class.

Apply now and be part of the team!

That principle is well aligned with the Single Responsibility Principle and helps on the implementation of the Dependency Inversion Principle that we will mention later.

A class can implement multiple interfaces so we should use that capacity to use the interfaces to help shape the behavior by adding small interfaces with specific purposes.

A good sample is the IDisposable interface. It is an interface that defines classes that have to dispose of some resources and indicates the system that it can use the Dispose method to do so. It is very simple, has only one method and can be added to any class that has to have that behavior.

But adding that method on a higher level interface would require that classes that does not have to dispose of resources to also implement that method unnecessarily. That would obviously lead to new potential bugs and more points of attention in the code.

So keep your interfaces lean and with a specific behavior in mind.

The Dependency Inversion Principle

The principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

The dependency inversion principle was also postulated by Robert C. Martin and described in several publications including the paper Object Oriented Design Quality Metrics: an analysis of dependencies, an article appearing in the C++ Report in May 1996 entitled The Dependency Inversion Principle, and the books Agile Software Development, Principles, Patterns, and Practices, and Agile Principles, Patterns, and Practices in C#.

This principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details.

In conventional application architecture we have low level classes (LLCs) which implement basic and primary operations and high level classes (HLCs) which encapsulate complex logic and rely on the LLCs. A natural way of implementing such structures would be to write LLCs and once we have them to write the complex HLCs that directly depend on the behavior of those classes.

It makes it extremely hard to change or replace the LLCs since with the growth of the complexity of our system it becomes more and more dependent of them.

In order to avoid such problems we can introduce an abstraction layer (an interface) between the HLCs and LLCs. Therefore the HLCs use the interfaces to define its behavior and the LLCs are now responsible to implement that interface but are no longer called directly from the HLCs.

That principle is even more powerful if combined with other ones:

Using it with the Liskov’s principle you can guarantee that you can replace the LLCs by any other of their subclasses without breaking the behavior of you system.

Also, using it with the Interface Segregation Principle you can give flexibility to break the implementation of the interface (and therefore the behavior of the HLC) into smaller replaceable classes.

More Flexible and Less Dependencies

The DRY and SOLID principles are tools and practices designed to make your coding more flexible and with less dependencies. That leads to a code less prone to errors, with fewer points of potential bugs and easier to maintain.

They are not required and their use will depend of your experience in coding that the knowledge and sensibility to the system you are building.

See you next time.

 

Checklist

Related Articles:

Always try to be DRY and SOLID – Object-Oriented [OO] Programming Principles (Part 1)

Always try to be DRY and SOLID - Object-Oriented [OO] Programming Principles (Part 2)

Topics: Acronyms, Programming

Written by Caroline Le Brun

As a 16-year marketing veteran, Caroline’s experience extends across multiple industries. Since she joined Cimpl, her successful marketing campaigns have increased the company’s online and community presence, in addition to Cimpl’s footprint and appearances in new or traditional media (such as the Globe and Mail). Caroline is a specialist in communication and social media. She works closely with analysts to keep track of and adapt to the trends and changes in the industry of IT: Technology Expense management, IT cost optimization, Technology trends. Her leadership conducts Cimpl’s marketing team toward ever greater achievements. Caroline is also an exemplary citizen. Outside of work, she is involved in TEMIA, the Dorval Day Camp, and other community organizations. She has a Bachelor’s degree in Commerce from Concordia University and a Master Certificate in Integrated online Strategies from the University of San Francisco Intensive Development program.

Follow Us!

MonthlyExecutiveReportWebinar2
Self-Assessement_Checklist
Customer Stories: Access now!

Subscribe to our Blog