Intro to Object-Oriented Design

In this article, I want to discuss how to design an application with an Object-Oriented language. In order to do this we must change our way of looking at the world. We must shift our thinking of the world as a collection of predefined procedures to modeling the world as a series of messages that pass between the objects. And the world will become object oriented.

The reason why I’m writing this article is because, following the techniques of object oriented design will produce cost-effective software using code that is also a pleasure to work on. The problem design solves is change! Change is unavoidable — it is the need for change that makes design matter. Applications that are easy to change are a pleasure to work on.

Why is change such a destructive force? Because change is hard. Object oriented applications are made up of parts that interact to produce the behavior of the whole. The parts are objects and the interactions are embodied in the messages that pass between them. The sender of the message knows things about the receiver, this knowledge creates dependencies between the two and these dependencies are resistant to change.

Object oriented design is about managing dependencies. Unmanaged dependencies wreak havoc, changing one object forces change among its collaborators, which forces change among its collaborators, ad infinitum. A small change can radiate outwards which can ultimately leave no code untouch.

Every application is a collection of code; the code’s arrangement is the design. Design is the art of arranging code. Combing an overall understanding of your applications requirements with knowledge of the costs and benefits of design alternatives.

In some of my previous articles I explained what are design patterns and what are some of the design principles. There are many principles we can study. All of them got their start as choices someone made while writing code. And their discoveries were confirmed by academics that wanted to quantify “goodness”.

The gang of four wrote their book in 1995 to describe patterns as simple elegant solutions to specific problems. The SOLID principle is also one of these aforementioned principles.

Before I conclude this article I want to discuss the act of the design. Software is custom furniture, the principles and patterns are tools. The end results could be a beautiful cabinet or a rickety chair, which reflects the programmers experience with the tools. Lack of design applications are easy to write but impossible to change. Overdesign is also how design fails, seeing patterns where none exist is a common mistake with intermediate programmers. The final design flaw is when design is dictated from afar, none of the necessary adjustments can occur.

Thanks for taking the time to read this article.