객체 경계에 걸친 정보 유출

종종 비즈니스 객체에는 정보가 객체 경계를 너무 자주 넘어야하는 상황이 있습니다. OO를 수행 할 때는 정보가 하나의 객체에 있고 가능한 한 해당 정보를 처리하는 모든 코드가 해당 객체에 있어야합니다. 그러나 비즈니스 규칙은이 원칙을 따르지 않아 문제가 발생합니다.

예를 들어 가격이있는 InventoryItem을 나타내는 많은 OrderItem이있는 Order가 있다고 가정합니다. InventoryItem.GetPrice ()로 수량을 곱하는 OrderItem.GetPrice ()의 결과를 합산하는 Order.GetTotal ()을 호출합니다. 여태까지는 그런대로 잘됐다.

그러나 우리는 일부 품목이 한 거래에 2 개로 판매되는 것을 발견했습니다. OrderItem.GetPrice ()가 InventoryItem.GetPrice (Quantity)와 같은 작업을 수행하고 InventoryItem이이를 처리하게함으로써이를 처리 할 수 ​​있습니다.

그러나 일대일 거래는 특정 기간 동안 만 지속됩니다. 이 기간은 주문 날짜를 기준으로해야합니다. 이제 OrderItem.GetPrice ()를 InventoryItem.GetPrice (quatity, order.GetDate ())로 변경하십시오.

그러나 고객이 시스템에 얼마나 오래 있었는지에 따라 다른 가격을 지원해야합니다. InventoryItem.GetPrice (Quantity, order.GetDate (), order.GetCustomer ())

그러나 일대일 거래는 동일한 인벤토리 항목을 여러 개 구매하는 것뿐만 아니라 InventoryCategory의 모든 항목을 여러 개 구매하는 경우에도 적용됩니다. 이 시점에서 우리는 손을 내밀어 InventoryItem에 주문 항목을 제공하고 접근자를 통해 객체 참조 그래프 위로 이동하여 필요한 정보를 얻도록 허용합니다. InventoryItem.GetPrice (this)

TL; DR 객체에서 낮은 결합을 원하지만 비즈니스 규칙에 따라 특정 결정을 내리기 위해 모든 곳에서 정보에 액세스해야하는 경우가 종종 있습니다.

이것을 다루는 좋은 기술이 있습니까? 다른 사람들도 같은 문제를 발견합니까?

우리는 기본적으로 내가 일하는 것과 동일한 경험을했고 OrderBusinessLogic 클래스를 사용하여 해결했습니다. 대부분의 경우 설명하신 레이아웃은 대부분의 비즈니스에서 작동합니다. 멋지고 깨끗하며 간단합니다. 그러나이 범주에서 2 개를 구매 한 경우에는이를 "비즈니스 실행"으로 취급하고 OrderBL 클래스가 필요한 오브젝트를 순회하여 총계를 다시 계산하도록합니다.

완벽한 솔루션입니까? 우리는 여전히 하나의 클래스가 다른 클래스에 대해 너무 많이 알고 있지만 적어도 비즈니스 객체에서 비즈니스 로직 클래스로 필요한 것을 이동했습니다.

당신 같은 소리는 모든 물건을 추적 별도의 할인 객체 (또는 이들의리스트)가 필요하고 뭔가처럼 주문에 할인 (들)을 적용 Order.getTotal(Discount)하거나 Discount.applyTo(Order)또는 유사한.

다른 클래스의 데이터에 액세스해도 괜찮습니다. 그러나 이것이 한 방향 관계가되기를 원합니다. 예를 들어, ClassOrder가 CallItem에 액세스한다고 가정하십시오. 이상적으로 ClassItem은 ClassOrder에 액세스하지 않아야합니다. 주문 클래스에서 누락 된 것으로 생각되는 것은 Walter가 제안한 클래스를 보증하거나 보증하지 않는 일종의 비즈니스 논리입니다.

편집 : 윈스턴의 의견에 대한 답변

적어도 당신이 그것을 사용하는 방식으로 인벤토리 아이템 객체가 전혀 필요하지 않다고 생각합니다. 대신 인벤토리 데이터베이스를 관리하는 인벤토리 클래스가 있습니다.

ID로 인벤토리 항목을 참조합니다. 각 주문에는 재고 ID 목록과 해당 수량이 포함됩니다.

그런 다음이 순서로 총계를 계산합니다.
Inventory.GetCost (Items, customerName, date)

그런 다음 다음과 같은 다른 도우미 기능을 가질 수 있습니다.

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

이것에 대해 더 많이 생각한 후에, 나는 내 자신의 대안 전략을 생각해 냈습니다.

Price 클래스를 정의하십시오. Inventory.GetPrice()가격 개체를 반환

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();
}

이제 Price 클래스 (및 일부 관련 클래스)는 가격 책정의 논리를 캡슐화하므로 주문에 대해 걱정할 필요가 없습니다. 가격은 주문 / 주문 항목에 대한 정보를 모르는 대신 주문 / 주문 항목에 대해 아무것도 모릅니다.