Determining Object Relationships

The first step in determining the relationships between objects is to figure out what you want to do with your objects because their purpose determines your design. When I was having a design issue one day, a project manager of mine said he looks at objects this way: If I was a car dealer working to sell a car, a tire would not be an object to me—the car would be an object because that is what is important to me. I would not care what the tire on the car is; however, if I was a mechanic working on the car, then the tire would be an object because I care who made it, what it is made out of, what its size is, and so on.

The same principle, which is just a matter of perspective, also applies to the Territory and Employee objects. If you look at the system from the employee perspective, then each employee is associated with one or more territories. Or, you can reverse that relationship and say that a territory has one or more employees (an employee is a part of a territory). Also, you could represent this relationship by relating the employee to the TerritoryMgr or by relating the territory to the EmployeeMgr. Again, it depends on how you want to display these objects to the user. For your purposes, when you build the Employee class, you will relate the employee to one or more territories and not vice versa. The reason for this is mostly logical. It just does not seem right that you assign an employee to a territory from the territory screen, but you would assign an employee to a territory when you are on the Employee screen because you are editing information about an employee.

The next thing is to determine when and why you would need a relationship. For example, when using the program, I do not particularly care which territory an employee belongs to. But when I run reports, I might want to create a report that summarizes what the sales were in a particular territory or region—for that I definitely need that relationship. But, you are not creating the reports from objects in your application—you are creating the reports from your database, so that object relationship is not as important. Another thing to think about is when you might need a piece of information. If I load up an Employee object and I need to know everything there is to know about the employee immediately after I load the employee object, then I need to examine my relationships more carefully because the Employee object would be an aggregate of almost everything. I would be telling myself that I do not want and cannot use my Employee object without knowing everything about the employee—that would make the Employee object an aggregate of everything. This is something that is independent of the interface; it is a rule that should be enforced in the business objects, but oftentimes how you design your interface determines these relationships. I have yet to find someone who has said that there is a hard and fast rule to these things. I believe object design is as much an art as a science, which means no two people will ever build object relationships the same way. This has worked for me on several large scale projects—it is not the only way you can do it, but it allows for a great deal of flexibility and is easily extended later without affecting other parts of your application.

The other thing to remember is the purpose of the application. This is an inventory system; it is not an HR system. The Employee, Territory, and Region objects are small parts of the system. If you did not know what region or territory an employee was part of, it probably would not affect your ability to create an invoice. The same goes for the employee with respect to an order. Many ordering systems use the Internet today, and there are no employees associated with an order when ordering from an Internet application. Regardless of anything else, the purpose of the application must always be foremost in creating object relationships.

Note

I have presented a couple of small arguments on how objects are related to each other. This is mostly so that you can see the type of thinking that must go into object-oriented design. I have often had long, confusing discussions with other developers as I was working on a system over precisely these types of issues. Theory is wonderful, and it does help, but determining how and when to relate an object is the key.

Most of the objects in this object model are for the purposes of filling combo boxes. For example, the Region list will fill a combo box on the territories edit form so that you can associate a region with a territory. The territories will fill a list box on the employee edit form so that you can associate an employee with one or more territories and so on. You can even look at the employee/orders relationship the same way. These objects simply associate themselves with other objects. Even the relationship between the Order object and the Order Detail object can work this way. However, the Order Detail objects cannot exist without their associated Order object.