In the real world, objects are made somewhere. If we want a new car, we go to the dealer and have them order us one from the factory. The factory will build our new car for us, and the dealer will deliver it. If we want to change something on the car, then we must take the car back to the dealer, who will then arrange for the repair. If we want to get some information on this type of car, such as how many were sold, we would ask the dealer. The dealer manages all of the services we will need performed on the car. Just like the car needs someone to manage all of the services related to the car, our components need a manager to manage all of the services related to the component. In the case of our components, this manager will be another class that performs these services on the clsCustomers class. Thus, in our two-class hierarchy we would have a managed (bottom) class, clsCustomers, containing all of the relevant properties that describe a customer:
Normally when we list the properties and methods of a component in a class diagram, a plus sign (+) means the method or property is public, a minus sign (-) means that the property or method is private and a pound sign (#) is used for friend properties (properties that can be seen by everything within the component but cannot be seen outside it). All of our customer properties and methods are public, so in this case we have omitted these signs.
The managing (top) class, clsCustomersManager, will contain all of the methods and properties that will be performed on clsCustomers:
We can perform this process for all of our components. Our Products component, for example, will have different properties but the same methods as the Customers component. Thus we will find that clsProductsManger may well be identical to clsCustomersManager.
When designing a Visual Basic class, all of the methods in the class should be services that the object created from the class will perform. If you have a method that performs a service on the object, such as AddNew, then it belongs in a separate managing class. Any property that belongs only to the object, such as customer name, should be in the class that belongs to the object. Any property that is shared amongst all of the objects, such as Count, belongs in a managing class.
Not all classes on the bottom of the hierarchy have only properties in their interface. If we wanted to build an animation program with an animated cat, the cat component might look as follows:
Walk, Meow and WagTail are all services that are performed by the cat object, not services performed on the cat object. Our managed class does not perform any services, so it will not have any public methods.
OK, so we have a two-class hierarchy consisting of a managed class (clsCustomers) and a managing class (clsCustomersManager). Together, the two classes would make up our Customers component. What happens, however, if we have more than one type of customer? Consider the following hypothetical situation. Different users at Northwind may actually need to look at different types of customers. For instance, a Sales Representative may need to view all customers during their working day; but a Sales Analyst at Northwind might need to look at all the customers who have made orders very recently. Or a rather interested Sales Manager somewhere may need to view all customers who are regularly spending over $1000 an order, say. In other words, each different user may need to view a different Customers collection. In this situation we would have to deal with three collections of customers. The best way to handle this would be to create a three-level class hierarchy:
So what's happening in this diagram? Well, if you think back to our two-level class hierarchy, you'll recall that we had a managing class and a managed class. In the diagram above, our managed class is represented by the rightmost collections of actual customer details. And our managing class is in the middle of the diagram, managing those collections of customer details. We've now introduced a third level class (the top class) - which itself manages what was our original managing class.
This is a fairly complex hierarchy. To actually build this component we would need to map out what each class would do and how it would communicate with the other classes. Bearing this in mind, you should not use hierarchies unless you have a need for them. If you find yourself building a hierarchy and the methods and properties all belong to one object, it is likely you should be building a single class. If all of the methods act on one class, and all of the properties belong to that class, then it is unlikely that you need a hierarchy.
A final point to note before we move on is that we can create, for example, a Products class hierarchy in a similar manner. If you recall, we noted that the public methods for this class would be the same as for the Customers class but the public properties would be different. When public properties are moved in to the bottom class, then clsProuductsManager will be virtually identical to clsCustomersManager.
We are still not at a stage where we know the exact design of our components. In Chapter 7 we discussed our reasons for choosing a three-tier framework for our project: scalability and upgradability. We now have to choose how to distribute our objects in within this framework.
Was this article helpful?