Single Responsibility (SRP), Open/Closed (OCP), Liskov's Substitution, Interface Segregation, and Dependency Inversion. Five agile principles that should guide you every time you need to write code.

Definition

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

The Open/Closed Principle, OCP in short, is credited to Bertrand Mayer, a French programmer, who first published it in his book n Object-Oriented Software Construction in 1988.

The principle rose in popularity in the early 2000s when it became one of the SOLID principles defined by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices and later republished in the C# version of the book Agile Principles, Patterns, and Practices in C#.

What we are basically talking about here is to design our modules, classes and functions in a way that when a new functionality is needed, we should not modify our existing code but rather write new code that will be used by existing code. This sounds a little bit strange, especially if we are working in languages like Java, C, C++ or C# where it applies not only to the source code itself but to the binary also. We want to create new features in ways that will not require us to redeploy existing binaries, executables or DLLs.

OCP in the SOLID Context

As we progress with these tutorials, we can put each new principle in the context of the already discussed ones. We already discussed the Single Responsibility (SRP) that stated that a module should have only one reason to change. If we think about OCP and SRP, we can observe that they are complementary. Code specifically designed with SRP in mind will be close to OCP principles or easy to make it respect those principles. When we have code that has a single reason to change, introducing a new feature will create a secondary reason for that change. So both SRP and OCP would be violated. In the same way, if we have code that should only change when its main function changes and should remain unchanged when a new feature is added to it, thus respecting OCP, will mostly respect SRP also.

This does not mean that SRP always leads to OCP or vice versa, but in most cases if one of them is respected, achieving the second one is quite simple.

The Obvious Example of OCP Violation

From a purely technical point of view, the Open/Closed Principle is very simple. A simple relationship between two classes, like the one below violates the OCP.

The User class uses the Logic class directly. If we need to implement a second Logic class in a way that will allow us to use both the current one and the new one, the existing Logic class will need to be changed. User is directly tied to the implementation of Logic, there is no way for us to provide a new Logic without affecting the current one. And when we are talking about statically typed languages, it is very possible that the User class will also require changes. If we are talking about compiled languages, most certainly both the User executable and the Logic executable or dynamic library will require recompilation and redeployment to our clients, a process we want to avoid whenever possible.

Show Me the Code

Based only on the schema above, one can deduce that any class directly using another class would actually violate the Open/Closed Principle. And that is right, strictly speaking. I found it quite interesting to find the limits, the moment when you draw the line and decide that it is more difficult to respect OCP than modify existing code, or the architectural cost does not justify the cost of changing existing code.

Let's say we want to write a class that can provide progress as a percent for a file that is downloaded through our application. We will have two main classes, a Progress and a File, and I imagine we will want to use them like in the test below.

function testItCanGetTheProgressOfAFileAsAPercent() {
    	$file = new File();
    	$file->length = 200;
    	$file->sent = 100;
    
    	$progress = new Progress($file);
    
    	$this->assertEquals(50, $progress->getAsPercent());
    }

In this test we are a user of Progress. We want to obtain a value as a percent, regardless of the actual file size. We use File as the source of information for our Progress. A file has a length in bytes and a field called sent representing the amount of data sent to the one doing the download. We do not care about how these values are updated in the application. We can assume there is some magical logic doing it for us, so in a test we can set them explicitly.

class File {
    	public $length;
    	public $sent;
    }

The File class is just a simple data object containing the two fields. Of course in real life, it would probably contain other information and behavior also, like file name, path, relative path, current directory, type, permissions and so on.

class Progress {
    
    	private $file;
    
    	function __construct(File $file) {
    		$this->file = $file;
    	}
    
    	function getAsPercent() {
    		return $this->file->sent * 100 / $this->file->length;
    	}
    
    }

Progress is simply a class taking a File in its constructor. For clarity, we specified the type of the variable in the constructor's parameters. There is a single useful method on Progress, getAsPercent(), which will take the values sent and length from File and transform them into a percent. Simple, and it works.

Testing started at 5:39 PM ...
    PHPUnit 3.7.28 by Sebastian Bergmann.
    .
    Time: 15 ms, Memory: 2.50Mb
    OK (1 test, 1 assertion)

This code seems to be right, however it violates the Open/Closed Principle. But why? And How?

Changing Requirements

Every application that is expected to evolve in time will need new features. One new feature for our application could be to allow streaming of music, instead of just downloading files. File's length is represented in bytes, the music's duration in seconds. We want to offer a nice progress bar to our listeners, but can we reuse the one we already have?

No, we can not. Our progress is bound to File. It understands only files, even though it could be applied to music content also. But in order to do that we have to modify it, we have to make Progress know about Music and File. If our design would respect OCP, we would not need to touch File or Progress. We could just simply reuse the existing Progress and apply it to Music.

Solution 1: Take Advantage of the Dynamic Nature of PHP

Dynamically typed languages have the advantages of guessing the types of objects at runtime. This allows us to remove the typehint from Progress' constructor and the code will still work.

class Progress {
    
    	private $file;
    
    	function __construct($file) {
    		$this->file = $file;
    	}
    
    	function getAsPercent() {
    		return $this->file->sent * 100 / $this->file->length;
    	}
    
    }

Now we can throw anything at Progress. And by anything, I mean literally anything:

class Music {
    
    	public $length;
    	public $sent;
    
    	public $artist;
    	public $album;
    	public $releaseDate;
    
    	function getAlbumCoverFile() {
    		return 'Images/Covers/' . $this->artist . '/' . $this->album . '.png';
    	}
    }

And a Music class like the one above will work just fine. We can test it easily with a very similar test to File.

function testItCanGetTheProgressOfAMusicStreamAsAPercent() {
    	$music = new Music();
    	$music->length = 200;
    	$music->sent = 100;
    
    	$progress = new Progress($music);
    
    	$this->assertEquals(50, $progress->getAsPercent());
    }

So basically, any measurable content can be used with the Progress class. Maybe we should express this in code by changing the variable's name also:

class Progress {
    
    	private $measurableContent;
    
    	function __construct($measurableContent) {
    		$this->measurableContent = $measurableContent;
    	}
    
    	function getAsPercent() {
    		return $this->measurableContent->sent * 100 / $this->measurableContent->length;
    	}
    
    }

Good, but we have a huge problem with this approach. When we had File specified as a typehint, we were positive about what our class can handle. It was explicit and if something else came in, a nice error told us so.

Argument 1 passed to Progress::__construct()
    must be an instance of File,
    instance of Music given.

But without the typehint, we must rely on the fact that whatever comes in will have two public variables of some exact names like "length" and "sent". Otherwise we will have a refused bequest.

Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class. ~Source Wikipedia.

This is one of the code smells presented in much more detail in the Detecting Code Smells premium course. In short, we do not want to end up trying to call methods or access fields on objects that do not conform to our contract. When we had a typehint, the contract was specified by it. The fields and methods of the File class. Now that we have nothing, we can send in anything, even a string and it would result in an ugly error.

function testItFailsWithAParameterThatDoesNotRespectTheImplicitContract() {
    	$progress = new Progress('some string');
    	$this->assertEquals(50, $progress->getAsPercent());
    }

A test like this, where we send in a simple string, will produce a refused bequest:

Trying to get property of non-object.

While the end result is the same in both cases, meaning the code breaks, the first one produced a nice message. This one, however, is very obscure. There is no way of knowing what the variable is - a string in our case - and what properties were looked for and not found. It is difficult to debug and to solve the problem. A programmer needs to open the Progress class and read it and understand it. The contract, in this case, when we do not explicitly specify the typehint, is defined by the behavior of Progress. It is an implicit contract, known only to Progress. In our example, it is defined by the access to the two fields, sent and length, in the getAsPercent() method. In real life the implicit contract can be very complex and hard to discover by just looking for a few seconds at the class.

This solution is recommended only if none of the other suggestions below can easily be implemented or if they would inflict serious architectural changes that do not justify the effort.

Solution 2: Use the Strategy Design Pattern

This is the most common and probably the most appropriate solution to respect OCP. It is simple and effective.

The Strategy Pattern simply introduces the use of an interface. An interface is a special type of entity in Object Oriented Programming (OOP) which defines a contract between a client and a server class. Both classes will adhere to the contract to ensure the expected behavior. There may be several, unrelated, server classes that respect the same contract thus being capable of serving the same client class.

interface Measurable {
    	function getLength();
    	function getSent();
    }

In an interface we can define only behavior. That is why instead of directly using public variables we will have to think about using getters and setters. Adapting the other classes will not be difficult at this point. Our IDE can do most of the job.

function testItCanGetTheProgressOfAFileAsAPercent() {
    	$file = new File();
    	$file->setLength(200);
    	$file->setSent(100);
    
    	$progress = new Progress($file);
    
    	$this->assertEquals(50, $progress->getAsPercent());
    }

As usual, we start with our tests. We will need to use setters to set the values. If considered mandatory, these setters may also be defined in the Measurable interface. However, be careful what you put there. The interface is to define the contract between the client class Progress and the different server classes like File and Music. Does Progress need to set the values? Probably not. So the setters are highly unlikely to be needed to be defined in the interface. Also, if you would define the setters there, you would force all of the server classes to implement setters. For some of them, it may be logical to have setters, but others may behave totally differently. What if we want to use our Progress class to show the temperature of our oven? The OvenTemperature class may be initialized with the values in the constructor, or obtain the information from a third class. Who knows? To have setters on that class would be odd.

class File implements Measurable {
    
    	private $length;
    	private $sent;
    
    	public $filename;
    	public $owner;
    
    	function setLength($length) {
    		$this->length = $length;
    	}
    
    	function getLength() {
    		return $this->length;
    	}
    
    	function setSent($sent) {
    		$this->sent = $sent;
    	}
    
    	function getSent() {
    		return $this->sent;
    	}
    
    	function getRelativePath() {
    		return dirname($this->filename);
    	}
    
    	function getFullPath() {
    		return realpath($this->getRelativePath());
    	}
    
    }

The File class is modified slightly to accommodate the requirements above. It now implements the Measurable interface and has setters and getters for the fields we are interested in. Music is very similar, you can check its content in the attached source code. We are almost done.

class Progress {
    
    	private $measurableContent;
    
    	function __construct(Measurable $measurableContent) {
    		$this->measurableContent = $measurableContent;
    	}
    
    	function getAsPercent() {
    		return $this->measurableContent->getSent() * 100 / $this->measurableContent->getLength();
    	}
    
    }

Progress also needed a small update. We can now specify a type, using typehinting, in the constructor. The expected type is Measurable. Now we have an explicit contract. Progress can be sure the accessed methods will be always present because they are defined in the Measurable interface. File and Music can also be sure they can provide all that is needed for Progress by simply implementing all the methods on the interface, a requirement when a class implements an interface.

This design pattern is explained in greater detail in the Agile Design Patterns course.

A Note on Interface Naming

People tend to name interfaces with a capital I in front of them, or with the word "Interface" attached at the end, like IFile or FileInterface. This is an old-style notation imposed by some outdated standards. We are so much past the Hungarian notations or the need to specify the type of a variable or object in its name in order to easier identify it. IDEs identify anything in a split second for us. This allows us to concentrate on what we actually want to abstract.

Interfaces belong to their clients. Yes. When you want to name an interface you must think of the client and forget about the implementation. When we named our interface Measurable we did so thinking about Progress. If I would be a progress, what would I need to be able to provide the percent? The answer is simple, something we can measure. Thus the name Measurable.

Another reason is that the implementation can be from various domains. In our case, there are files and music. But we may very well reuse our Progress in a racing simulator. In that case, the measured classes would be Speed, Fuel, etc. Nice, isn't it?

Solution 3: Use the Template Method Design Pattern

The Template Method design pattern is very similar to the strategy, but instead of an interface it uses an abstract class. It is recommended to use a Template Method pattern when we have a client very specific to our application, with reduced reusability and when the server classes have common behavior.

This design pattern is explained in greater detail in the Agile Design Patterns course.

A Higher Level View

So, how is all of this affecting our high level architecture?

If the image above represents the current architecture of our application, adding a new module with five new classes (the blue ones) should affect our design in a moderate way (red class).

In most systems you can't expect absolutely no effect on the existing code when new classes are introduced. However, respecting the Open/Closed Principle will considerably reduce the classes and modules that require constant change.

As with any other principle, try not to think about everything from before. If you do so, you will end up with an interface for each of your classes. Such a design will be hard to maintain and understand. Usually the safest way to go is to think about the possibilities and if you can determine whether there will be other types of server classes. Many times you can easily imagine a new feature or you can find one on the project's backlog that will produce another server class. In those cases, add the interface from the beginning. If you can not determine, or if you are unsure - most of the time - simply omit it. Let the next programmer, or maybe even yourself, to add the interface when you need a second implementation.

Final Thoughts

If you follow your discipline and add interfaces as soon as a second server is needed, modifications will be few and easy. Remember, if code required changes once, there is a high possibility it will require change again. When that possibility turns into reality, OCP will save you a lot of time and effort.

Thank you for reading.

Single Responsibility (SRP), Open/Closed (OCP), Liskov’s Substitution, Interface Segregation, and Dependency Inversion. Five agile principles that should guide you every time you need to write code.

Definition

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

The Open/Closed Principle, OCP in short, is credited to Bertrand Mayer, a French programmer, who first published it in his book n Object-Oriented Software Construction in 1988.

The principle rose in popularity in the early 2000s when it became one of the SOLID principles defined by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices and later republished in the C# version of the book Agile Principles, Patterns, and Practices in C#.

What we are basically talking about here is to design our modules, classes and functions in a way that when a new functionality is needed, we should not modify our existing code but rather write new code that will be used by existing code. This sounds a little bit strange, especially if we are working in languages like Java, C, C++ or C# where it applies not only to the source code itself but to the binary also. We want to create new features in ways that will not require us to redeploy existing binaries, executables or DLLs.

OCP in the SOLID Context

As we progress with these tutorials, we can put each new principle in the context of the already discussed ones. We already discussed the Single Responsibility (SRP) that stated that a module should have only one reason to change. If we think about OCP and SRP, we can observe that they are complementary. Code specifically designed with SRP in mind will be close to OCP principles or easy to make it respect those principles. When we have code that has a single reason to change, introducing a new feature will create a secondary reason for that change. So both SRP and OCP would be violated. In the same way, if we have code that should only change when its main function changes and should remain unchanged when a new feature is added to it, thus respecting OCP, will mostly respect SRP also.

This does not mean that SRP always leads to OCP or vice versa, but in most cases if one of them is respected, achieving the second one is quite simple.

The Obvious Example of OCP Violation

From a purely technical point of view, the Open/Closed Principle is very simple. A simple relationship between two classes, like the one below violates the OCP.

The User class uses the Logic class directly. If we need to implement a second Logic class in a way that will allow us to use both the current one and the new one, the existing Logic class will need to be changed. User is directly tied to the implementation of Logic, there is no way for us to provide a new Logic without affecting the current one. And when we are talking about statically typed languages, it is very possible that the User class will also require changes. If we are talking about compiled languages, most certainly both the User executable and the Logic executable or dynamic library will require recompilation and redeployment to our clients, a process we want to avoid whenever possible.

Show Me the Code

Based only on the schema above, one can deduce that any class directly using another class would actually violate the Open/Closed Principle. And that is right, strictly speaking. I found it quite interesting to find the limits, the moment when you draw the line and decide that it is more difficult to respect OCP than modify existing code, or the architectural cost does not justify the cost of changing existing code.

Let’s say we want to write a class that can provide progress as a percent for a file that is downloaded through our application. We will have two main classes, a Progress and a File, and I imagine we will want to use them like in the test below.

function testItCanGetTheProgressOfAFileAsAPercent() {
    	$file = new File();
    	$file->length = 200;
    	$file->sent = 100;
    
    	$progress = new Progress($file);
    
    	$this->assertEquals(50, $progress->getAsPercent());
    }

In this test we are a user of Progress. We want to obtain a value as a percent, regardless of the actual file size. We use File as the source of information for our Progress. A file has a length in bytes and a field called sent representing the amount of data sent to the one doing the download. We do not care about how these values are updated in the application. We can assume there is some magical logic doing it for us, so in a test we can set them explicitly.

class File {
    	public $length;
    	public $sent;
    }

The File class is just a simple data object containing the two fields. Of course in real life, it would probably contain other information and behavior also, like file name, path, relative path, current directory, type, permissions and so on.

class Progress {
    
    	private $file;
    
    	function __construct(File $file) {
    		$this->file = $file;
    	}
    
    	function getAsPercent() {
    		return $this->file->sent * 100 / $this->file->length;
    	}
    
    }

Progress is simply a class taking a File in its constructor. For clarity, we specified the type of the variable in the constructor’s parameters. There is a single useful method on Progress, getAsPercent(), which will take the values sent and length from File and transform them into a percent. Simple, and it works.

Testing started at 5:39 PM ...
    PHPUnit 3.7.28 by Sebastian Bergmann.
    .
    Time: 15 ms, Memory: 2.50Mb
    OK (1 test, 1 assertion)

This code seems to be right, however it violates the Open/Closed Principle. But why? And How?

Changing Requirements

Every application that is expected to evolve in time will need new features. One new feature for our application could be to allow streaming of music, instead of just downloading files. File‘s length is represented in bytes, the music’s duration in seconds. We want to offer a nice progress bar to our listeners, but can we reuse the one we already have?

No, we can not. Our progress is bound to File. It understands only files, even though it could be applied to music content also. But in order to do that we have to modify it, we have to make Progress know about Music and File. If our design would respect OCP, we would not need to touch File or Progress. We could just simply reuse the existing Progress and apply it to Music.

Solution 1: Take Advantage of the Dynamic Nature of PHP

Dynamically typed languages have the advantages of guessing the types of objects at runtime. This allows us to remove the typehint from Progress‘ constructor and the code will still work.

class Progress {
    
    	private $file;
    
    	function __construct($file) {
    		$this->file = $file;
    	}
    
    	function getAsPercent() {
    		return $this->file->sent * 100 / $this->file->length;
    	}
    
    } 

Now we can throw anything at Progress. And by anything, I mean literally anything:

class Music {
    
    	public $length;
    	public $sent;
    
    	public $artist;
    	public $album;
    	public $releaseDate;
    
    	function getAlbumCoverFile() {
    		return 'Images/Covers/' . $this->artist . '/' . $this->album . '.png';
    	}
    } 

And a Music class like the one above will work just fine. We can test it easily with a very similar test to File.

function testItCanGetTheProgressOfAMusicStreamAsAPercent() {
    	$music = new Music();
    	$music->length = 200;
    	$music->sent = 100;
    
    	$progress = new Progress($music);
    
    	$this->assertEquals(50, $progress->getAsPercent());
    }

So basically, any measurable content can be used with the Progress class. Maybe we should express this in code by changing the variable’s name also:

class Progress {
    
    	private $measurableContent;
    
    	function __construct($measurableContent) {
    		$this->measurableContent = $measurableContent;
    	}
    
    	function getAsPercent() {
    		return $this->measurableContent->sent * 100 / $this->measurableContent->length;
    	}
    
    } 

Good, but we have a huge problem with this approach. When we had File specified as a typehint, we were positive about what our class can handle. It was explicit and if something else came in, a nice error told us so.

Argument 1 passed to Progress::__construct()
    must be an instance of File,
    instance of Music given.

But without the typehint, we must rely on the fact that whatever comes in will have two public variables of some exact names like “length” and “sent“. Otherwise we will have a refused bequest.

Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class. ~Source Wikipedia.

This is one of the code smells presented in much more detail in the Detecting Code Smells premium course. In short, we do not want to end up trying to call methods or access fields on objects that do not conform to our contract. When we had a typehint, the contract was specified by it. The fields and methods of the File class. Now that we have nothing, we can send in anything, even a string and it would result in an ugly error.

function testItFailsWithAParameterThatDoesNotRespectTheImplicitContract() {
    	$progress = new Progress('some string');
    	$this->assertEquals(50, $progress->getAsPercent());
    }

A test like this, where we send in a simple string, will produce a refused bequest:

Trying to get property of non-object.

While the end result is the same in both cases, meaning the code breaks, the first one produced a nice message. This one, however, is very obscure. There is no way of knowing what the variable is – a string in our case – and what properties were looked for and not found. It is difficult to debug and to solve the problem. A programmer needs to open the Progress class and read it and understand it. The contract, in this case, when we do not explicitly specify the typehint, is defined by the behavior of Progress. It is an implicit contract, known only to Progress. In our example, it is defined by the access to the two fields, sent and length, in the getAsPercent() method. In real life the implicit contract can be very complex and hard to discover by just looking for a few seconds at the class.

This solution is recommended only if none of the other suggestions below can easily be implemented or if they would inflict serious architectural changes that do not justify the effort.

Solution 2: Use the Strategy Design Pattern

This is the most common and probably the most appropriate solution to respect OCP. It is simple and effective.

The Strategy Pattern simply introduces the use of an interface. An interface is a special type of entity in Object Oriented Programming (OOP) which defines a contract between a client and a server class. Both classes will adhere to the contract to ensure the expected behavior. There may be several, unrelated, server classes that respect the same contract thus being capable of serving the same client class.

interface Measurable {
    	function getLength();
    	function getSent();
    }

In an interface we can define only behavior. That is why instead of directly using public variables we will have to think about using getters and setters. Adapting the other classes will not be difficult at this point. Our IDE can do most of the job.

function testItCanGetTheProgressOfAFileAsAPercent() {
    	$file = new File();
    	$file->setLength(200);
    	$file->setSent(100);
    
    	$progress = new Progress($file);
    
    	$this->assertEquals(50, $progress->getAsPercent());
    }

As usual, we start with our tests. We will need to use setters to set the values. If considered mandatory, these setters may also be defined in the Measurable interface. However, be careful what you put there. The interface is to define the contract between the client class Progress and the different server classes like File and Music. Does Progress need to set the values? Probably not. So the setters are highly unlikely to be needed to be defined in the interface. Also, if you would define the setters there, you would force all of the server classes to implement setters. For some of them, it may be logical to have setters, but others may behave totally differently. What if we want to use our Progress class to show the temperature of our oven? The OvenTemperature class may be initialized with the values in the constructor, or obtain the information from a third class. Who knows? To have setters on that class would be odd.

class File implements Measurable {
    
    	private $length;
    	private $sent;
    
    	public $filename;
    	public $owner;
    
    	function setLength($length) {
    		$this->length = $length;
    	}
    
    	function getLength() {
    		return $this->length;
    	}
    
    	function setSent($sent) {
    		$this->sent = $sent;
    	}
    
    	function getSent() {
    		return $this->sent;
    	}
    
    	function getRelativePath() {
    		return dirname($this->filename);
    	}
    
    	function getFullPath() {
    		return realpath($this->getRelativePath());
    	}
    
    }

The File class is modified slightly to accommodate the requirements above. It now implements the Measurable interface and has setters and getters for the fields we are interested in. Music is very similar, you can check its content in the attached source code. We are almost done.

class Progress {
    
    	private $measurableContent;
    
    	function __construct(Measurable $measurableContent) {
    		$this->measurableContent = $measurableContent;
    	}
    
    	function getAsPercent() {
    		return $this->measurableContent->getSent() * 100 / $this->measurableContent->getLength();
    	}
    
    } 

Progress also needed a small update. We can now specify a type, using typehinting, in the constructor. The expected type is Measurable. Now we have an explicit contract. Progress can be sure the accessed methods will be always present because they are defined in the Measurable interface. File and Music can also be sure they can provide all that is needed for Progress by simply implementing all the methods on the interface, a requirement when a class implements an interface.

This design pattern is explained in greater detail in the Agile Design Patterns course.

A Note on Interface Naming

People tend to name interfaces with a capital I in front of them, or with the word “Interface” attached at the end, like IFile or FileInterface. This is an old-style notation imposed by some outdated standards. We are so much past the Hungarian notations or the need to specify the type of a variable or object in its name in order to easier identify it. IDEs identify anything in a split second for us. This allows us to concentrate on what we actually want to abstract.

Interfaces belong to their clients. Yes. When you want to name an interface you must think of the client and forget about the implementation. When we named our interface Measurable we did so thinking about Progress. If I would be a progress, what would I need to be able to provide the percent? The answer is simple, something we can measure. Thus the name Measurable.

Another reason is that the implementation can be from various domains. In our case, there are files and music. But we may very well reuse our Progress in a racing simulator. In that case, the measured classes would be Speed, Fuel, etc. Nice, isn’t it?

Solution 3: Use the Template Method Design Pattern

The Template Method design pattern is very similar to the strategy, but instead of an interface it uses an abstract class. It is recommended to use a Template Method pattern when we have a client very specific to our application, with reduced reusability and when the server classes have common behavior.

This design pattern is explained in greater detail in the Agile Design Patterns course.

A Higher Level View

So, how is all of this affecting our high level architecture?

If the image above represents the current architecture of our application, adding a new module with five new classes (the blue ones) should affect our design in a moderate way (red class).

In most systems you can’t expect absolutely no effect on the existing code when new classes are introduced. However, respecting the Open/Closed Principle will considerably reduce the classes and modules that require constant change.

As with any other principle, try not to think about everything from before. If you do so, you will end up with an interface for each of your classes. Such a design will be hard to maintain and understand. Usually the safest way to go is to think about the possibilities and if you can determine whether there will be other types of server classes. Many times you can easily imagine a new feature or you can find one on the project’s backlog that will produce another server class. In those cases, add the interface from the beginning. If you can not determine, or if you are unsure – most of the time – simply omit it. Let the next programmer, or maybe even yourself, to add the interface when you need a second implementation.

Final Thoughts

If you follow your discipline and add interfaces as soon as a second server is needed, modifications will be few and easy. Remember, if code required changes once, there is a high possibility it will require change again. When that possibility turns into reality, OCP will save you a lot of time and effort.

Thank you for reading.

As we celebrate Martin Luther King Jr. Day, check out UMBC’s online exhibit “For All the World to See,” which focuses on the civil rights movement.

For All the World to See: Visual Culture and the Struggle for Civil Rights is organized by the Center for Art, Design and Visual Culture, University of Maryland, Baltimore County in partnership with the Smithsonian National Museum of African American History and Culture. Through a host of media—including photographs, television and film, magazines, newspapers, posters, books, and pamphlets—the project explores the historic role of visual culture in shaping, influencing, and transforming the fight for racial equality and justice in the United States from the late-1940s to the mid-1970s. For All the World to See includes a traveling exhibition, website, online film festival, and richly illustrated companion book.

If you’re in Texas, the exhibit will be coming your way on January 28. Be sure to see if it’s making a stop in a town near you!

For more information, read our story about the exhibit from an issue of the UMBC Magazine.

CSEE professor Tim Finin has been appointed as a co-editor of the Viewpoints section of the Communications of the ACM, the monthly magazine of the Association for Computing Machinery. ACM was founded in 1947 and is the world’s largest educational and scientific computing society with the mission of providing resources that advance computing as a science and a profession.

The Communications of the ACM was started in 1957 and is sent to all ACM members (currently over 100,000) and is considered “the leading print and online publication for the computing and information technology fields”. CACM’s Viewpoints section is publishes short articles expressing opinions and views that pertain to issues of broad interest to the computing community, covering a wide range of topics, including scientific, technical, educational and social. Each month a handful of articles are published from those contributed by a set of distinguished ACM columnists and submitted by ACM members and computing professionals.

Workaholism is often confused with hard work. Some people who work on the Web seem not only to disregard its dangers, but to actively promote it. They see it as a badge of honor—but is it really? On the contrary, it’s a serious issue that can damage Web teams.

Before we get started, let’s make one thing clear: A “workaholic” is someone who is addicted to work, someone who is out of balance and out of control. Their addiction can make them work for 12, 14 or even more hours a day, every day. No weekends, no vacations, just work. Soon, they neglect their family, friends, health, sometimes damaging them all irrevocably.

In contrast, people who simply “work hard” do not expose themselves to such dangers. Putting in a few extra hours to meet a critical deadline doesn’t usually result in workaholism, provided that those sprints are rare and justified.

On Good Web Teams

Running a modern Web business can be demanding. As a result, some business owners stretch their employees as far as they can. What they fail to realize is that working 40 hours per week is enough. Any more and both the employees and the business could be harmed, startups included.

Productivity depends not only on working hours, but on intensity of work. Here’s a magic equation:

work accomplished = time spent × intensity of focus

Pushing people to work more hours is a superficial solution, not a viable one.

Good teams, winning teams, are fragile ecosystems. Members communicate with each other through different media (face to face, instant messages, email, project management software), and the communication is often asynchronous (thus, accommodating both early birds and night owls, as well as people in other time zones). Once a team finds its pace, that rhythm must be protected.

Members of this fragile ecosystem are connected by invisible bonds of respect and care. Teams are made up of humans. You can see this in action on a sports team: When an opponent attacks a member of the team, the rest rush to protect their teammate. That’s team spirit.

Workaholics have a much more extreme approach to work. They work far more than 40 hours per week, they disrupt the rhythm of the team, and they disregard the invisible bonds of care and respect. Just one of them is enough to damage the health of a good team.

How Does Someone Become A Workaholic?

Think of the movies that feature a lonely computer programmer, coding non-stop day and night. The character is familiar. But can computers themselves stimulate workaholism? They are, after all, absorbing and entertaining at once. Losing control seems to be a greater danger for us than for other professionals. However, a job can’t turn someone into a workaholic. Workaholics tend to be rigid, perfectionist and born achievers.

“He would waste no hour.” (Image: Iana Peralta)

Workaholics have a characteristic that distinguishes them from people who just love their work: personal insecurity. Personal insecurity is associated with neuroticism, another inherent characteristic of workaholics, according to the study “Personality Correlates of Workaholism” (PDF). Peter E. Mudrack, in his chapter “Understanding Workaholism: The Case for Behavioral Tendencies” for the book Research Companion to Working Time and Work Addiction, connects workaholism to feelings of low self-worth and insecurity.

Insecurity comes in many guises: low self-esteem, antagonism, authoritarianism, severe fear of failure, perfectionism. The actions of workaholics express an urgent need to prove to themselves and to others that they’re better than everyone else in the room. Deep down, they hurt. Some feel like a failure in their personal life and use their job to escape from a bad relationship or to make up for an absence in their personal life.

Sometimes people become workaholics for less complicated reasons. A big loan or a personal debt are tangible problems. If someone is in desperate need of money, they’ll work as much as they can to get it. Supporting a large family is also a huge burden. Such situations are oppressive and make some people abandon their principles and become workaholics.

In some ways, workaholism is a symptom of modern society. We live in a culture where productivity is paramount and the boundaries between leisure and work are no longer clear. We’re raising a generation of people who not only love their work but put it at the center of their lives. The entrepreneurial lifestyle is held up as the model of how to work on the Web. Slowly, gradually, we are changing our fundamental values and criteria for success.

Are You a Workaholic?

Most workaholics wouldn’t admit that they’re one to themselves, let alone to anyone else. If you’re worried that you might be one, ask yourself a few simple questions:

• “Do I work far more than 40 hours per week?”
• “Do I feel a continual urge to prove that I’m the best among my colleagues?”
• “Do I recognize signs of intense insecurity in myself about work?”
• “Are my personal and work lives balanced?”

There’s even an online quiz that could help you. It’s simple and short.

You could bury your head in the sand and pretend that everything is OK. But if you suspect that you’re a workaholic, then doing something about it is critical. And if you still think workaholism is cool, please keep on reading.

The Attractiveness Of Workaholics

Yes, some employers love workaholics. But why are workaholics so appealing?

• They work longer hours than the rest of the team.
• They don’t mind taking work home.
• Outworking everyone else makes them seem like they care. Always taking on responsibility and being at work all of the time make them look valuable. And carrying on under any circumstance makes them a fighter.

They know what employers want, and they’re eager to give it.

Let’s take a look at two archetypal workaholics.

1. The Committed Lead Programmer

Upon conducting extensive research, an experienced lead programmer comes up with a number of different database implementations to apply to a Web project. He decides to test each one thoroughly to find the best one. This doesn’t impinge on anyone’s time except his own. He decides to take the job home and works day and night to accomplish the task. He knows it won’t be easy, but he’s committed. All he wants is to be appreciated for his dedication and work.

Pretty compelling, right? A meticulous Web worker who sacrifices his personal time to advance the project.

2. The Project Manager With Mettle

In a casual company meeting, a project manager promises stakeholders a sophisticated implementation of a service on an incredibly tight schedule. He’s not afraid to take responsibility for the project, and he promises to check every single aspect of it personally. If that requires him to push the team as far as he can, then so be it.

Stakeholders leave the meeting impressed by his loyalty and determination. At last, they have found someone they can count on.

The characters above are just a couple of the types of workaholics in our industry. There are many: the superstar designer who’s willing to present multiple design directions; the perfectionist developer who insists on flawless code, even sacrificing his summer vacations. The list goes on.

Such people look much more attractive than their coworkers who stick to eight-hour workdays. They have charisma, they work hard, and they should be praised, if not promoted.

“Office hours” are sometimes relative. (Image: Florian Boyd)

The Fake Glow Of Workaholism

The glow of this perfectionism is false. These practices are only temporarily fruitful, and they can eventually result in disaster. The reason is that workaholism is a shortsighted strategy, one that encourages people to express the worst parts of their personality.

Why is it shortsighted? Because the committed programmer cited above is unconsciously hurting his team’s spirit. As Scott Berkun notes:

“Simply outworking other people can have a negative effect on others: that 5× improvement may create a -2× impact on everyone else: if the star demoralizes others and goes out of his way to embarrasses them with his talent, morale and productivity are sure to drop.”

Furthermore, even the most productive employees can’t keep working with such intensity for long. They will eventually wear out, as will their ability to think clearly. They will no longer be able to contribute to the team or make sound decisions. A successful team needs steady performance from its members more than heroic efforts. A member who temporarily outworks the rest of the team soon becomes an obstacle because they can’t work as part of the team, despite their best intentions.

And why does workaholism lead people to show the dark side of their personality? Let’s return to our second character type. The project manager who would do anything to keep his promise will end up creating too much tension by pushing the team members to their limit. Even if he pushes himself more, he will not inspire anyone; he will merely be a foolish dictator — not a member of the team, but an opponent.

When a team struggles to cope with an impossible project and infighting occurs, the incredible pressure will reduce the overall quality of the work. In such an environment, the manager could very easily get someone out of their way by derailing them, as Shanley explains:

“Any disagreement or critique is transformed into a symptom of pathology on the part of the dissenter. Managers may imply that the individual is unstable, emotionally disturbed, or has a mental disorder. Commonly, this includes overtly stating or implying that the dissenter is “too emotional,” should “take some time off,” “has an anger problem,” is “hostile,” is “overly aggressive,” “takes things too seriously/personally” or “has a problem with authority.””

In the best case scenario, the workaholic will end up exhausted, needing weeks or even months to recover. In the worst case scenario, the team will derail and the members will be dispirited.

Workaholic Companies

Too many workaholic companies are out there, and it’s pretty easy for an employer to create one. All the employer has to do is push people to work beyond their limit and punish the ones who don’t. Big companies such as McKinsey have have sought out such people, according to CNN.

Workaholic companies are machines that burn people out. They don’t care about creating teams. They exploit the enthusiasm of young people and dry them up. One indicator of a workaholic company is that its contractors rarely stay with it for more than a few years.

There are other ways to identify workaholic companies. A few people proudly call themselves workaholics, but most people don’t boast about it, and spotting one from the outside can be hard. However, they can be identified. Before entering a new work environment, search for the “local heroes” — the people who urge everyone else to work more, who can’t have a good laugh during working hours or who constantly talk about “the good of the company.” Can you find the individuals who, beyond a doubt, elicit unpleasant feelings from the rest of the team? They are the ones to watch out for.

Go on. Don’t be afraid to ask straight questions of potential employers during interviews. They may respond vaguely, but try to get crystal clear answers. Some employers expect you to be as dedicated as them, to put yourself in their shoes. Or they will tell you that the company is now your home and that you should do whatever it takes to make it thrive. If you hear these words, run away!

Remember that you work for money, but money alone is not enough. A job is also about being satisfied, which comes from an effective management style, good use of the team’s various skills and a pleasant atmosphere. A workaholic company needs you more than you need it. You deserve better.

Workaholics tend to lose track of time — voluntarily or involuntarily. (Image credit: “Microaggression and Management“.)

Working With Workaholics

An environment where workaholism is the norm soon gets frustrating. You will quickly find yourself with two choices: follow the others or stand your ground and work according to your own conscience.

The first option is an admission of defeat. You’re saying, “I won’t try to change the situation here because, if I do so, my job will be at risk.” While no one would blame you for taking this route, you will wither day by day, dying a slow death.

The second option brings its own problems. You must be prepared to fight for your right to work normally. Remain calm, patient and diligent, while questioning everything. You could raise the following questions:

• How is performance measured?
• Why are deadlines so harsh?
• Who is ultimately responsible, and what happens when things go wrong?
• What are the procedures for making complaints?
• What is the past and future of the company?

If you do find yourself in a workaholic company, the first thing to do is keep sane and keep working. Try to find out why things have gone wrong. Ask questions in front of others so that they feel empowered to ask questions, too. Workaholism affects everyone, but not everyone feels free to speak up. If you never talk about it, no one will help you.

If the culture of the company as a whole promotes workaholism, then your employer might not be happy with you for pointing it out. Your employer might think that someone who works eight hours a day doesn’t work enough and will tempt others to work less. It’s not going to be easy, but it is worth the effort. If you can demonstrate that workaholism is destructive, then you’ll gradually change the culture of the company, a huge win.

Fighting Workaholism

Modern businesses need strong teams, not overworked individuals. They need healthy environments, with people who care as much for their teammates as they do for their products.

Fighting workaholism is not easy, but it can be done. How?

• Be eager to reject workaholism. Every. Single. Day.
• Learn to recognize workaholics.
• Avoid workaholic companies. You won’t regret it.
• If you are at a workaholic company now, end your workday at a reasonable time, or suffer the consequences.
• Spread the word.

Employers are responsible for workaholism, but if Web workers reject workaholic companies, then those employers would have to change their ways.

Perhaps you’re saying, “What if I’m the employer?”

It’s simple, really. By now, you must have realized that promoting workaholism won’t take you far. So, stand up, leave your desk and see if any workaholics are destroying your fragile ecosystem. Help them to bring balance back to their life. And if that doesn’t work, then do as the smart folks say: fire the workaholic!

(al, il)

© Yiannis Konstantakopoulos for Smashing Magazine, 2014.

If you’re anything like me, you spend a lot of time studying other designers’ work. I like to look at projects for the experience and the interactions created for the users.

Obviously, as more techniques come about, the changes in web design take place and newer, better things arrive. We’ve experienced the life of the splash page, the introduction header, parallax scrolling and so many other things that have affected the web experience. However, those things were mainly aesthetic and didn’t really change the way we create websites.

Lately, I’ve been thumbing through some websites and have seen a new change. One I think I like, but am not sure. A change that I could see really reinventing the way we even think about designing websites. It would cause us to be smarter and think more intuitively about our audience. And that couldn’t be a bad thing. This technique is something that’s not unique to the world of responsive and mobile design. However, for some tablets and desktops, it’s a new variety of navigation.

We aren’t getting rid of menus all together, we are just hiding them until they are called for. Could this be something that takes off?

How important are navigation bars?

The navigation bar was born right along with the Internet. Designers believe that placing all the menu content in clear view on a page just makes sense. And it’s hard to argue. If you come to a website for the first time, you want to know what’s available and where to go. It seems to have cemented itself as an important part of web design. Wireframing toolkits and programs include navigation bars, just like they include dummy text and buttons.

Navigation bars are presented in many different ways. Lately, sticky navbars have become very popular. Unlike the proposed effort, this nav bar is always present on the page. However, sticky bars are usually used in sites with heavy parallax scrolling (another huge trend). This can end up being a bit distracting, especially when it takes up a horizontal area at the top of a page.

It’s hard to argue the effectiveness of navigation bars. As a matter of fact, I won’t. They are effective and are the norm in web design right now. But, is there a better way to present our menus that could possibly change the entire way we think about web design? I believe so, and this way to change web design is to get rid of the navigation bar all together. But why?

3 reasons to stop using navigation bars

1. Fewer distractions

This is something I’ve touched on previously, but with the absence of navigation bars, there’s obviously fewer distractions. Navigation bars have become a place to store all the content you can’t fit on your website. On top of that, we put every single page we’ve imagined and come up with on the navigation bar. Some are junky and cluttered. Some have telephone numbers and search boxes. Some are just big and only have three small links on them. Some have drop-down menus that span the entire height of a website. What’s the point?

In the past few years we’ve come to notice that web design was becoming a little too cluttered, thus the resurgence of the ever-popular minimalist design. But instead of really fixing the problem of clutter, we’ve just stripped our web designs of the exciting stuff. In addition, the focus on the menu and the sitemap have really cost us the most important parts of the website. Immediately when we start designing, we are taught to think of the sitemap and how everything is going to connect. Imagine if we spent that time thinking about what the audience wants and how they’re going to use it. 

2. Customer Focus

At one point, I posed the question of whether or not flat design has made our web sites too simple. I’ve also asked other community members if they think minimalism is killing our creativity. I’ll spare you the lengthy read and summarize by saying this: we’ve traded in spectacular design for subtle web experiences. What do I mean? We’d rather have a simple blog with a white background, as long as the posts auto-scroll. We’d rather use a monotone or two-tone color scheme and make the highlight color something totally expected. Because we think that’s cool.

Now, I must admit that we must be weary of over-designing. It’s something I don’t recommend at all. But it seems like we just stopped designing all together. And the things we find to be good design are really only things other designers can notice and enjoy. It took me about 5 years to learn the lesson that what a designer may think will look good isn’t always what the customer thinks looks good.

In order to be successful with this, we have to focus on the customer/audience like never before. We have to try to figure out exactly what they want to see and how they want to see it. Navigation bars have kind of been like a guided process before, but since they’re the norm we’re just slapping it on a site as one-size-fits-all. The focus on the customer creates a greater connection with them and lends itself to experience driven designs like never seen before.

3. Experience driven designs

Let’s build a bridge. This bridge connects what we want them to see along with how we want them to see it. The length of the bridge varies depending on how far away the two are from each other, but there must be a bridge nonetheless. We obviously want to have the smoothest bridge possible so the transfer of information can be as smooth as possible. By ridding ourselves of the navigation bar, we’ve created a platform to have a fully immersive brand design that should cater directly to the customer.

This allows us to now create experiences. Yes, we’ll probably have to get away from the world of strict minimalism. However, this gets web design back to what it should be; a space on the web dedicated to the relationship between a brand and its customer. These experiences should make visitors more away of the brand while also creating an interesting way to do so. Rather than just clicking a link and being taken to a whole new page, now there’s an opportunity to really create something. There’s an opportunity to take all the cool new advances in HTML and CSS3 (aside from just scrolling) and create something magical and mindblowing.

Conclusion

Without that pesky bar at the top of our pages, it really frees up a whole new world of thought. I’m sure you’re thinking, well if you move and it’s hidden, then there’s really no difference. But we are essentially taking away the very thing that moves viewers from page to page. How does one design a website like that? How does one manoeuver around a website like that? It seems impossible and as if removing a bar couldn’t have such a large impact, but I beg to differ. You can check any scrolling site that makes no large use of navigation.

Is this the next thing in the world of web design? Can you imagine going to a website that has no visible menu, but knowing where you want to go? It seems like a mighty interesting challenge; one many will take. Of course, the first problem would be for sites that are heavy on pages: Does your flyout menu contain tons of links or do you just learn to condense all the content? No navigation bars could really change the way of web design, but only the future can tell if this will be a new trend.

Have you built a site without a traditional navigation bar? Do you think navigation bars are essential in website design? Let us know in the comments.

Featured image/thumbnail, navigation image via Shutterstock.

Bundle of One-Page Parallax Bootstrap 3.0 Templates – only $17!

Sports, we like to believe, remains the one true unifier. If we can’t bridge differences in politics, religion, or nationality, we can at least enjoy the pure spirit of competition together.

Or in the case of Dennis Rodman, his over use of this spirit might have sent him into rehab.            

           This follows his recent stab at diplomacy via a basketball match between ex-NBA ballers and the North Korean national squad that failed in bizarre fashion. The Hermit Kingdom and the USA, suffice it to say, are as opposed to each other as ever.

               If anything, Rodman may have unwittingly hurt his own cause. He drew ire from many by implying during a CNN interview that Kenneth Bae, a longtime American prisoner in North Korea, deserved his imprisonment.

               To be fair, it may not have all been Rodman’s fault that things went awry. It doesn’t help when the dictator you’re trying to help orders his own uncle’s execution and the company financing your trip suddenly distances itself from the project.

               Ill-conceived it may have been, at least Rodman took a shot at making the world a bit safer, right? That has to account for something.

               And who knows: perhaps this really has nothing to do with peace with a hostile regime? Maybe this is really just a tale of two odd-balls finding unlikely camaraderie–with one another.