Thông tin tràn qua ranh giới đối tượng

Nhiều lần các đối tượng kinh doanh của tôi có xu hướng gặp phải tình huống thông tin cần vượt qua ranh giới đối tượng quá thường xuyên. Khi thực hiện OO, chúng tôi muốn thông tin nằm trong một đối tượng và càng nhiều càng tốt tất cả các mã xử lý thông tin đó phải nằm trong đối tượng đó. Tuy nhiên, các quy tắc kinh doanh không tuân theo nguyên tắc này mang lại cho tôi rắc rối.

Như một ví dụ giả sử rằng chúng ta có một Đơn hàng có một số OrderItems đề cập đến một InventoryItem có giá. Tôi gọi Order.GetTotal () tính tổng kết quả của OrderItem.Getprice () nhân số lượng của InventoryItem.Getprice (). Càng xa càng tốt.

Nhưng sau đó chúng tôi phát hiện ra rằng một số mặt hàng được bán với giá hai cho một giao dịch. Chúng ta có thể xử lý việc này bằng cách yêu cầu OrderItem.Getprice () làm một cái gì đó như InventoryItem.Getprice (số lượng) và để InventoryItem giải quyết việc này.

Tuy nhiên, sau đó chúng tôi phát hiện ra rằng thỏa thuận hai đối một chỉ kéo dài trong một khoảng thời gian cụ thể. Khoảng thời gian này cần được dựa trên ngày đặt hàng. Bây giờ chúng tôi thay đổi OrderItem.Getprice () thành InventoryItem.Getprice (quatity, order.GetDate ())

Nhưng sau đó, chúng tôi cần hỗ trợ các mức giá khác nhau tùy thuộc vào thời gian khách hàng đã ở trong hệ thống: InventoryItem.Getprice (số lượng, order.GetDate (), order.GetCustomer ())

Nhưng sau đó, hóa ra các giao dịch hai đối một không chỉ áp dụng cho việc mua nhiều mặt hàng tồn kho giống nhau mà là nhiều giao dịch cho bất kỳ mặt hàng nào trong InventoryC Category. Tại thời điểm này, chúng tôi giơ tay và chỉ đưa cho InventoryItem mục đặt hàng và cho phép nó đi qua biểu đồ tham chiếu đối tượng thông qua các bộ truy cập để có được thông tin về nhu cầu của nó: InventoryItem.Getprice (cái này)

TL; DR Tôi muốn có sự kết nối thấp trong các đối tượng, nhưng các quy tắc kinh doanh thường buộc tôi phải truy cập thông tin từ khắp mọi nơi để đưa ra quyết định cụ thể.

Có kỹ thuật tốt để đối phó với điều này? Những người khác tìm thấy cùng một vấn đề?

Về cơ bản, chúng tôi đã có cùng trải nghiệm khi tôi làm việc và chúng tôi đã giải quyết nó bằng cách có một lớp OrderBusinessLogic. Đối với hầu hết các phần bố trí bạn đã mô tả hoạt động cho phần lớn doanh nghiệp của chúng tôi. Thật đẹp, sạch sẽ và đơn giản. Nhưng trong những trường hợp bạn đã mua bất kỳ 2 từ danh mục này, chúng tôi coi đó là một "hoạt động kinh doanh" và có lớp OrderBL tính toán lại tổng số bằng cách duyệt qua các đối tượng cần thiết.

Có phải là một giải pháp hoàn hảo, không. Chúng ta vẫn có một lớp biết quá nhiều về các lớp khác, nhưng ít nhất chúng ta đã chuyển nhu cầu đó ra khỏi các đối tượng kinh doanh và thành một lớp logic kinh doanh.

Âm thanh như bạn cần một đối tượng riêng biệt chiết khấu (hoặc một danh sách của họ) mà theo dõi tất cả những thứ đó, và sau đó áp dụng chiết khấu (s) vào thứ tự, một cái gì đó giống như Order.getTotal(Discount)hoặc Discount.applyTo(Order)hoặc tương đương.

Hoàn toàn ổn khi truy cập dữ liệu từ các lớp khác. Tuy nhiên, bạn muốn đây là một mối quan hệ một chiều. Ví dụ: giả sử ClassOrder truy cập CallItem. Lý tưởng nhất là ClassItem không nên truy cập ClassOrder. Điều tôi nghĩ rằng bạn đang thiếu trong Lớp Đặt hàng của bạn là một loại logic kinh doanh nào đó có thể hoặc không thể đảm bảo một lớp như Walter đề xuất.

Chỉnh sửa: Phản hồi bình luận của Winston

Tôi không nghĩ rằng bạn cần một đối tượng hàng tồn kho ... ít nhất là theo cách bạn đang sử dụng nó. Thay vào đó tôi sẽ có một lớp kiểm kê quản lý cơ sở dữ liệu hàng tồn kho.

Tôi sẽ đề cập đến các mặt hàng tồn kho bằng một ID. Mỗi đơn hàng sẽ chứa một danh sách ID hàng tồn kho và số lượng tương ứng.

Sau đó, tôi sẽ tính tổng số đơn đặt hàng với một cái gì đó như thế này.
Inventory.GetCost (Mục, tên khách hàng, ngày)

Sau đó, bạn có thể có chức năng trợ giúp khác như:

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

Sau khi suy nghĩ về điều này nhiều hơn, tôi đã đưa ra chiến lược thay thế của riêng mình.

Xác định một lớp Giá. Inventory.GetPrice()trả về một đối tượng giá

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

Bây giờ lớp Giá (và có thể một số lớp liên quan) gói gọn logic của giá và đơn hàng không phải lo lắng về nó. Giá không biết gì về Order / OrderItem thay vào đó chỉ đơn giản là có thông tin được cung cấp cho nó.