Object Oriented Design: Part 1 — Purpose

Wilfred Tannr Allard
Launch School
Published in
2 min readFeb 14, 2018

The purpose of design

The purpose of Object Oriented Design (OOD) is to design software that has a low cost of change. Poorly designed code and well-designed code can both solve the exact same problem and provide the exact same features from a specific list of requirements. But when another set of requirements is added later on, the cost of integrating the new changes with the old code will be much greater in the case of poorly designed code. In other words, the greater the cost of change, the poorer the code is designed.

How is the term “cost” defined? How do we know how much a change “costs”? It can be thought about this way: given a new requirement and a currently-existent code base, imagine that all you had to do was write the new code that directly implements the new feature, and the application would magically work exactly as it should. That would make the change a zero cost change. Now imagine instead that implementing this feature required using a couple custom classes in the code base. It turns out that the implementation of this custom class was not written in anticipation of being used in this new way, so using it in this new way will actually raise an error. Implementing the new feature is now not only a matter of direct implementation, but tangential “repair” so that the implementation of the new feature will not raise an error when it uses the pre-existing custom class. This change is more costly than it was in the first scenario.

Why did this happen? Is there a way to tangibly notice when different components of code are likely to break when used in new and unanticipated contexts? In fact, there is, and it’s called looking at dependencies. Analyzing and managing dependencies will be covered in part 2 of this series on object oriented design.

If a code base never needed to change, then ‘design’ would be a meaningless term. The fact that code needs to change is the primary problem that design solves.

With a firm grounding in the “why” of Object Oriented Design, we can move onto the “how” in the next article of this series (stay tuned for its release).

--

--

Wilfred Tannr Allard
Launch School

Software Engineer | Working on infrastructure for sustainable, global crypto-economy @NervosNetwork | tannrallardtech@gmail.com | www.tannrallard.tech