我目前正在計劃一個新系統的設計,我需要編寫與後端API交互的代碼。我正在考慮對象的組成和繼承,並決定在我的情況下最正確的過程將是與繼承的構圖一起去,因爲我的對象彼此具有「有」關係而不是「是」。使用Perl的OO設計模式
我現在發現雖然由於某些對象依賴於其他對象,因此可能存在「對象A」具有屬性「對象B」和屬性「對象C」 - 但是「對象B」也具有屬性「對象C」。
在希望這種類比會更有意義:
可以說我有賣盒子包含它們的內貓,放射性物質可能會或可能從未反應的公司:
我賣我產品到組織。用戶通過指定他們所屬的組織來向我註冊。一個組織可能有很多用戶或沒有用戶。用戶必須擁有其所屬的組織。我跟蹤我的產品(箱子作爲一個實體,貓作爲一個實體)以及它們屬於哪個組織。我也跟蹤貓和他們在哪個盒子。一個組織可能有許多箱子,其中有許多貓。盒子可能是空的。一些用戶被允許購買新的盒子,而其他人則被允許看着他們。
驗證&授權全部由我與之交互的API管理。
至於對象關係去:
$user has a => $organization that it belongs to
$user has a => $role that dictates what it may or may not do.
$box has a => $organization that it belongs to
現在
:
$cat has a => $box that it belongs to
和
$cat has a => $organization that it belongs to ?
OR
$cat has a => $box that it belongs to WHICH has a => $organization that it belongs to
這裏正確的設計決定是什麼?有沒有其他方面我不考慮哪一個可能使一個選項比另一個更可行?
我將在此係統中使用Perl Catalyst
和Moose
實施MVC
設計模式。
謝謝大家的貢獻。
嗨有。首先謝謝你的回覆。你的說法是有道理的 - 這將使我能夠在整個系統中保持一個整潔的設計模式。我只會設計對象來關心直接影響他們的東西,並丟棄它不需要的鏈條上的任何東西。如果我在這裏有足夠的街道信貸,我會給你一個投票。一旦我達到了15的信譽標記要求,我會回來投票:) – nmap911
@ nmap911 - 如果答案有幫助,你可以(也應該:)也標記爲「接受」(checbox左邊)。很高興我能提供有用的反饋意見 – DVK
非常好,感謝您的支持。有標記 - 我現在也獲得了街頭的信譽,所以有了投票權 – nmap911