Relationships -- when I use the term relationship, I mean the Unified Modeling Language (UML) concepts of association, aggregration, and composition -- are implemented via the combination of attributes and methods (operations). The attributes describe the relationship, and the methods define and update the relationship. In An overview of object relationships, I discussed the fundamentals of object relationships. Now I want to begin exploring how to implement them by starting with the easiest type of relationship: A unidirectional relationship with a multiplicity of one.

A unidirectional association is one that may be traversed in one direction only. For example, in Figure 1 you see a unidirectional association from Person to Address. You know it is unidirectional because the association line has an arrowhead pointing from Person to Address. The implication is that Person objects know about their Address objects, but Address objects don't know about the Person objects that live there. In the diagram, you see that Person has scaffolding code to maintain the association, in this case the homeAddress attribute and its corresponding getter and setter method (the code for which is presented in Listing 1).

The source code

One-to-one associations are always implemented as the combination of a simple attribute, such as an instance of an instance of Address in the case of the Person class, and a getter and setter method to manipulate that attribute.

		
/**
 * Gets the person's home address
 *
 * @return homeAddress
 */
 public Address getHomeAddress()
 {
      return homeAddress;
 }

/**
 *  Sets the person's home address
 *
 * @param homeAddress
 */
 public void setHomeAddress(Address homeAddress)
 {
      this.homeAddress = homeAddress;
 }

Back to top

Implementing business rules

It is quite common that business rules pertain to the relationships between objects. For example, the business rule "A bank customer can have no more than five bank accounts if they do not also have a brokerage account with our firm" pertains to the relationship between customers and accounts. Getter and setter methods are ideal places to implement this sort of logic, as well as applicable transformation logic pertaining to your data attributes. For example, Listing 2 presents an alternative implementation of the setter method of Listing 1. See how it first verifies the address object that it has been passed is valid, by invoking its validate() method and, if it is, then it sets the value of the homeAddress attribute. If the address is not valid, then it throws an exception.

/**
 *  Sets the person's home address
 *
 *  @param homeAddress
 *  @return homeAddress
 */
 public Address setHomeAddress(Address homeAddress) throws 
     InvalidDataException
 {
     // Only set the address if it is valid
     if ( homeAddress.validate() ) {
          this.homeAddress = homeAddress;
    }
    else {
        throw new InvalidDataException();
    }
 }

Back to top

Bidirectional relationships

Had the association been bidirectional, the Address class would have required the addition of a Person attribute, with corresponding getter and setter operations. Bidirectional associations are naturally harder to manage than unidirectional associations because they can be traversed in both directions. Here's a little secret: Maintaining a bidirectional association is just like maintaining two unidirectional associations. The only added complication is that you need to maintain them both in tandem. Implementing relationships with a many multiplicity, one-to-many, and many-to-many relationships, is the topic of the next tip in this series.

Resources

• Building Object Applications That Work by Ambler, S.W. New York: Cambridge University Press, 1998.
  
  
• The Object Primer 2nd Edition by Scott W. Ambler. New York: Cambridge University Press, 2001.
  
  
• The Unified Modeling Language Reference Manual by James Rumbaugh, Grady Booch, and Ivar Jacobson. Reading, MA: Addison-Wesley Longman, Inc., 1999.
  
  
• The Elements of Java Style by Vermeulen, A., Ambler, S.W., Bumgardner, G., Metz, E., Misfeldt, T., Shur, J., & Thompson, P. New York: Cambridge University Press, 2000.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• The source code
• Implementing business rules
• Bidirectional relationships
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers