Before your change it simply took a List<IndoorTemperatureSensor> and it had only one for loop. But look at this – feels like we’re missing something…..

Make it Open OCP conform

Suddenly you remember the open closed principle:

SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.

(The Open-Closed Principle, Robert C. Martin, The C++ Report)

That sounds odd, how can we build something that is closed for modification, but open for extension?

Abstraction is the key!

Because the AvgTemperatureReader is wired against the implementation “IndoorTemperatueSensor” we had to modify it to make work with our new outdoor sensor implementation.

The refactored solution uses an interface that provides access to the last read temperature. The abstract class removes code that would be duplicated in both sensor classes.

Look how simple the implementation of the AvgTemperatureReader looks like again:

conclusion

The OCP is in my opinion a key concept of object oriented design. Applied correctly it supports building software where changes don’t cascade through large parts of your codebase. This is not easy, but deep knowledge of the domain and can help to build in the necessary abstractions.

The full example is avaible in my GitHub repository.

That means: A derived class should by able to be replaced by another object of it’s base class without errors or modified behavior of the base class.

What’s the problem?

We tend to model the real world into classes. This is in general a good practice, but it has pitfalls.

Let’s look at an example: A square is an rectangle, so we model it as a subclass of rectangle, so we can handle a square like a rectangle and reuse it’s area property.

Ok, let’s have a look at the test’s:

Because we reuse the rectangle class for the square, it’s possible to set width and height separately. Square redefines the width and height setters to set both properties when one of them is changed. In the failing test we create a square with 5×5 by setting the width, and by setting the height we change it to 10×10. This is definitively a violation of the LSP.

How to make it lsp conform

As we’ve learned, rectangle and square are somehow related, but their (implementation) details are different. To encapsulate what varies and to provide a generic interface we introduce an abstract Shape class.

Both implementations have immutable properties and implement the abstract “Area” property get accessor. Because a square is only initialised with the side length, Area works always as expected.
This way we also could add additional shapes like a circle, which would be instantiated with a radius.

You find the full example project in my GitHub repository.

Conclusion

Inheritance can lead to very complex and hard to maintain code. Today we use inheritance rarely (Favour composition over inheritance), but when – we should have the LSP in mind.

I’ll explain this with an example, let’s assume we have an Interface SensorDevice that provides a lot of functions:

So what’s the problem with fat interfaces like in the example coding?

If clients use interface with methods they don’t need, they know details that they don’t care about.
In the sensor device example you will have code that controls maybe hundreds of different sensors and on the other hand there’ll be code that reads and handles the readings.
Device State, control and reading methods are tightly coupled togehter. If there’s a change in a method signature for example, all “clients” are eventually affected by the change – which is unnecessary.

Applying the interface segregation principle

To understand the ISP you must understand the difference between the (class-)interface and the object interface. Depending on the language a class can inherit from one or more classes and implement multiple interfaces

An object that implements multiple interfaces exposes all methods. But you also can access the object with the interface it implement, like IDisposable.
This allows a very specific access to a subset of the object interface, so that it can be treated in different ways without caring about its details.

Especially on higher levels of abstraction you will have objects with many methods, but you can group them using interfaces:

Now you can access the different methods by client-concern using the interfaces:

Console-Output
06.03.2016 07:17:37 ConsoleLogFakeSensor: enable()
06.03.2016 07:17:37 ConsoleLogFakeSensor: isEnabledSince()
06.03.2016 07:17:37 ConsoleLogFakeSensor: disable()
06.03.2016 07:17:37 ConsoleLogFakeSensor: powerOff()
Press any key to continue…


This will also be very handy if you want to disable dozens of different devices of different types using the generic interface “DeviceState” – without knowing which type of Device it is.

The example project is in this GitHub repository.

Conclusion

Splitting fat interfaces by client concerns is a powerful tool to build cohesive interfaces. Due to the reduced dependencies the scope of changes is minimised and the loose coupling will payoff in the long term when it comes to extending and maintaining the project. Smaller specific interfaces may also help to communication your intentions.

Sources

• Wikipedia / Interface Segregation Principle
• * Robert C. Martin, Agile Software Development – Principles Patterns and Practices, Pearson 2014

• “High level modules should not depend upon low level modules. Both should depend upon abstractions.”
• “Abstractions should not depend upon details. Details should depend upon abstractions.”

See Principles of Object Oriented Class Design by Robert C. Martin (2000) for further details.

An example Application
The application sends e-mail notifications to users. The message text is different for regular and premium users.
The “BL” sub-package contains the business logic, it knows how to generate the email (address, subject and message) and how to call the SMTP client.

This design is maybe the easiest possible way, but it has also disadvantages:

• Re-using the business logic is not possible because it’s internally wired directly to the STMPClient
• This also makes it hard to unit-test, the dependency is hidden in the implementation
• To replace the low-level STMPClient you have to change it’s depending class SMTPNotificationSender directly

That may not be a big deal in a small application like this example, but growing applications and changing requirements require flexible designs.

Refactor towards the dependency inversion principle
To solve the coupling problem we have to invert the dependencies: The business-logic provides an interface (abstraction), that is implemented in the low-level infrastructure package.

I moved the business-logic (core) and the infrastructure into separate class-libraries. As you see, the core library has no dependencies!

The “SMTPNotificationSender” is now called “NotificationService” and receives an instance of the interface SendMail by constructor-injection. This decouples it from the low-level E-Mail sending implementation and makes to business-logic easy to test.

The “Main” routine is now responsible for wiring up the classes at startup.

And finally here’s an example for 2 test-cases using Telerik’s JustMock:

You find the full project in my GitHub Repository and also a diff between the original and the refactored version.

Summary
The dependency inversion principle is very useful to build maintainable and testable code. The instantiation (wiring up the classes) is not cluttered all over the project. The actual implementation classes can be reused and easily replaced. A DI Framework / IoC Container wich I’ll explain in the next blog post can make this even easier.