Object Oriented Programming

Object Oriented Programming

Thinking Object-Oriented

Real Power

One of the more difficult jumps of the several leaps and bounds from procedural to object-oriented programming is conceptualizing the system you are programming. Thinking object-oriented is the real power of object-oriented programming, and even if we always program procedurally we may already be thinking object-oriented. We need to be able to see a system, a problem, or a program in terms of objects and their relationships to one another. When we do this any program will be much more simple and easy for us to grasp. It will be easy to picture how it works in our minds.

There are three ways to think object-oriented. One way it not better then another. They are all just different and each of them is used as we start use objects appropriately. I call these three ways the Top Down approach, the Bottom Up approach, and Real World Modeling.

Top Down

The Top Down approach in object-oriented programming give us a way to see the system as a whole. We break the entire system down into related parts. The Model-View-Controller design pattern (we’ll talk about design patterns in a later article) is an example of this. It breaks the system into three parts: objects related to the business model, display objects, and objects to handle user input.

When we use the Top Down approach we need to think of how the system can be broken up into logical pieces. We can slice up the entire system like I do a pie. First I slice the pie in half, then in half again, making four pieces, then in half again. I end up with nice evenly sized pieces, something I’ve never been able to do by slicing a piece at a time. Similarly with a program or system (which might be a small part of a larger system) we break it up into larger pieces, then smaller ones, then even smaller ones, until we have pieces of a manageable size.

We can see the Top Down approach thinking with a short example. Let’s use the oh-so-common ecommerce store. If we think of the system as a whole we know there will be data to keep, store functionality, and a good looking design that we want to change once in awhile. We can break our data section down into session management and a database object. We might break our store functionality into sections like the catalog, product reviews, the shopping cart, and the checkout. We can have our display section broken down into a general template and a caching template that will cache pages for reuse (so the database doesn’t have to work so hard). We can then go over each of the functionality sections and further break them down into small pieces and objects.

Bottom Up

The Bottom Up approach does not look at the system as a whole. Instead, it concentrates on grouping related functionality together. We see functions and variables as related and so put them together into an object. Then we see objects which interact or are related and put them together into a group (called a package, usually put into the same folder etc.) We can then group those object groups into larger and larger groups until we have the whole system accounted for.

Using this approach to think object-oriented we use two different steps. The first step is grouping functionality into objects. The second step is grouping objects into groups. For step one, we figure out what goes together. This can be easy if we already group our related procedural code into files. We may have a file that contains all of our database functions in it. Instead of having all the functions there sitting in the global scope and the variables they use (perhaps a connection variable, or a record-set variable), we can group it all into a database object, with properties such as the connection reference and functions such as query or closeConnection.

The second step is similar to the Top Down approach, just backwards. Instead of breaking a system down into parts, we are building it up from the pieces we know we will have. Grouping objects into larger and larger groups until we have the whole system makes it much easier to picture the internals of a system in our mind, and how things are actually working. It also allows us and others to easily find pieces of functionality to extend or fix because they are organized into folders and files (packages and objects) in a logical manner.

Model the Real World

Finally, Real World Modeling is one of the most powerful aspects of object-oriented programming. This is making objects that you know in the real world into objects in your system. Because we all live in the real world, it is easy for others to immediately understand what an object is and does if it is based off of something real world.

A customer, shopping cart, and product in an ecommerce store are immediately recognized and their interactions between each other are understood easily, because we can see the same interaction in our daily lives. We know that there can be many products in our shopping cart. We know that each customer may have a shopping cart to put their products in. We know that customers have names and addresses, and that products have names and prices. The programmatic shopping cart however may have related functionality that a real shopping cart may not have. It may be able to tell us the total price of all the products in it, where a real cart can’t do anything but roll around (something not needed in an ecommerce store).

The first thing you might do when developing a system is to discover all the real world objects in that system. Whether it is employees, supplies, offices, text characters, documents, buttons, or trash cans, they all help us think of the system easier and model it better. We already know many of the objects’ interactions and who “owns” what (the customer owns the shopping cart and the cart owns the products). These real world objects may even be the groupings of objects instead of the objects themselves. Or they may be objects that help group others. You might have a department object with its employees and manager.

Once you have the real world objects you can then group them. The shopping cart, order, and checkout might go into the same section. You may put products and categories into the catalog group. Customers and store admin may be their own group.

Object-Oriented Thinking

Object-oriented thinking has been around even before object-oriented programming. People do it without knowing it might be called object-oriented. It helps us conceptualize a system and better grasp it. It helps us wrap our mind around a system without blowing a fuse. It makes programming easier for us and easier for others coming to our code. Object-oriented programming was created to make it easy to transfer our object-oriented thinking into code, although we can still program procedurally our object-oriented design. This is the real power of object-oriented programming.