DaWei Designs

What is an object?

Well, it ain't nuthin' but a thang. Bubbas of my acquaintance will use that expression to downplay the seriousness of an event or circumstance. An example would be getting one's leg shot off by an irate husband with bad aim. Dealing with the concept of an object is hopefully less serious than that.

Objects, and their design, were not invented by software gurus.

Object-oriented design was with us before the computer. I would consider the wheel a candidate, though its inventor probably thought polymorphism Programming: The ability to refer, at run-time, to different objects, according to varying circumstance. The ability of code to handle arguments of many types. The ability to use the same syntax for objects of different types.

Not invented by OOD high-priests

Biology: The existence of multiple forms of individuals within the same species (aside from gender differences).

A very useful capability on which a designer may capitalize. was a cross-dressing parrot.

One of my favorite objects, when I try to express the equivalence of objects and things (and their usefulness) is the carburetor. The modern fuel-injection system is more distributed, controlled by something that's maybe behind your glove-box, with the dispensing mechanisms in closer proximity to the intended destination, the cylinders. It is, indeed, more a system than a thing. The carburetor, on the other hand, exhibits just about the ultimate in "thinginess." Despite the variations one might find among the various sizes and kinds, their functions and their interfaces are essentially all the same. The designer was concerned with producing an explosive mixture that adapted to varying conditions. The precise location of the fuel and air sources, or the location of the remote throttle actuator, were of minor importance. It was only necessary that they be able to attach to the interface according to the designer's rules. Some other person could worry about how that was accomplished, or appeal to higher authority to have the design changed if the rules were overly stringent or impossible to follow.

Why are objects useful?

It is a mistake to think that the machine we are manipulating is intrinsically suited to solving our problems. It is not. Unless we can divorce the means of solving our problem from the implementation of that solution on our machine, we won't be highly successful in either endeavor.

Our problems are composed of contrary objects. If they weren't so recalcitrant, they wouldn't be problems. If we can model those objects on the machine, we can perhaps spot a solution more easily than if we try to decompose those problem objects into something they're not and seek a solution in some brute force way akin to fitting a square peg into a round hole with a sledgehammer.

Objects are useful precisely because they establish an equivalence between things in the problem space and things in the solution space. They also allow one to focus one's attention on accomplishing a particular function, with at least a momentary disregard of the companion functions that are necessary in the overall design of a solution.

The importance of that overall design is not to be downplayed. Someone needs to do it, and do it first. An automobile with a perfect carburetor and square wheels will be something less than highly marketable. Deciding it needs round wheels after distributing a couple million of them in the marketplace is an expensve alternative to thinking it through in the beginning.

The overall design will dictate what things, what objects, are necessary to achieve the primary goal. When that overall design is a fait accompli, the collection of individual objects will be relatively clear and the responsibilities for implementing them may be parceled out. If the same person is responsible for all the pieces, the explicit division into separate tasks makes the job less daunting. Once we have built an object we may close the lid and hide all its complexities away. We may stash a bunch of 'em on a shelf and use them as we please without further worry. We don't have to open the lid unless we just feel like tweaking them, souping them up, making a better mousetrap.

The use of objects, black boxes, little individual things, contributes to the effectiveness of the solution. The design and implementation effort will be easier and the overall outcome will be more satisfactory. Their usage aggregates the things that are specific to a piece of the problem. They live in one place, where we may keep an eye on them. When those things are gathered together and viewed as one piece, they're easier to comprehend. It is clearer how one should attach other objects in an effective way. It is easier to control undesirable side effects. It is easier to prevent unwarranted tinkering with the process. It is easier to isolate the cause of a failure.