F＃ - 純功能設計，而不是oop設計

Question

我想創建一個由三個代理組成的簡單“多代理”系統。 對於每個代理程序，都會創建一個封裝郵箱處理器的類型。 所有代理（位置，id等）和函數（sendMessage，move）都有共同的屬性，代理與郵箱處理器的實現（消息的處理方式）不同。 此外，它們可能因特定代理商特有的其他功能而不同。 每個代理還應該包含（作為其屬性之一）其他代理的列表，它將向其發送消息。 這是一個非常簡單的模型，我計划在F＃中使用郵箱處理器。

在OOP中，這意味着創建代理接口（或抽象類），並且所有特定代理都將使用自己的實現從此接口繼承。

我知道OOP在F＃中是可行的，但我寧願堅持純粹的功能設計。 但是，在我看來，OOP是這種情況下最合適的方法。 如果您能就功能（F＃）設計給我任何想法，我會很高興嗎？ 謝謝。

Answer 1

首先，F＃中的功能風格和面向對象風格並沒有真正發生沖突。

• 功能樣式包括使用不可變類型，沒有副作用的純函數和F＃數據類型，如區分聯合，函數等。

• 面向對象的風格更側重於如何組織代碼（使用類和接口），但代碼仍然可以純粹功能而不使用任何可變狀態。

在基於代理的系統中，在代理的實現中使用功能樣式是有意義的，但是使用類來組織代理。 我認為這可能是F＃中的最佳實踐（另請參閱有關在MSDN上封裝F＃代理的文章 ）。

在您的示例中，您說代理會保留其發送消息的其他代理的列表。 有一些值得考慮的選擇（如果你想避免接口）：

• 公開F＃事件（ Event<'T> ）。 這樣，代理只是公開通知，而不必顯式管理其他代理的列表（此設計也允許其他類型的訂戶）。

• 保留一系列功能。 如果您只需要向其他代理發送消息，那么您基本上只需要一個具有單個方法的接口。 在這種情況下，您可以保留一系列功能，例如
  Message -> unit 。

我通常更喜歡暴露事件 - 這樣，系統耦合不那么緊密，您可以更輕松地以各種方式組合代理（它們不必實現特定的接口組合）。 本文從更高層次的角度討論基於代理的體系結構 ，也可能有用。

Answer 2

你為什么要堅持純粹的功能設計？ F＃允許功能和 OOP原則的清晰組合，我會利用這兩種機制並利用語言的強大功能。

如果你想結合功能和OOP方面，我首先要使你的對象不可變 。 因此，您在使用對象，但在功能范例中。

Answer 3

你已經想出了一個OOD，OOP解決方案看起來最自然是令人驚訝的嗎？

如果你用流程重寫了設計描述，並且記住了數據轉換，它自然會作為FP設計而失敗，並且在OO中聽起來很笨拙，有很多類。 因為它幾乎沒有描述數據類型或需要進行哪些轉換。 乍一看，我會說代理是三個參數的函數：郵箱，消息處理程序（或消息處理程序列表），以及要聯系的其他代理郵箱的列表。 如果將來的調度基於消息，則消息處理程序是兩個args的函數。 郵件和郵箱列表。