Note that java has a "main" function, but not a "main" object.
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 useAs 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 useGenerally 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.
OOP Table of Contents---
Part of bolthole.com... Solaris tips ... ksh tutorial ... AWK Programming tutorial