Planning Systems (3 of 5)

This is the third of five articles on object oriented-programming.

Object-oriented programming gives us many new ways to create an application. It makes many things easier to do. One of these things is planning. Planning is an important and oft overlooked part of an application, but it is as essential to the success of the application as the coding of it. Just to clear the air, let me clarify that planning is not necessarily spending months of sketching diagrams before a two week project. Neither is it coming up with things as you go. But planning is a great tool that will make applications more solid, easier to build, and quicker to build.

Four Story Lean-to

I spent some time in other places of the world. One of these places was Malaysia, great country. During my visit I traveled to many of the poorer areas of the country and one particular community stands out in my mind. In Tawau, East Malaysia there was a whole subdivision of houses built out over the ocean on sticks. The houses were shacks, built with driftwood and covered with tin. The walkways between the homes were also driftwood and just nailed together in random fashion. Being five times taller and three times less skinny than the largest man there (maybe that’s an exaggeration) didn’t make me feel any more comfortable walking around out there. It was obvious there had been no master plan, no idea of how the houses would be put up. But hey, it saved on property taxes.

These homes were not built to last, nor would it be easy to add new homes to the community or upgrade existing homes. And there was definitely a lot of upgrading that could have been done! Similarly, if we try to build mansions of sticks, four story lean-tos, or even a modest home with no plan, our applications will end up looking (and working) more like the forts and tree houses my brother and I built in the field behind our house.

I think all of us have built applications like this and know the pain and the bugs and quick-fixes that need to be made for the application to even work. Even after that it doesn’t end up being something you are proud to show to others (unless, of course, it’s one of your very first applications, in which case it is amazing that you got something to work at all and you want everyone and their grandmother to see)

In addition to giving us a nicer product in the end, planning allows us to “share the wealth” with other programmers, so to speak. We are able to help everyone see the master plan and their part in it. We are able to have more than one developer work on it at a time. Pretty innovative idea, I know.

So how should we plan? However we want. You don’t need to use UML to plan. You don’t need systems design and analysis training. You just need to sit down with some paper and start writing (or drawing) an idea of how the application will fit together. You could even just take a moment to think it through without any writing utensil for smaller projects. We will go over how to organize, what to reuse, and what we should use while we do it (our brains).


The definition of organize as Google™ tells us is “formed into a structured or coherent whole; methodical and efficient in arrangement or function; arranged into definite structures.” We need to know where things are, where they are going to be, and how to find them. We also need to know how they are going to work together. Object-oriented programming is great for this because it give us a way to plan called object-oriented design. I discussed in the previous article Thinking Object-Oriented how we can visualize systems in terms of real-world objects. This is what object-oriented design is aimed at doing. We plan out the system modeling it after the real world. We imagine our ecommerce store is a real store and plan out the system based off of how a real store works. We think of our intranet as it were the company’s actual organization and plan it out into departments with their managers and employees. We are able to plan a system much more easily because we live in the real world (well, most of us anyway) and are familiar with objects, items, things, and stuff in our everyday lives.

When we create an object we need to consider that is might be reused elsewhere. This means that it shouldn’t rely on system specific things to work, and if it does, there should be a known (and good) reason for it. This kind of separation from the environment is called encapsulation and is an excellent way to make an object reusable, as well as easier to maintain and update.


I don’t know how many times I’ve heard “let’s not reinvent the wheel,” but it’s been a lot. Many times it’s been with valid points. Many other times it hasn’t been. Let me first explain what we should reuse (and shouldn’t) then I’ll go over why object-oriented programming allows us to reuse code more easily than procedural programming.

What is a classic example of something that uses a wheel? A car. Do we ever use a wheel by itself? Not often. When we “reinvent the wheel” we are recreating something that has been done by many others before. However, I would like to emphasize that it is not creating a custom application again. A car is made up of many reusable parts, but we cannot take an economy car and make a four-wheel truck with it. We should build applications with reusable parts, and if our new application is to be the same or similar to another, then we can take the old and tweak it up a bit, give it a new paint job.

The reason why I am even going over this is because of many bad experiences in the past. It seems many development teams want to try to take an existing system and create their own custom application with it. “Why reinvent the wheel?” In every instance it has taken much longer to try to integrate with the existing database, to try and force the application into strange contortions, to try and add “a few additional features” (which end up doubling the features) then it would have been to step back, plan out the system from scratch, and rewrite it from scratch (hopefully reusing many _parts_ or pieces of other applications).

Ok, enough with that. Why is object-oriented programming more reusable than procedural? Well, again it goes back to things being easier to think about. If you are looking to put a stick-shift into your new car, you ask for a stick-shift and you get a stick-shift as well as all that goes with it. You’ll get the numbers of the gears, the methods to shift and put into neutral, all of it. If it were procedural you would need to get each method separately (although they may be sitting next to each other) and make sure you don’t forget what and where the properties are. If you need a customer in your store you could grab it from another store. You don’t need to search for all of the parts scattered throughout the store. In addition, if you need to change the customer, you only have one place to do it. And again, it’s much easier to think about the system as objects and how you might reuse the parts.

It is much easier to find things in an organized room, and object-oriented programming provides greater organization for an application than procedural programming.


Now, many who are weary about using object-oriented programming are such because they have seen horrible programming that used classes, methods, and properties. They feel their procedural programming is ten times better, and they might be right. Object-oriented programming is no magic hack. It is not a cure-all. No matter how we program, to make good programs we must use your brain. I know, I know, it sounds like too much to ask. Actually, I think all of us know we may write code without much forethought of how it needs to work or turn out. We often can make it work too, just not as well as it should.

We must think about where we are going and what we are doing when we program. Even if we don’t have a written plan, we need to think the system through before hacking away. Thou shalt not be mentally lazy is a commandment I give to us all.

I wish us all luck as we build our mansions or high-quality single family homes. If we are committed to planning we will end up with nice products in the end.

10 Responses to “Planning Systems (3 of 5)”

  1. Andrew Says:

    Wow. Good stuff. What is UML anyway?

  2. Jacob Wright Says:

    UML stands for Unified Modeling Language. It is a standard way to draw models of an application.

  3. Paul Lamonby Says:

    Very interesting articles, Im just learning OOP and this is the best ‘real-world’ example I have read so far.

    But 1 question (well several really, but…) is always at the back of my mind, When you are planning a project in OOP, do we think only about that project when writing ‘re-useable’ code, or do we also think about future projects that could ‘re-use’ the code?

    The reason I ask is that most of my applications are small, bespoke and unique games. (I use game development as a way of testing new practices and ideas, I find games a good way to focus on planning, coding, UI, etc and all in a fun way with a useable product at the end.)

    To learn OOP I am re-writing some of these games to integrate classes, but I am finding that the classes are only relevent to each game, so therefore I am wondering if I need to use them at all, when the 9 or 10 existing functions work the game fine?

    I still want to put them into OOP just as a learning tool, but have you found a limit as to when OOP is needed and when not?

  4. Jacob Wright Says:

    Good question. I will discuss more about reusing objects in the final article of the five written on object oriented programming. To answer your question however, the base reason for object oriented programming as discussed in the introduction is for organization. Reuse is made easier with it. But making an object reusable takes more time. If it will not be applicable to more than one application, it does not need to have any extra effort spent to be made reusable.

    In addition, there are times when the code is simple enough that throwing together a procedural script is faster and better than doing it object oriented.

    Do you find yourself ever copying and pasting code from a previous project? Or do you rewrite code from another project? These are times that a reusable object may help. For example, my brother wrote a 3D engine object that would help him make 3D stuff in Flash for whatever project he is working on. You may want a reusable score keeper object or a connection object that regulated the data of two players so that they may play a game against each other.

    I hope these may answer some of your questions. Good luck OOPing!

  5. » Intro to OOP Says:

    […] Part 3: Planning Systems […]

  6. hiren Says:

    only one question : why didn’t you showed any code in all five articals ?

  7. Jacob Wright Says:

    Because I wanted the articles to be language neutral. The biggest thing I was attempting to instill was a different way of thinking, of picturing a system in your mind. Code will come later. :)

  8. Ashley Says:

    Reuse is the best part. I strongly suggest it in all the places. You can never good at creation if you are not good at avoiding to create one but by reusing something else.

  9. Tahiya Says:

    Nice. I’m just getting into Actionscript and found my way here as a designer/graphic artist/elearning creator rather than programmer. It seems you are one of the few people able to include contextual cues in your explanations of OOP. So much of what is out there tries to SHOW you OOP or get you to come along and see 10000 examples of it working so you’ll “get it”. It seems to me there is a real derth of experts who can place their understanding of OOP in a bowl non-programmers can “eat” from. Either that or the people who are experts are the kind of thinkers who go FROM specifics TO general principles instead of the other way around. Good teachers can take students back and forth in both directions to stitch it all together. You’re definitely on the right track.

  10. Jordan Says:

    Hey, I may be a little late but incredibly awesome tutorial! I loved the explanations, and of course your commandment too!