何處放置處理兩個類之間關係的方法？

在我的應用程序中，我有產品在生產線的車站之間旅行。記錄站內產品的每次通過記錄：失敗成功。產品和電臺之間的關係是多對多的。何處放置處理兩個類之間關係的方法？

如果我是在程序語言編程我想有以下功能：

get_last_pass_result($station_id, $product_id) {...}

返回的上一次出現這種特定產品這個特定的站傳遞的結果。

現在你將如何在OOP方面這個邏輯模型？我肯定會有班級，班級的產品。但我應該做的（PHP語法）：

$station->get_last_product_pass_result($product_id)

或者

$product->get_last_pass_on_station_result($station_id)

的情況似乎對稱的，我不知道是什麼因素存在，那麼這兩者之間決定

（或者甚至是一些第三方解決方案嗎？）

我無法在這裏提供有關該域的所有現有信息，但可隨意添加以下注意事項：if [關於域的假設]然後[您的設計解決方案]，如果感覺合適

來源

2013-03-14 shealtiel

我取，但基於DDD的原則，所以我不知道這個適合你的需要，但無論如何...

所以，你有一個站和產品。我會說，他們是兩個實體，可以有引用到對方，但是你所談論的邏輯包括這些實體很可能被放在一個域名服務像ProductPassingService與操作像GetLastPassFor（產品，站）。

您正在訪問的服務必須使用底層域實體火車站和產品（和存儲庫查詢它們），執行不屬於要麼站和產品邏輯責任。它使實體站和產品保持了太多的責任。

此外，域實體不應使用庫（DDD - the rule that Entities can't access Repositories directly）所以這個邏輯屬於某個域的服務。

來源

2013-03-14 08:03:02

我喜歡這個答案。即使感覺背後有一個複雜的想法，我可能想要或不想採用 – shealtiel 2013-03-14 08:22:55

@shealtiel你是否知道DDD？ – 2013-03-14 09:21:02

@Zdeslav Vojkovic，不，除了在看到它的答案中提到的維基百科頁面之外。我對潛入更多更概念化的河流有點小心，除非它們非常集中並且廣泛同意（如MVC） – shealtiel 2013-03-17 12:11:17

我建議把它的產品。我擔心的是產品的數量很大，但是這些工作站應該是固定的，並且將特定產品的狀態記錄在該產品的對象中是很自然的。對於該臺，它可能只需要記錄一些統計數據。

來源

2013-03-14 06:42:19

產品和工作站之間的關係是多對多的，因此不可能*存儲有關產品傳遞的數據。我在問哪裏把方法 – shealtiel 2013-03-14 06:50:33

我不完全清楚Product是代表產品（例如椅子）的類型還是產品的單個實例（例如，椅子001，椅子002）。從你的例子看來後者就是這種情況，所以我會使用它，否則get_last_pass_result沒有多大意義。

我相信，我會介紹Path型（不知道很多有關領域，雖然）。現在，根據其他用例，這可能是一個聚合根（DDD術語）或不是。

這意味着它可以通過Product實例或直接從DB/repository/whatever訪問。隨着路徑例如，我可以簡單地做：

var path = product.GetPath(); // if it is accessible only via product 
var path = Path.GetPathForProduct(product); // or pathRepository.GetPathFor(), or ... 
var result = path.LastResult;

這種方法從產品本身的解耦工廠過程，並允許其他一些情況下（例如，發現平均時間，等...）

來源

2013-03-14 08:53:52

這是否意味着Path是一個訪問存儲庫的域實體？ – 2013-03-14 09:10:51

可能是因爲您決定遵循DDD路線。儘管如此，我無法分辨在這種情況下DDD是否合理。但是，如果它是一個聚合根，它將只有一個回購，並且正如我在答案中所寫的那樣，我不太瞭解有關決定 – 2013-03-14 09:20:16

的要求。實際上，域實體應該最好無法訪問存儲庫。這就是爲什麼我提出了一個域服務來協調行爲。（http://stackoverflow.com/questions/5694241/ddd-the-rule-that-entities-cant-access-repositories- directirect） – 2013-03-14 09:24:12

一如往常 - 這取決於你如何使用它。

但是在探索頻道 - 汽車工廠有一個很好的「它是如何工作」的樣本。在槽式輸送機的行程中，汽車會接收越來越多的附加部件。每輛汽車都附有一種作業計劃 - 要完成任務的作業清單。當它通過生產線時，負責工作的人會對工作完成情況做出評判。所以當發現缺陷時 - 你肯定知道源。

因此，回到程序方法。首先，使用結構+過程方法而不是純粹的操作更自然。但是，當然，這取決於你。

第二 - 我建議將「產品」與「生產線日誌」對象分開，該對象與產品處於一對一關係，但在產品發佈後不一定需要。「生產線日誌」存儲與站點處理對象有關的事件。此外，您可以將其作爲一個時間表使用，即包括如何處理特定產品（如汽車包括或不包括調節器或霧燈等特定功能）。並且「計劃」的行動應該被工人標記爲「完成」。在現今的術語中，它也可以用'事件採購'術語來表示：在移動過程中，產品修改被寫入日誌;因此可以通過逐個重放修改事件來重新構建產品。

來源

2013-03-14 20:35:09 mikalai

何處放置處理兩個類之間關係的方法？

回答

相關問題