I like the example of objects in the classic book of java: Thinking in Java.
----------------
Type Name:
| Light |
----------- ----
Interface:
| on(); |
| off(); |
| brighten(); |
| dim(); |
------------------
| Light lt = new Light();
| lt.on();
The interface determines the requests that you can make for a particular object. A type has a method associated with each possible request, and when you make a particular request to an object, that method is called.
Here, the name of the type/class is Light, the name of this particular Light object is lt, and the requests that you can make of a Light object are to turn it on, turn it off, make it brighter, or make it dimmer. You create a Light object by defining a "reference"(lt) for that object and calling new to request a new object of that type. To send a message to the object, you state the name of the object and connect it to the message request with a period(dot).
One problem people have when designing objects is cramming too much functionality into one object. For example, in your check printing module, you may decide you need an object that knows all about formatting and printing. You'll probably discover that this is too much for one object, and that what you need is three or more objects. One object might be a catalog of all the possible check layouts, which can be queried for information about how to print a check. One object or set of objects can be a generic printing interface that knows all about different kinds of printers. And a third object could use the services of the other two to accomplish the task. Thus, each object has a cohesive set of services it offers. In a good object-oriented design, each object does one thing well, but doesn't try to do too much.
Monday, December 1, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment