如何在以下示例中優雅地分解兩個類？

假設我們採用使用面向對象原則構建自動售貨機的情況。如何在以下示例中優雅地分解兩個類？

讓我們假設我們有一個叫做VendingMachine的抽象。

class VendingMachine { 
    List<Slot> slots; //or perhaps a 2-d matrix of slots 
}

的自動售貨機類有槽的列表，並且每個時隙可以具有一些容量（以模型說5項一個在另一個後面）。

現在我該如何將Value（$）關聯到一個槽。很顯然，每個插槽將具有相同的項目，因此每個插槽應與相同的值關聯（或者更好地表示該項目的抽象，比如Item類）。

但是在責任方面，VendingMachine類應該只能彈出一個項目，或者試圖從空槽中彈出一個項目時拋出異常。我認爲，VendingMachine級別的職責不在於瞭解某個特定插槽的價值。

我該如何優雅地設計呢？是否有一些設計模式出現在您的腦海中。

我的解決方案是創建一個MoneyManager類。

class MoneyManager { 
    MoneyManager(VendingMachine vm); 
    Pair<Slot, Item> mapping; 
} 
class Item { 
    int itemCode; 
    BigDecimal value; 
}

即使您認爲建模是錯誤的，我更感興趣的是知道如何去耦這樣的2個類。

例如，如果你設計一個停車場，一個班級應該有車輛需要多少空間（點數）的信息。 ParkingLot有信息它有多少點。

但我不想讓汽車知道停放在哪個ParkingLot以及哪個位置。同樣，我不希望ParkingLot保持汽車停放狀態和位置。是否應該有一箇中級的ParkingManager維護這個狀態以獲得乾淨的設計？

來源

2017-08-14 rents

模型你需要什麼，不多不少。不必要的抽象比抽象的要少得多。抽象通常來自域的語言......我想我們可以說機器**庫存**或**庫存**已被補充？您也可能最有可能管理機器的**庫存**或**庫存**。庫存/庫存概念可能足夠重要，可以進行明確的建模，但不要引入虛構抽象或技術抽象。 – plalx

正如我上面所說的，我更感興趣學習如何在這種情況下解耦。這是一個思考練習。 – rents

你知道如何在你剛剛提供解決方案時解耦。除此之外，沒有人可以爲您提供正確的設計來解決沒有具體細節的假設問題。 – plalx

我認爲你需要的是某種邏輯，如wharehouse管理。

假設所有的插槽和項目都是相同的大小，你可能會這樣分解出來。

public class Item 
{ 
    public string Name { get; set; } 

    public string Category { get; set; } 
} 

public class Slot 
{ 
    public int Capacity { get; set; } 

    public List<Item> Items { get; set; } 
} 

public class Warehouse 
{ 
    public List<Slot> Slots { get; set; } 
}

這將管理倉庫的物品的基本分佈。 Warehouse類將管理插槽列表，並且Slot類將管理其包含的項目列表。

也許，如果您需要，您可以添加大小和位置並添加適合不同插槽的什麼樣的項目的邏輯。

來源

2017-08-14 20:36:04 bocanegra

如何在以下示例中優雅地分解兩個類？

回答

相關問題