Asset 1EN.png

Cimpl Blog

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

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

Posted by Caroline Le Brun | November 15, 2012 9:28 AM


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

In the first part of this post we talked about being DRY so if you didn’t see it, I recommend that you take a few minutes and read it.

SOLID is an acronym of acronyms. It's better to show than trying to explain; take a look at the table below:                        

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                           

Those principles are themes that fill many books on coding. They represent studies of programing’s best practices on the OO (object oriented) world. I will try to be as brief and simple as possible, but I recommend that if you want to go deeper on the matter, it will give you an excellent framework to improve your coding.

The Single Responsibility Principle

“Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.”
That principle was introduced by Robert C. Martin in an article by the same name as part of his Principles of Object Oriented Design. It is based on the principles of “cohesion” and “separation of concerns”.

It basically says to put things that are related together and keep things that are not related to then elsewhere.

This is very important because every point of the application is a potential source of errors. The chances that a change to your code will need to be made at some point is high. Also, chances are that a correction or change will affect some of the functionalities that are more closely related to it. These changes become easier to manage when you define boundaries and a set of functions that can be reused in other parts of the software or even in other future developments.

Imagine a process to retreive a file

  1. open it
  2. read only the lines that have values
  3. sum the values
  4. display the result
  5. add a line with the total to the file
  6. saves the file

All of this can be done in a single method, in a single class. But if you read it closely you will identify 3 basic operations:

  1. Open, read and save the file (Date Read and Persistence)
  2. Sum the values (Business logic)
  3. Display the value (Interface)

If you write those groups of functions each in a separate class with atomic methods you will be able to maintain your code with greater efficiency. For instance, you can reuse the file manipulation code in other parts of your code. Or if the business logic changes (adding a percentage to the total for example), it will be easier to locate the point of change. Also, when dealing with bugs or corrections, it is easier to identify what is causing the problem.

In our sample above, lets says that the value is correct but is not being displayed in the correct format. In this case, you should target your display class to make the correction. You don’t need to look in the code of the big function where the display code is. And there is no reason to touch the other two classes that are working fine.

Again this is just a very simple example. Algorithms normally are far more complex than that. If you keep this principle in mind when projecting your system it will be easier to see code, reuse blocks, focus points of attention, and transform code into services or external libraries etc.

Open/Close Principle

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."

Bertrand Meyer is generally credited as having originated the term which appeared in his 1988 book Object Oriented Software Construction. Later in 1990 the concept were redefined to refer to the use of abstract interfaces.

Meyer said that once completed, the implementation of a class could only be modified to correct errors and that new or changed features would require that a different all together.

The redefined concept stated that those classes (the original and the new ones) should derive from an abstract interface that defines the functionality to allow it to polymorphically substituted for each other. In other words, once the implementation of a class is done, changing the behavior of a method in the class would often leads to breaking in the code and usually it is not easy to determine every possible break point.

You should protect the implementation of that functionality in that class to avoid problems. To change a behavior you should use another class that implements differently the same method and to guarantee that the method signature is the same an abstract interface is used.

An abstract interface is like a contract that says what are the formats of the input and the output of a method but has no implementation.

Apply now and be part of the team!

Let’s go back to our sample above. Imagine that we define the calculation class as bellow:

public class Sum {
	public double Calculate(IEnumerable values) {
		return values.Aggregate(0.0, (s, v) => s + v);

That class is correct. If when change its code we will have to verify every point where it is called in the application to search for possible errors. But If we write it like this:

public interface IBusinessLogic {
	double Calculate(IEnumerable values);
public class Sum : IBusinessLogic {
	public double Calculate(IEnumerable values) {
		return values.Aggregate(0.0, (s, v) => s + v);
Now to change the behavior of the method we just need to write the new class:
public class SumAndPercent : IBusinessLogic {
	public double Calculate(IEnumerable values) {
		return values.Aggregate(0.0, (s, v) => s + v) * 1.1;

The interface guarantees that the code is interchangeable between the two classes we just need to change the reference to an instance new class where the change is required. Again I am being very simplistic here just to illustrate the concept. Obviously the process is more complicated than that but even with more complicated scenarios that principle reduces the potential errors generated by a change.

In the next post I will continue to talk about the SOLID principles.

cimpl product evolution 2017


Continue to part 3

Topics: Acronyms, Programming

Written by Caroline Le Brun

Having worked in marketing for 16 years, Caroline has significantly improved Cimpl’s online presence and industry recognition as Marketing Director. Working closely with analysts and highly focused on keeping up with IT industry trends, she is most knowledgeable in the realm of technology and IT expense management best practices. As a passionate, driven marketer, she works side by side with her marketing team to bring Cimpl beyond its greatest achievements.

Follow Us!

New Call-to-action
Cimpl Helps Businesses Manage the Enterprise Digital Footprint

Subscribe to our Blog