Phils quick-n-dirty intro to object-oriented thinking #3 - when to use it

A VERY QUICK next section here; by request, here's a section on how and when to use Object-Oriented Programming.

GOOD PLACES FOR OOP

The classic "Graphics Object" class, which has subclasses "square", "triangle", "circle", etc, etc
Almost any application that has a lot of physical objects to be manipulated virtually. For example, a vending machine inventory program, that would have "merchandise" objects, inside a "vending_machine" object.
(There are other, more "interesting" examples, but it gets complicated to describe!)

See the "General Principle" section, below, for why the first two are good examples.

BAD PLACES FOR OOP

a slidescreen type demo (ie: a virtual movie)
a class called "main"

The first one is bad, because a slidescreen show is just a sequential list of operations. There is no obvious cohesion of elements.
The second one is bad, because it makes the top-level normal C function, "main()", an object, for no particular reason. Making something an object, does not automatically make it better.

Note that java has a "main" function, but not a "main" object.

General Principle

In some CS class or other, (probably software methodology), the following concept was brought up:
  Objects or modules should have high cohesion internally, and loose
  coupling externally.
Or something like that. The idea being, if you have designed your object correctly, it will be filled with highly-related things that are only internal to itself. That's high cohesion (or is it "coherence"?).
Loose coupling, on the other hand, means that you can do useful work with the object, with only a few member functions operating on it. External access to the object needs to know almost nothing about the internals of the class. You should aim to let an external function do what it needs to do, with a minimum of calls.
Note: That does NOT mean "1 function with a 10-member struct is better than 10 functions with 1 data-argument each"
If you find you are making a lot of the internals of an object visible, or directly changable by outside folks, then you most likely have either designed your object poorly, or have made the wrong choice of objects. Sometimes, there are multiple possible ways to break a program concept down into object. Not all of them will be as efficient as others.

Good object use
As given in the first "good places" example above, a good way to design an object class, is to represent a category of objects that may be slightly different, but for the most part, act exactly the same. The suggested "graphics object" would potentially have many operations common to all things of type "square", "triangle", "circle", and so on. For example, in a program that kept track of all these graphics objects, it is likely that it would need to do all of the following:

Draw, move, resize, rotate

Bad object use
Generally speaking, it is best to model your object design around objects, rather than processes. If your object description would most accurately contain a verb... it is probably not a good choice of object. Eg: "RunObject", "DrawObject", "HideObject", are all probably bad choices of an actual object class. It would be better to have them as member functions of a specific object instead.
Actions are best done TO an object, not AS an object.

Previous section: Static objects
Next section: A Game-Plan

OOP Table of Contents--- phil@bolthole.com
Part of bolthole.com... Solaris tips ... ksh tutorial ... AWK Programming tutorial