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
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.
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.
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.
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.
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.
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.
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.
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
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”.
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
Refactoring and Design Patterns
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
Blog posts on hardware hacking and tinkering
Internet of Things Framework
© 2011, 2012