It shows that you are unregistered. Please register with us by clicking Here
![]() |
|
![]() |
![]() | Register - FAQ - Today's Posts - New Posts - Support - Search | ![]() |
|
|
#2 (permalink) |
|
Member
Join Date: Jul 2006
Age: 28
Posts: 61
|
The most basic idea in OOP is that each object encapsulates some data and code. The object takes requests from other client objects, but does not expose its the details of its data or code to them. The object alone is responsible for its own state, exposing public messages for clients, and declaring private the ivars and methods that make up the implementation. The client depends on the (hopefully) simple public interface, and does not know about or depend on the details of the implementation.
For example, a HashTable object will take get() and set() requests from other objects, but does not expose its internal hash table data structures or the code strategies that it uses. The theme here is one of separation -- trying to keep the complexity inside one object from interfering with another object. Or put another way, trying to keep the various objects as independent from each other as possible. Each object provides some service or "interface" for the other objects. Ideally, the service is exposed in a way that is simple for the other objects to understand. The complexity of the implementation still exists, but it is isolated inside the one class. This works because for most problems there are all sorts of details of the implementation that the clients don't really care about -- how the hash buckets are arranged for example.. Inevitably, the interface that captures just the issues relevant to the client is much simpler than the full implementation. Looking at a whole program, we have many objects, each exposing a simple interface to the other objects and keeping the details of its own implementation hidden. With all the objects following this strategy, we get a divide-and-conquer solution to the whole program. Instead of a 1000 line program, we have a bunch of 200 line objects with minimal dependencies on each other. In this way, we escape the n^2 trap of writing and debugging large programs. |
|
|
|