確定耦合的程度

Question

我有一個組件，其中API暴露了大約10個功能。我可以想到兩種方法來實現它：

1. 將所有這些功能作爲單獨的功能給出。

2. 僅公開一個以XML爲輸入的函數。根據指定的request_Type和通過XML傳遞的參數，我在內部調用其中一個相應的函數。

Q1。第二個設計會比第一個設計更鬆散嗎？

我總是閱讀我應該如何嘗試我的組件鬆散耦合，我應該真的去這個程度來實現失去耦合？ Q2302。哪一個在OOP方面會更好？爲什麼？

---

編輯：

如果我公開此API在d-總線供他人使用，將類型檢查仍是一個考慮到這兩種方法比較？根據我的理解，類型檢查是在編譯時完成的，但是當這個函數暴露在某個IPC上時，類型檢查問題就出現了。

Answer 1

您提出的兩種選擇方案在您希望通過API提供的「功能」數量（顯然非常大）方面沒有差異。然而，第二個似乎有許多缺點，因爲你失去了任何強類型檢查，文檔化功能將變得更加困難等。（我看到的唯一優點是，如果添加功能，則不需要更改API但在不利的用戶將無法找出像刪除功能的API修改，直到運行時。）

更重要的是與此相關的問題是單責任管理原則（http://en.wikipedia.org/wiki/Single_responsibility_principle）。正如你在談論面向對象的時候，你不應該在一個類中暴露你的數十個函數，而是將它們分成不同的類，每個類都有一個責任。確定良好的「責任」和角色需要一些練習，但遵循一些基本指導方針將有助於您快速入門。請參閱Are there any rules for OOP?以獲取良好的起點。

---

回覆的問題編輯

我沒有用d總線，所以這可能是完全錯誤的。但從快速瀏覽tutorial我看了

每個對象都支持一個或多個接口。將接口想象成 一組已命名的方法和信號，就像它在GLib或Qt或Java中一樣。接口定義了一個對象實例的類型。

DBus用簡單的命名空間字符串標識接口， 類似org.freedesktop.Introspectable。大多數綁定將這些接口名稱直接映射到適當的編程語言 構造，例如到Java接口或C++純虛擬類。

據我所知，D-Bus具有不同對象的概念，它提供由多種方法組成的接口。這意味着（對我來說）我上面的答案仍然適用。指定你的API的「D-Bus native」方式意味着展示接口，而我看不出有什麼理由說明爲什麼好的OOP設計指南不應該有效。由於D-Bus似乎甚至將這些映射到本地語言構造，所以這更可能。

當然，沒有人會讓你僅僅用XML構建自己的API描述語言。但是，像是某種基礎技術的濫用。你應該有充分的理由去做這些事情。