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.

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.

A Singleton takes itself care of  t’s instantiation and life cycle. Because the constructor is not public, it is not possible to create an object outside of the class.
Therefore it has a static method (i.e. getInstance) as global access point. It has also a private static attribute of itself, that is only instantiated one time. This way the instance method returns always the same instance.

When or why could you apply this Design Patterns?
A Singleton is used, when you want to make sure, that there’s only one Instance of a class.

For example you have a class that communicates with a serial port (COM). A serial port can only be opened once a a time. That means you can only have on Instance of the class that’s controlling the port.

It’s also used for database or API-access classes to prevent multiple connections or instantiations of the external libraries. Logging, caching or configuration are also possible candidates.

That sounds fine, but what’s the catch?
First of all: It uses a global variable. And as we all learned the hard way, global variables can make the behavior of your code unpredictable. Global state can lead to complex problems, as it can be modified anywhere in your code.

Also this violates the Single Responsibility Principle: “There should never be more than one reason for a class to change.” – Robert C. Martin
Instantiation is in my opinion a responsibility, and in medium or large scale code bases a critical.

Another drawback is tight coupling. Calling the singleton::getInstance() anywhere in your code couples it directly the singleton class.
Loose coupling is a good practice to develop maintainable and testable code.
Loose coupling and clear dependencies passed to new instances, for example by using constructor injection, allow the composition of reuse able modules at run time.

A class using the singleton is hard to test in isolation. And testing in general and also testing a module in isolation is essential for maintainable code.

To test a class which access the singleton in a method, you must find a way to replace the normally hidden instance with a stub, mock, etc.

To do this, the singleton class may have a public setInstanceForTesting method, which may not be a good idea.
Another possibility is creating a subclass with a static set method, that overrides the static instance variable (if it is protected).

The global state can also become a nightmare when testing your code. Tests fail and you have no idea why, or tests pass that should fail because the implementation is not complete yet.
You have to be careful when you test code using singletons, that the state of the previous test is removed.
If you don’t replace the singleton instance by dependency injection at least clear the static instance or reset it to an initial state – before and after every test run (setup / tearDown).

So is the Singleton really so bad, should i never, ever use it?
Probably no other design pattern is / was adopted, loved, discussed and hated as much as the singleton.

No piece of software is the same, and there may be situations when a singleton may be the way to go. See the further reading link collections for more details and example patterns.

But – you must consider all the drawbacks and weigh if it’s worth to live with them!

Further Reading

• Singleton Design Pattern, SourceMaking.com
• Test-Specific Subclass, XUnitPatterns.com
• Dependency Lookup, XUnitPatterns.com
• Null Object, SourceMaking.com
• Registry, MartinFowler.com