Open/Closed Principle Violation

Before I post too many SOLID principle posts, let me prefix by saying that I strongly believing that following SOLID principles as guidelines will lead to writing better Object Oriented code.

Back to Open/Close Principle

Software entities like classes, modules and functions should be open for extension but closed for modifications.

Out of all the SOLID principles, I’ve found this one to causes the most confusion and is the hardest to identify for developers.  When following any of the SOLID principles, they all have a bit of cross over that help you identify when violating one of them.  Violating Open/Close principle usually means you are also violating Single Responsibility.

Here are a few smells/tips to for identifying when you might be violating Open/Closed principle:

  • Conditional Code
  • Multiple unit tests due to multiple execution paths
  • Violation of Single Responsibility
[code lang=”csharp”] // Something smells in here…
public int GetSpeed()
int speed = 0;

if (_type is Bike)
speed = 10;
else if (_type is Car)
speed = 70;
else if (_type is Jet)
speed = 300;

return speed;

Reality of fixed price & fixed scope

Fixed price, fixed scope development contracts are still a very relevant and are not likely going away.  Clients want a to know how much they are going to spend and exactly what they are going to get.  The reality is, iterative development was created because they don’t know (entirely) what they want up front.

Waterfall is still primarily used, however the reality is, it’s more of a business decision than a development decision.

Same old story…

We spend a great deal of time up front gathering business requirements and attempt to create a specification of our interpretations of those requirements.  We then learn new requirements which result in change requests.  Changes are generally viewed negatively during waterfall, even though they are getting the customer closer to the solution they want.

During implementation, there should be no business logic decisions to be made by the developers, right?  We should of defined all of this in our specification.  Ya right.

After implementation, testing, and delivery, our customers get their working software.   What is their reaction?

This isn’t working they way we wanted.

And then our response:

Yes it is.  Look at the specification.

This turns into meeting after meeting with no one happy.


The idea is that a waterfall project with a fixed price and fixed scope will let the client know exactly how much it is going to cost, and exactly what they are going to get.  The reality is they will get exactly what we documented from our interpretations of their requirements.

We document all scope up front so we can be certain that everything needed will be in the system.  Reality is the client cannot visualize everything they need in the system and requirements are missed and are moved into change management if they are ever realized.

Fixed price contracts are viewed to favor the client. The reality is they should favor the vendor who can handle change management correctly.  Other fixed priced custom solution industries (mold manufacturing) make their money not on the initial proposal, but in change management.

The reality is that there are constraints that force us into a fixed price waterfall process.  Project management, client expectations, and client education seem to be the key to success.