- Design Principles for Checking Business Rules
- Designing Business Rules Checking
- Property Write Accessors with Business Rule Checking
- Collaboration Accessors with Business Rule Checking
- Conclusion
Collaboration Accessors with Business Rule Checking
With collaborations, business rule checking gets more complicated because there are two objects involved: the object establishing or removing the collaboration and the object that is the collaborator. Both objects typically have their own set of business rules checking, whether the collaboration can be established or removed.
A collaboration can be either single-valued, as a sale order having only one broker; or multi-valued, as a broker having many sale orders. We use the same implementation pattern for both types of collaborations because over time, a single-valued collaboration can potentially evolve into a multi-valued collaboration. This often happens when the system decides to keep history about past collaborations (see Table 3).
Table 3. Methods for Changing the State of a Collaboration X
addX(anObject) |
Public write accessor to add anObject as an X collaborator. |
testAddX(anObject) |
Business rule method to validate that anObject can be an X collaboration. |
doAddX(anObject) |
Assignment method to assign a reference to anObject as an X collaborator. |
removeX(anObject) |
Public write accessor to remove anObject as an X collaborator. |
testRemoveX(anObject) |
Business rule method to validate that anObject can be removed as an X collaboration. |
doRemoveX(anObject) |
Assignment method to remove a reference to anObject as an X collaborator. |
Collaboration Write Accessors Example
In the online commodity system, business rules dictate whether a broker can be assigned to a sale order. A broker on leave or vacation cannot collaborate with a new sale order, and a broker with too many pending sale orders cannot collaborate with a new sale order. A sale order cannot remove its broker; however, it has a special business service, swap broker, which bypasses this rule and replaces its broker with a new one, provided the new broker passes all the business rules
A partial listing for the sale order's collaboration write accessors is shown in Listing 2. Notice that the public write accessor calls the business rule test methods and the assignment methods in both the sale order and the broker. The business service that swaps brokers is shown in Listing 3. The swap service removes the broker without checking the business rules, but restores the original broker if the business rules fail for the new broker.
Listing 2. Collaboration Write Accessors for Sale Order
/* PUBLIC ACCESS METHODS */ public void addBroker(Broker aBroker) throws BusinessRuleException { if (aBroker == null) { throw new BusinessRuleException("Cannot add null broker."); } this.testAddBroker(aBroker); aBroker.testAddSaleOrder(this); this.doAddBroker(aBroker); aBroker.doAddSaleOrder(this); } /* BUSINESS RULE CHECKING METHODS */ public void testAddBroker(Broker aBroker) throws BusinessRuleException { if (this.broker == null) return; else { throw new BusinessRuleException("Sale order already has broker."); } } public void testRemoveBroker(Broker aBroker) throws BusinessRuleException { throw new BusinessRuleException("Sale order cannot remove broker."); } /* ASSIGNMENT METHODS */ public void doAddBroker(Broker aBroker) { this.broker = aBroker; } public void doRemoveBroker(Broker aBroker) { this.broker = null; }
Listing 3. Business Service Selectively Bypassing Remove Collaboration Business Rules
/* BUSINESS SERVICES */ public void swapBroker(Broker newBroker) throws BusinessRuleException { if (newBroker == null) { throw new BusinessRuleException("Cannot have null broker."); } Broker oldBroker = this.broker; this.doRemoveBroker(oldBroker); try { this.testAddBroker(newBroker); newBroker.testAddSaleOrder(this); } catch(BusinessRuleException excptn) { this.doAddBroker(oldBroker); throw excptn; } this.doAddBroker(newBroker); newBroker.doAddSaleOrder(this); }