Because you will essentially implement VB-created components through classes, you will create the three types of members that
are available to a VB programmer in all component programming.
These three member types are as follows:
The following sections discuss the design of these three member types.
Designing Properties of Components
To identify component properties, you need to identify a component's attributes.
You will derive properties in different ways:
- Re-examine the usage scenarios for aspects of the objects that the application needs
to track. These attributes will be good candidates for object properties. A usage scenario may
speak of looking up a customer's credit balance, for example. This would imply that
Credit Balance is a property of the Customer object. More subtly, it would also mean that
you need a unique way to identify each customer: Customer ID would therefore be another property.
- As you validate the Logical Model during the component design process, you
will find that items you may have initially identified as business objects in
their own right are really attributes of other objects. During logical design,
the nouns "Customer" and "Contact Person" may be identified as objects, for example.
Further consideration will uncover the fact that a Contact Person is best stored
as an attribute of a customer. You would therefore specify Contact Person as a
property of the Customer object.
Designing Methods of Components
A method is an action or behavior that the object performs. You can identify an object's methods by
-
Reviewing the usage scenarios. Behaviors of objects that the usage scenarios mention can become methods.
-
Identifying interactions between objects. When an object needs to cause a second object to do something, you have identified a method of the second object.
Designing Events of Components
An event is a message or notification that an object sends to the system and that can
be detected.
One way to identify events is to review the methods that you have defined for
an object. If it is clear that a method should run in response to some other behavior in the
system (either from the same object or from another object), you have identified an event. You can
design events to encapsulate the behavior of objects to make it unnecessary for objects to manipulate
each other directly.
If an object such as SalesOrder completes some action, such as completing
a detail-line entry, for example, it might require a second object, Inventory,
to update its QuantityOnHand property. The Inventory object might have an UpdateQOH
method. Instead of requiring the SalesOrder object to have direct knowledge of
the Inventory object and its methods, you could define an event for the SalesOrder
object, EntryComplete, that would signal a change to the SalesOrder object. A
programmer using your component could then decide how to react to that event,
perhaps by calling the UpdateQOH method.
