Information Spilling Across Object Boundaries

Question

Many times my business objects tend to have situations where information needs to cross object boundaries too often. When doing OO, we want information to be in one object and as much as possible all code dealing with that information should be in that object. However, business rules do not follow this principle giving me trouble.

As an example suppose that we have an Order which has a number of OrderItems which refers to an InventoryItem which has a price. I invoke Order.GetTotal() which sums the result of OrderItem.GetPrice() which multiples a quantity by InventoryItem.GetPrice(). So far so good.

But then we find out that some items are sold with a two for one deal. We can handle this by having OrderItem.GetPrice() do something like InventoryItem.GetPrice( quantity ) and letting InventoryItem deal with this.

However, then we find out that the two-for-one deal only lasts for a particular time period. This time period needs to be based on the date of the order. Now we change OrderItem.GetPrice() to be InventoryItem.GetPrice( quatity, order.GetDate() )

But then we need to support different prices depending on how long the customer has been in the system: InventoryItem.GetPrice( quantity, order.GetDate(), order.GetCustomer() )

But then it turns out that the two-for-one deals apply not just to buying multiple of the same inventory item but multiple for any item in a InventoryCategory. At this point we throw up our hands and just give the InventoryItem the order item and allow it to travel over the object reference graph via accessors to get the information its needs: InventoryItem.GetPrice( this )

TL;DR I want to have low coupling in objects, but business rules often force me to access information from all over the place in order to make particular decisions.

Are there good techniques for dealing with this? Do others find the same problem?

Answer 1

We've had basically the same experience where I work and we've addressed it by having a OrderBusinessLogic class. For the most part the layout you've described works for the majority of our business. It's nice and clean and simple. But on those occaisions where you have buy any 2 from this category, we treat that as an "business execption" and have the OrderBL class recalculate the totals by traversing the objects needed.

Is it a perfect solution, no. We still have one class knowing way too much about the other classes, but at least we've moved that need out of the business objects and into a business logic class.

Answer 2

Sounds like you need a separate Discount object (or a list of them) that keeps track of all that stuff, and then apply the Discount(s) to the Order, something like Order.getTotal(Discount) or Discount.applyTo(Order) or similar.

Answer 3

It is perfectly okay to access data from other classes. However, you want this to be a one directional relationship. For example, suppose ClassOrder accesses CallItem. Ideally, ClassItem should not access ClassOrder. What I think you are missing in your Order Class is some sort of business logic that may or may not warrant a class such as Walter suggested.

Edit: Response to Winston's comment

I don't think you need an inventory item object at all...at least in the way that you are using it. I would instead have an inventory class that managed an inventory database.

I would refer to inventory items by an ID. Each order would contain a list of inventory ID's and a corresponding quantity.

Then I would calculate the total of the order with something like this.
Inventory.GetCost(Items,customerName,date)

Then you could have other helper function like:

Inventory.ItemsLefts(int itemID)
Inventory.AddItem(int itemID, int quantity)
Inventory.RemoveItem(int itemID, int quantity)
Inventory.AddBusinessRule(...)
Inventory.DeleteBusinessRule(...)

Answer 4

After thinking about this more, I've come up with my own alternative strategy.

Define a Price class. Inventory.GetPrice() returns a price object

Price OrderItem::GetPrice()
{
    return inventory.GetPrice().quantity(quantity);
}

Currency OrderItem::GetTotal()
{
    Price price = empty_price();
    for(item in order_items)
    {
         price = price.combine( item.GetPrice() )
    }
    price = price.date(date).customer(customer);
    return price.GetActualPrice();
}

Now the Price class (and possibly some related classes) encapsulate the logic of pricing and order does not have to worry about it. Price doesn't know anything about Order/OrderItem instead simply having information fed into it.