Object Oriented Software Design Principles: What happened?

One of the observations I’ve had while doing the interviews is that a great deal of the Senior Engineer candidates, even those that have worked for several years, almost always have “Object Oriented Programmer or Expert” written on their resume but they are not well versed in Object Oriented Design Principles.

When the opportunity arises, I love working with early career engineers on these concepts. I am very passionate about mentoring. I am afraid however that a lot of us have gotten out of the practice of mentoring and continuously learning. I am not sure why but maybe it is the lack of investment by businesses to make sure project schedules allow for the time.

There are quite a few senior (staff, principle) engineers that have forgotten that it is part of their job description to be able to mentor early to mid engineers and each other, to continuously be learning.

With learning and teaching these principles so that they become a habit, we can write code at a fast pace for the need of the short term while not compromising too much on the long term. All too often, the “write code fast for the short term” wins out and usually, this is not with the mindset that it will be refactored later. There are too many engineers out there that do not keep up on their skill sets and got where they are simply because of their long-term Subject Matter Expert knowledge from being at a single company for so long. They have lost their zeal to learn.

I know. I can see some of you reading this, thinking:

“Well there are all types of talent out there, some Seniors are better at communication and leading from a people perspective. We have to use the right tool for the job. There are different types of players on a team where each contributes in their own way.”

I definitely do not know everything there is to know about software engineering. I have a lot to still learn myself. For the most part, I agree but that does not mean at this level they should not be held accountable for having some inkling of good design principles. These are the basics!

If I am lucky, the candidate can tell me about polymorphism, inheritance, and encapsulation. If I am really lucky, they can tell me how visibility, cohesion, and abstraction work together to provide encapsulation or the difference in an interface and an abstract class. Hopefully, they can tell me when to use which. “Is-A” vs “Can-Do” relationships.

Most people cannot tell me a single main difference between procedural programming and object oriented programming. I believe partly the fault for that is that a good deal of development groups tend to spend their time in a rush, developing anemic domain models, using transaction script, thinking they are actually writing object oriented code when they are not.

“It’s Java, right? We are creating an object, right? I am doing object oriented programming!”

No, sorry you are not.

Keep in mind, when I am interviewing a candidate, I do my best to not be stuck on whether someone knows a principle by name, although I would consider it bonus points. I do not care if someone can tell me what SOLID, DRY, or GRASP stands for. I just want to understand what they would do in situations where the principles defined by SOLID would come into play. I am sure there are a lot of engineers out there have learned the principles in some form or fashion without learning the more technical term for it first. I know I am one of them. I try to dig deep and see if they do know the principles without them having to know the technical term. Even with this, I have seen quite a few who are just not there yet.

What we will cover

My motive for this article: Expediency and good practices can both be achieved

I know I may be coming off as slightly critical but I sincerely want to encourage early career and senior OOP engineers to really understand these principles and how to put them into practice.

There are a lot of managers and organizations out there that do not care about the craft and just want to get things done. They say it is for the company but in truth, if they cared about the company, they would be worried not only about the short-term but also the long-term effects of what they build today.

Do not put yourself in that bucket. It is possible to get things done fast in the short term but with a well-designed application with clean code for the long term. It is possible to have teams of engineers that can do both. The applications you are building and the company will be better for it.

So on that note, I would like to add yet another series of web pages on these following principles. Each section will slowly be added so check back periodically for updates. The acronyms below should link to each new post as it is created.


We will go over a set of nine different patterns defined by Craig Larman for Object Oriented Design. Larman did an excellent job defining these patterns to communicate what design experts were already intuitively doing. They move past the typical “define your nouns for the classes and your verbs for the methods” approach to object-oriented design to a more in-depth approach defining what role or responsibility each noun takes. An in-depth study can be had by reading his book Apply UML and Patterns
General Responsibility Assignment Software Patterns
Information Expert
Low Coupling
High Cohesion
Protected Variations
Pure Fabrication


SOLID principles will also be covered. The term was first created by Michael Feathers to help remember principles first laid out by Bob Martin. Bob describes these principles as helping with the dependency management aspects of OOD versus the conceptualization and modeling aspects of OOD. An in-depth study of these patterns can be found in his book Agile Software Development: Principles, Patterns, and Practices

The following descriptions were taken from Bob’s site UncleBob.com.

Single Responsibility – A class should have one, and only one, reason to change.

Open Closed Principle – You should be able to extend a classes behavior, without modifying it.

Liskov Substitution Principle – Derived classes must be substitutable for their base class.

Interface Segregation Principle – Make fine grain interfaces that are client specific.

Dependency Inversion Principle – Depend on abstractions, not concretions.

I hope you enjoy this as it grows. I am always open to improving and corrections so please feel free to post a message to ask questions, correct me, or just let me know if you hated or enjoyed the article. I am always looking for ways of improving myself.

I hope to have a PDF cheat sheet created for these principles soon and will post a link to it here.

Principles Cheat Sheet
Draft: GRASP Power Point

Leave a Reply