Refactoring and Design Patterns
This page
This chapter

Introduction to OOP


Learning curve




Relatively high learning curve

The learning curve on Object Oriented Programming is relatively high compared to Procedural Programming. There are several reasons for that:

1: Learning a new way of thinking

OOP introduces a new (or other) way of thinking to building code


2: More theory

With OOP comes a lot more theory of how you build and structure your code and what you should- and should not use and do. Then there are Design Patterns and Architectural Patterns (like Inversion of Control, Domain Driven development and Model View Controller) and frameworks (like Spring, Swing, Swiz and PureMVC).


3: More restrictions

From the start, OOP brings more restrictions: the use of strong typing, Classes, Class Packages, the availability of public and private variables, the explicit return types of methods. In contrary to loosely typed environments like Visual Basic and JavaScript you can no longer get away with generic types (var myVariableDoesNotNeedAType) or by just defining methods and Variables (function myFunctionWithoutReturnType).





Productivity curves


Procedural programming



Procedural programming: a lot of progress in the beginning, a drop in speed as you go

The lack of strict rules in Procedural Programming allows you to setup your application relatively quick in the first phase. You do what is needed in the most practical way possible.

As the project progresses, you might be re-using code here and there using Copy & Paste or some sort of classes. The drop in the speed of progress is mostly caused by: hidden bugs that only emerge when you test that specific part of the application, messy code (which is not exclusive to procedural programming), and repetitive solutions in copy/pasted duplicate code.




Object Oriented Programming



OOP: hardly any visible progress in the beginning, hard comeback at the end

When you look at the productivity curves of OOP and Procedural Coded Projects, the OOP Based projects are hardly showing any progress in the beginning. As the project progresses, the speed of progress in OOP projects (when executed properly) increases. The main reasons are found in the way the project is structured and elements can be re-used. Another important reason is the use of Strong Typing and the support your programming environment offers you in debugging issues before even running your program.


Refactoring and the time spent on complexity

One of the most important tools to keep the time spent on complexity in any code (Procedural and OOP) stable is the process of refactoring.


Why would the speed of progress increase with OOP?

The theory is something like this: because you encapsulate complexity and promote the re-use of functionality you only have to do things once. If you do this well, you reap the benefits as your project progresses. Instead of repeating lines of code, you use settings to enforce specific behavior. Instead of creating increasingly mounts of intertwined code with numerous dependencies that is hard to change you have loosely coupled code that is easy to restructure and refactor.


Can this only be achieved in OOP?

You can achieve the same results in procedural programming. Re-use, refactoring and encapsulation is not unique to OOP. Why OOP is seen as a “step up” in programming and associated to all these benefits is because it offers a set of tools, principles, patterns and constraints in coding that help you to achieve these goals with a solid structural base that is embedded in the languages you use. Concrete these tools, principles and patterns are (to name some but not all): Strong Typing (where your variables and methods are and return objects of a very specific type), extending classes, using Interfaces and using abstract classes. 



Messing up with OOP



Can you mess up with OOP?

You can mess up with OOP just as much (and maybe even more) as you can with procedural programming.  The biggest pitfall is over-complication. With all kinds of theory on Design Patterns and “How you should setup your code” it is easy to misunderstand the intentions of the writer and go for solutions that might look good when you read them but are complete overkill for the things that need to be done by your code: leading to 3 to 6 different classes with several methods and callbacks to do something you could have solved in 10 lines of code in one single Class.




How do you reduce the learning curve?


Work with people who already have experience

The best step is to work with people who already have some experience in OOP (and Design Patterns). They will help you get past the first hurdles and get going in the right direction.


Read the fucking manual

There are many books on OOP. Some are good. Some suck big time. Find the books that help you. Find the books that speak to you in a language you understand. Read this book, even though it is not perfect.


Read the source code of others

Use the code made by others as the source of your inspiration. Try to figure out what they are doing and how and why they do it. Focus on the parts that make sense only. Sometimes coders simply mess up even worse than you can imagine and you do not want to waste time on stuff that is already done wrong from the beginning.


Google for answers

Go and Google. Relentlessly. In principle you can find answers to all your questions as someone already asked them somewhere.


Study the Design Patterns on type and use

I started sorting Design Patterns on type and use. So based on “what do you want to do?” I made several lists including the Design Patterns that are fit for that use.





Why do we use it?


Control over complexity


OOP as the best solution to harness complexity

Object Oriented Programming (OOP) is currently the best way to structure and control the (emerging) complexity of any project. It uses concepts and metaphors that allow you to create code that is easy to expand, hard to break and easy to repair.


Mastering OOP: code remains simple while complexity grows

Once you get the hang of the basic principles of OOP, you will notice that the code of your projects will remain relatively simple even though the complexity of your project and your application can become increasingly bigger.



Re-use and better code


Basis: extraction, encapsulation and abstraction

One of the main pillars (for me, that is) on OOP and re-use of code is the principle of extraction, encapsulation and abstraction. The base of this approach is simple: isolate the code that performs a specific job, take it out of its current environment (extraction) and place it into a new and clearly defined container (encapsulation). The next step that follows is abstraction: making it so that the concrete actions are hidden behind an abstract point of entry (the method and method call and even by extracting it into a separate class).


Re-use: making code more generic

Each project has code that repeats the actions made elsewhere, but just a little bit differently. I refer to this as copy & paste code as that is how such code is usually built and started.

OOP principles (and the Design Patterns) help you to solve this kind of coding in different and more elegant ways. For instance by using generic code blocks in which you can inject specific “workers” that will do the specific job.


Less repetition: better code

The less repetition you have, the better your code becomes. The reason is simple: every time you change your mind about a specific solution, you only want to change this once. When you applied a lot of copy & paste coding, you will have to implement this new approach in several places. Especially when you are under pressure, this can lead to mistakes. Sometimes small enough not to be noticed much later. In other cases, leading to a crash & burn situation in which the only solution is a drastic rollback to an earlier version of your software.




More effective, so accept the learning Curve


Learning curve?

OOP has a relatively long Learning Curve. That learning curve does not lie in coding itself, but in how you and where you organize stuff to make your code and your project the best it can be.


Why? Level of abstractions

This Learning Curve has to do with the levels of Abstraction that you will introduce as your own experience grows.


Horrid documentation on OOP

Where do your start when you have no experience in OOP and nobody to show you? Most documentation you will find online and in books assume you have some level of expertise and some backup in the form of a teacher or coach. There is hardly any step-by-step guide that takes you through all the important places so that your first project is not the complete disaster it probably turns into, as OOP really adds a lot of new challenges.


My take to harness the curve: using the metaphor of a company to organization my code

The oh-so loved and hailed MVC did not work for me (see my breakdown of MVC via the link below). Instead I found the most helpful metaphor to organize my own code is the organization of a company. Most of your code deals with processes: getting things done by calling this or that. As both a company and your code need to make decisions and deliver results, both your code and an organization have useful overlaps you can use to simplify your Abstract Models.




Diving into OOP and (code) Architectural Patterns

The next chapter will handle OOP principles. In part 7 I will treat Architectural Patterns like the MVC Pattern, the Extended MVC Pattern, the (horridly named) MHOPUDO model, which stands for Manager, Handler, Operator, Parser, Utility and Data Object. Each has a very clear role and position within your structure.





What is it?


A model that reflects objects and processes

As many programs reflect processes and objects from the real world, OOP tries to hand you a model of programming that reflects just that: objects and processes.


Example: People, Buildings and Cars

A simple example is an application that deals with People, Buildings and Cars. The first classes you will create are the Classes: Person, Building and Car. Within each class, representing the object, you will then add behaviors and methods to those classes and objects. For instance:

Park Car in Garage – Where Garage might be a sub-set of Building


Connect Person to Car – Where the person will be attached to the Car as long as your program runs and nothing else changes


Isolate processes

The idea is to isolate processes and put them in the proper places. For instance, when we want to make the care “drive” from “A” to “B”, we manage that locally in the Car object.

All processes required to get “Car” from “Building” could be placed in “Car”, or other classes like “Navigator” accessed via “Car”.


Self-organizing objects

Where the power of OOP becomes visible is when we have two or more “Cars”, each navigating from one “Building” to another “Building”. Each “Car” can drive independently from any “Building” to another without any need of any management outside each “Car”.


Implications of self-organizing objects

This principle implies the following:

1: Scalability – As each “Car” (and object) manages itself, you can create as much cars as you want, and each “Car” will be able to navigate itself without increasing the complexity of your code or your project. The same goes for “Buildings” and “People”


2: Control over complexity – Since more “Cars” and “Buildings” will not lead to more complexity in your code (you can create as much as you like and your systems CPU and RAM allows you) you can create relatively large and complex systems where and while each individual part remains relatively simple





Peter Kaptein © 2012 Created: December 17, 2011 Last update: April 22, 2012

Refactoring and Design Patterns

Peter Kaptein


Last update: June 01, 2012



Chapters and Patterns marked with: ** are in revision

Patterns marked with a: * are not addressed yet



Downloads include: presentations and cheat sheets on Refactoring, OOP and Design Patterns.

No permission is needed to use this content to teach to classes or to use it within your company.


Sites and blogs

My Professional blog


Beyond the Keyboard

Blog posts on hardware hacking and tinkering


Internet of Things Framework


© 2011, 2012