Thinking Object-Oriented (2 of 5)

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

This is the second of five articles written on object-oriented programming. These articles were originally written for http://www.jacwright.com/ This article was going to be entitled Conceptulizing Systems, but was changed to Thinking Object-Oriented as this title better describes the content of the article. I hope these are of benefit to you.

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.

9 Responses to “Thinking Object-Oriented (2 of 5)”

  1. joshbuhler.com » Intro to OOP Says:

    […] Part 2: Thinking Object-Oriented […]

  2. Utah PHP Users Group » Blog Archive » Planning systems (3 of 5) Says:

    […] 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. […]

  3. Utah PHP Users Group » Blog Archive » Creating objects (4 of 5) Says:

    […] In the previous three object oriented programming articles written for jacwright.com, we introduced object oriented programming, spoke of thinking about a system object oriented, and discussed the importance of planning, even if only in one’s head. The next two articles, Creating Objects and Reusing Objects, delve into the meatier subject of writing objects. We will be discussing how to implement the plans we’ve made and the systems we’ve conceptualized. Without these principles, object oriented programming can become a mess instead of a blessing. Encapsulate, Encapsulate, Dance to the Music (lyrics) […]

  4. John Holmen Says:

    But databases can also model the “nouns” of the domain. OOP authors often talk about the valuable addition of behavior that OOP adds, but if one looks at the actual actions needed, their association with the domain nouns is not always one-to-one. The close coupling of the two does not make practical sense. I would like to see clear-cut evidence that OOP is better than procedural in conjunction with a well-designed database. I see no reason to mirror the database entities in the application code as classes. That is extra effort and code that does not need to be there.

  5. Light Fittings Says:

    :’* I am very thankful to this topic because it really gives useful information ;,;

  6. Uqasxnye Says:

    prince william wales,

  7. Daniel Vergara Says:

    Nice article, I’ve learned the exactly what I need to my project.

    Thanks

  8. Darren Swiderski Says:

    All my life I’ve wanted to be someone; I guess I should have been more specific.

  9. Alton Says:

    Have you deemed adding extra videos to the blogs and keep readers more interested? I mean I just read over the article of yours and it was very fine but since I’m really a visual learner,I found that being more useful. Just my my idea, Good luck