可能是我的表達不夠清楚，其實我想表達是，封裝的目的性。

以上圖來說明，其中，「Customized-Library」是針對「3th-Rabbitmq-Library」的封裝；這是否是您想表述的情境呢？

若是，我應該就沒有誤會。

為什麼我會說，這樣的封裝沒有問題呢？

因為「Customized-Library」很明顯是針對使用「RabbitMq」的「業務邏輯」來封裝，譬如說，「Email」和「Sms」使用的「Exchange」不同，甚至是「Virtual host」、「Broker」都不同；或是「Sms」所需使用的是臨時性的「MQ」；此時，我們將這個屬於「Email」和「Sms」的「邏輯」各自包裝，那麼，當有開發者要使用「Email」和「Sms」時，他就不再需要知道那些關於「RabbitMq」的事情，譬如，它應該連線到哪個「Exchange」。

不過這樣的缺點是什麼？

就是如您所說，這樣的「Customized-Library」再未來可能不敷需求，變得難用了；譬如，「Sms」的按照訊息的「重要性」分成兩個不同的「Queue」，但問題是，當出要連到哪個「Queue」已經寫死在「Customized-Library」中了，所以如果要改，就會變得很難改，不改，又不敷使用，或很難用。

但其實，這個問題不是「封裝」的問題，而是「封裝」的程式碼設計的不夠有彈性，不敷「Sms」的邏輯改變。

所以在我看來，您所說的情況應該是屬於「再包一層」的程式碼的設計不夠具有彈性，而導致這個原因不外乎就是不夠明確的「目的性」，簡單的說，就是不遵守單一職責，或許是缺職責，也可能是存在多個職責，才會導致程式碼在變動時需要考慮多個面向。

其實我並不認為你的顧慮是錯誤，事實上，在多數情況下，我很贊同你的方式，除非存在明確的 「Actor」，否則，我們真的不太需要再去的第三方庫「再包一層」；事實上，當專案不夠大的情況，更準確的說是 「Actor」不夠明確的情況，我們很容易陷入過度設計，或彈性不足的窘迫情況。

那我就解釋這邊喔，感謝您的回覆。