Home > Software Design > OOAD Memento

OOAD Memento

March 11th, 2011 Leave a comment Go to comments

Object oriented analysis and design in my mind is absolutely the most important skill a software engineer must posses. I’m taking procedural languages out of the equation, since I’m a proponent of domain driven design, and that implies object oriented technologies.

If our brains had unlimited capacity and we could stretch our minds over an unlimited number of concepts, there would be no software engineering science. We would write programs in a linear fashion without breaking them into functions, encapsulating data and behavior into objects, or partitioning concerns into aspects. But unfortunately that is not the case – we normally cannot keep more than three to seven things in our head at the same time. Therefore, in my opinion, all methods and principles of software design in general, and OOAD in particular serve one and only one purpose – partitioning the problem space for our imperfect brains to comprehend it, and limit the number of things we keep in mind when modifying the program.

So, there is something special about a program that we perceive as well designed. As Martin Fowler well put it – “Any fool can write code that a computer can understand.  Good programmers write code that humans can understand.”

There are many techniques that help us make programs easier to understand, and easier to modify. In this article I’ll try to give a quick overview of what I consider important for successful object oriented analysis and design, and provide links to more resources on this topic. The information is rather compressed and sketchy, and gives a quick entry point if one wanted a refresher on the subject, therefore, I call it “memento”. So here is my memento on OOAD.

We’ll start with a cornerstone of OOAD – Encapsulation.

There is also a mnemonic that denotes five fundamental principles of OOAD:


  • SRP (Single Responsibility Principle)
  • OCP (Open/Closed Principle)
  • LSP (Liskov Substitution Principle)
  • ISP (Interface Segregation Principle)
  • DIP (Dependency Inversion Principle)

Dependency inversion principle is usually fulfilled via dependency injection (DI), which is a special case of Inversion of Control (IoC) principle.

We also want to minimize the dependencies between components, and make sure units of code only do one thing, but do it well.

If we separate concerns well, we may get to:

But there are some things that span layers and form separate aspects:

We also want to minimize code duplication:

  • DRY (don’t repeat yourself)

Albert Einstein once said – “Everything should be made as simple as possible, but no simpler”, which leads us to the following principles:

  • YAGNI (you ain’t gonna need it)
  • KISS (keep it simple stupid)

Quality of design can usually be gauged by Testability of the resulting software.

Finally, some design patterns related to quality of service include:

If you have something to add to this list, please drop me a line in comments.

  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.