|< Previous PageNext Page >|
There are a few key concepts you should understand when learning the Enterprise Objects frameworks. They are all rooted in good object-oriented design principles and many of them share ancestry with Apple’s Cocoa object-oriented application framework. Although understanding these concepts isn’t necessary to develop Enterprise Objects applications, familiarity with them helps you gain a better appreciation of how the technology works.
That said, there is a lot of information to digest when learning Enterprise Objects and you won’t need to put these concepts into use until after you know the basics. So you may want to skip this section and come back to it later on.
Key-value coding is a data access mechanism in which the properties of an object are accessed indirectly by key or name, rather than directly as fields or by invocation of accessor methods. It is used throughout Enterprise Objects but is perhaps most useful to you when accessing data in relationships between enterprise objects.
Key-value coding enables the use of keypaths to traverse relationships. For example, if a Person entity has a relationship called toPhoto whose destination entity (called PersonPhoto) contains an attribute called photo, you could access that data by traversing the keypath toPhoto.photo from within a Person object.
Keypaths are just one way key-value coding is an invaluable feature of Enterprise Objects. In general, though, it is most useful in providing a consistent way to access an object's data. Rather than needing to know if an object's data members have accessor methods, what the names of those accessor methods are, or if the data is accessible through fields, all you need to know are the keys that represent an object’s data. Key-value coding automatically finds the data, regardless of how the object provides its data. In this context, key-value coding satisfies the classic design pattern principle to “encapsulate the things that varies.”
Using the previous example, if you're working in a class that has access to a PersonPhoto object, you can get the photo data in the PersonPhoto object by invoking valueForKey("photo"). You don't need to know if the PersonPhoto object returns that data by providing an accessor method called photo or getPhoto, or through a field. Key-value coding is another feature of Enterprise Objects that reduces the amount of code you need to write and helps you write reusable business objects.
Advanced key-value coding concepts are discussed in:
In addition, the API reference for com.webobjects.eocontrol.EOKeyValueCoding and for com.webobjects.foundation.NSKeyValueCoding provide more detailed information on key-value coding.
Delegation is a way of extending a class in an object-oriented framework. Whereas subclassing means that you write a new class based on an existing class, delegation means that you make use of hooks that the class provides to change its behavior. In object-oriented design methodology, delegation is a form of class composition.
Delegation does just what it suggests: When you implement an object’s delegate, you are telling the object to use the behavior that your delegate specifies at specific points in an application's execution. So for example, in the case of an editing context object, if you write a delegate for this object, the editing context object checks your delegate at certain points in an application’s execution and uses the logic your delegate specifies instead of or in addition to its own. The pseudocode in Listing 2-1 illustrates delegation.
Compared to subclassing, delegation is usually a more elegant solution to extend or customize the behavior of a class. A class’s delegate provides hooks for those parts of a class that the class’s designer wants to be customizable. Furthermore, subclassing can be a tricky, tedious, and undesirable task for large classes that have many dependencies on other classes. Delegation reduces the amount of code you have to write and better ensures that your custom code will work, even when the delegate’s class is updated.
The objects in an application are no good on their own. It is the relationships and communications between objects that breathe life into an application. In a complex system like Enterprise Objects, it's common that a single object needs to communicate with multiple objects simultaneously.
There are any number of bad approaches to this problem and one remarkably good one: notifications. Notification allows for a loose coupling of objects—objects that need to communicate with one another don’t need to know about one another in advance. Rather, when objects need to communicate with one another, they rely on a notification center to manage their communications.
Enterprise Objects uses an object called a notification center to broadcast messages to objects in an application. Objects register with the notification center for specific notifications they want to receive. They also post notifications with the notification center when they want to notify other objects that a particular event occurred.
Figure 2-5 illustrates how objects and the notification center interact. A given object tells the notification center which notifications it’s interested in; it posts notifications to the notification center when its state changes; it receives notifications that it is registered to receive.
Figure 2-5 Notification center and its clients
Notifications are particularly important in the control layer. Enterprise objects often have relationships to other enterprise objects in the same editing context. When a value in one enterprise object changes, other enterprise objects in that editing context (and perhaps in other editing contexts, too) need to be told of the change. So, when a value in an enterprise object changes, that enterprise object's editing context posts a notification to let the other enterprise objects in that editing context update their data accordingly.
Notification creates a kind of dynamic nervous system within the object graph with the notification center as the brain of the system. You can think of the object graph as an organic system with many built-in feedback loops. As you begin to work with object graphs, you’ll find them to be a very natural way of thinking about data.
You may wonder about the differences between delegation and notification. With delegation, an object (the delegator) asks another object (the delegate) for a response before it performs a particular action (communication between objects can be forced and synchronous). Notification differs from delegation in that objects that post notifications don’t directly communicate with the objects that receive those notifications (communication between objects can never be forced and synchronous; object communication through notification is always asynchronous). With delegation, the delegate object has the opportunity to affect the tasks of its delegator, whereas in notification, objects don’t directly affect the execution of other objects.
|< Previous PageNext Page >|
Last updated: 2003-02-01