Where I work we have a number of applications that started out in VB6 and were ported to VB.NET. I can understand why those have the spaghetti code that they do, but then there are those application that were .NET from the start and still have such tight coupling, lack of cohesion, and lack of encapsulation that it baffles me. Since the advent of .NET the general discussion about Object Oriented software has migrated into the Business Application Developer sphere in a big way, but it seems that many developers have a hard time wrapping their minds around what that means.
Last week I had a set of conversations with some fellow developers about why some developers have a hard time thinking in OO. The conclusion I arrived at was not that the concept of OOP is so difficult, but that it is such a different mindset from what I call a linear mindset that people struggle to re-orient the well worn thought patterns they have developed. From my perspective the difference is between that of a linear thought process and a relational (or Object Oriented Thinking) thought process.
Many developers have a very fixed view of what they are trying to accomplish with their application (CRUD) and that drives there development. They want to create some data, retrieve it, update it. or delete it. This is a very linear type of process. In essence the developer is thinking more in terms of the workflow of the technology for doing CRUD operations than they are the relational aspects of the real world objects and inadvertently strap themselves into an application design that restricts their flexibility.
What a developer needs to train themselves to do is to create software that mimics the real world objects and then compose those objects into the workflows they need. This allows the developer to change the workflow without breaking the objects or change the objects without breaking the workflow. When we throw in concepts like interfaces and base classes it allows us to think not only relationally but also more abstractly about the categories of objects we have and how those larger categories interact and fit into the workflow.
So what does this mindset look like? Here’s an example.
You have a pizza you need delivered. From a linear perspective you can code a method that takes a delivery id and gets a pizza row back from the database, you create the pizza object, walk out the door, get a car from the database, find the keys, start the car, get directions to the house from the database, drive to the location, take the payment and save it to the database, return to the pizzeria. Or, you can create a delivery person object that accepts a pizza from the pizzeria (It’s the Pizzeria’s responsibility to compose the Pizza object). He can use a type of Vehicle to travel to a location (It’s the Parking Lots responsibility to hold the car object). Whether it’s an automobile or a motorcycle doesn’t matter, because the Delivery Person can participate in the transportation relationship with the Vehicle. He then interacts with a Customer object from which he knows how to receive payment. (He doesn’t have to save the payment to the database because that’s the responsibility of the Cashier). If we abstract the Delivery Person into an Employee that knows how to receive payment then we can inherit from that common Employee class and both our Delivery Person and the Cashier in the pizzeria can participate in the transactional relationship with customers though the Cashier object will be the only one that can put the money into the cash register (think store the money in the database).
This is surely a simplistic example and is not meant to be fool proof, but I think it adequately illustrates the difference between the two thought processes. Where as the linear thought process is more geared toward CRUD operations the Object Oriented approach allows for CRUD and also allows us to compose our objects into more complex workflows without having our business object and data access embedded in our UI. What we should be striving for in OOP is to develop a deeper and more thorough thought pattern of seeing software as a set of real world objects that participate in relationships with each other. We then utilize those objects to create our workflows and perform our CRUD operations.
One point I have to make clear is that I am not advocating that Object Oriented Thinking excludes linear thinking. Rather, Object Oriented Thinking contains linear thinking but is not limited to it. We have to use linear thinking to help us define the workflow branches, but we cannot allow that linear thinking to dictate the structure of our software. We must force ourselves to look for relationships between objects and then to use those objects as the components our workflow will act against and utilize to fulfill the business requirements of our customers.
Tags: object oriented, oop