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.