Top down object oriented design

First we'll take a look at this from an abstract point of view, then we'll get on to the examples. Top down, object oriented design was originally conceived as an answer to the ever growing complexity of computer programs. With the demands of the military, aerospace, and the many other large industries that were exploiting the use of computer technology, computers software systems were becoming impossible to visualise. As computer programs began to run into hundreds of thousands, even millions of lines of code, modifications became ghastly nightmares and even the smallest of faults or mistakes could become major, expensive problems to solve.

With so much interaction between various sections of the programs it was impossible to track down sequences of events. An innocuous alteration to one small part of a program could have serious repercussions in others. This made modifications and corrections to a large system impossibly difficult. This problem was exasperated when programs became so large that the programming had to be divided up between several design teams. Then, an alteration by one team could present an insoluble problem for another team when the different sections of the full system were brought together.

A rationalisation of the programming procedures saw it as being necessary to separate large programs into parts that could function and be tested quite separately from each other. Out of this was born the programming technique known as OOPS (object oriented programming systems). This technique allowed the development of highly complex programming environments that could be regulated and controlled.

The essence of top down, object oriented design is basically very simple. The idea is that you take a planned system and break it up (decompose it) into separate parts (objects). These objects are connected to each other only by means of communication links. This requirement for communication links, necessitates that, for any component of a system to qualify as an object, it must have the means and ability to receive and transmit information.

The key to the success of this technique is the principle of encapsulation; this is where each object must be private to itself so that its internal working need not have to be known or understood by any other part. It is this element that is so foreign to the thinking of the Industrial Age where a preoccupation with standards and control precludes this possibility.

Considering e-commerce and e-business solutions in terms of systems of objects, each object might be seen as a black box that provides functions or services to other black boxes. The functions and services of the black boxes are provided as a response to messages received; the messages being accompanied by any relevant information (parameters) needed to carry out the function. Re-emphasising, because this is of paramount importance, each black box object is restricted only to communicating with other black boxes. It cannot make alterations, or, be able to interfere with the internal workings of any other black box

Taking this principle outside of the technical context of computer programming, would see black boxes as being ordinary everyday things like people, companies, departments, contractors, subcontractors, Web sites, computer programs, manufacturing processes, advertising agents, servers, shopping carts, electronic shopping malls, credit transfer software, programmers, graphic designers, etc. Any of these things can be considered as black boxes that can communicate with each other but not alter or interfere with each other's activities. Any e-business or e-commerce solution can be decomposed into a communication infrastructure and these kind of black boxes.

Confusingly, things that are called objects in the everyday world such as a Web page, a piece of artwork, an animation, a field of text, etc., are not considered to be objects in an object oriented environment because they cannot communicate. In an object oriented environment they are called components. Such components can only become objects if they are combined with an object that can communicate. Thus, an artwork isn't an object but an artwork combined with its artist is an object.

The concept of object oriented design can be very difficult to grasp without seeing several different kinds of examples. We'll start then by decomposing the business of the newsagent into black boxes. The newsagent's customers need not be aware of the complexity of the newsagent's strategy to provide them with newspapers. To them, the newsagent would simply be a black box that they could instruct to deliver newspapers to them each day. They don't know or care how this newsagent black box arranges this service: they just want it done. In his turn, the newsagent would see his customers as black boxes, each of which could fit into a component that was a newspaper round. He'd think of all of his delivery boys and girls as black boxes and he'd assign these to specific newspaper round to turn each round into a black box.

Having made these assignments into black boxes, the newsagent can forget details. He can arrange his delivery service at a higher level of organisation where the names of the customers or not relevant. He doesn't have to know whether or not the delivery boys and girls have new tires on their bikes or whether or not they've had breakfast before they come out. It's not important whether they are boys or girls. Paper delivery boys and paper delivery girls can all be considered to be black boxes that each have a statistical ability to carry out a part of a procedure that allows the newsagent to provide a reliable newspaper delivery service to his customers.

As simple as it seems from this example, it is not easy to decompose systems into appropriate sized black boxes. It is not easy to see how they can be linked only by means of communication. For this reason we'll now go through several other examples so that many different ways of applying this thinking can be appreciated. It is vital to do this because object oriented thinking is going to be as important to communication age strategies as hierarchical structuring was to the Industrial Age.

Let's start with a technological example to illustrate the principle of encapsulation: that all important and necessary characteristic for all objects in an object oriented environment. Imagine an e-commerce solution that involves a database. The database will contain some formatted or catalogued collection of items. It will also incorporate software that will be able to communicate with other software. It will include software that adds to, subtracts from, or modifies the records in the database. It is thus completely self sufficient: it is an object.

Object oriented design specifies that no other objects will be allowed to make changes to this database. If changes need to be made they cannot be made directly by any other parts of the system. Changes have to be specified and sent to the database object as the parameters of a message so that the database's own software can make the necessary alterations to the records.

In this way, a software object, acting as a database, will be like a factory stock room complete with a responsible stock room manager. The stock room manager will not let anyone go into the stock room to take components away or add components to the shelves. A responsible stock room manager will make sure that all deliveries go through him and he is the only one able to put things on the shelves. He'll also make sure that if anybody wants something from his stock room they have to ask him to get it for them. In this way the stock room manager is in complete control and will be able to ensure that his stock room is kept orderly and he will always be in a position to know what is in stock and where it can be located.

Similarly, another software object might be responsible for the information that goes onto a computer screen. This is the object's function. It keeps a record of what goes on screen and no other objects are allowed to alter or change the display at all. If another software object performs a function that requires a human observer to be made aware of something, the object must send the necessary information to the object that is responsible for the screen display and not make its own alterations to the screen.

In many respects, an object oriented system acts like an old style unionised factory where each type of worker is restricted to their own union's range of responsibilities and not allowed to encroach upon the responsibilities of others, i. e., only electricians would be allowed to do electrical jobs even if it is something as simple as changing a fuse. In the industrial world of high efficiency, such a restriction might seem ridiculously petty, but, in the world of objects it is crucially important.