在API中暴露多少低級別內容？

在設計通用庫的公共API時，應該暴露多少內部使用的低級內容？一方面，用戶不應過分依賴實現細節，太多低級函數/類可能會混淆API。因此，下跪反應可能是「無」。另一方面，一些低層次的功能可能對人們有用，而更多的低層功能可能會阻止抽象倒置（在高層次結構之上重新實現底層結構）。在API中暴露多少低級別內容？

此外，公開更多低級別細節可以提供性能快捷方式。例如，假設您有一個函數來查找數組的中位數。令人驚訝的原則是你應該複製數組，以便API的用戶不必關心它的實現涉及重新排序元素的副作用。在這種情況下，你是否應該注意到，median（）會花費內存分配，並提供繞過分配的另一個函數，但會隨意對用戶的輸入進行重新排序？

什麼是這種類型的細節暴露多少的一般準則？

來源

2009-01-10 dsimcha

關於你的中位數（）的例子，解決方案是文件。首先提供最不令人意外的方法，那麼，如果出現性能需求，則提供第二種方法，不要分配和記錄其行爲 – 2009-01-10 14:53:00

儘可能少。

您揭露的細節越多，更改可能會破壞消費者。

來源

2009-01-10 14:44:59

你的API不應允許調用者通過破壞內部狀態（例如重新排序集合等）來「破壞」任何東西。爲了解決這個問題，只有在必要時才能讀取暴露的接口。

關於複雜性，我傾向於簡單的基本方法。我非常努力地不要過度設計任何我認爲需要的東西。

寫今天的要求（也許明天的），但不能超越。您可以隨時擴展。拋棄你無法再維護的東西更難。

來源

2009-01-10 14:47:19

這樣做的unix方式是提供機制，而不是政策。只要提供正確的工具來做事情（比如說一把刀），但儘量不要預測它們將如何使用（剝蘋果或磨鉛筆）。

來源

2009-01-10 15:00:18 PolyThinker

您可以詳細說明這一點嗎？我真的不明白你在說什麼。 – dsimcha 2009-01-10 16:53:15

我聽過一種表達方式：公開什麼，但不是如何。

我們的目標是爲客戶提供一個有用且豐富的庫，使它們不依賴於庫的內部。你希望能夠改變內部結構，而不會打斷調用者（就像其他人已經注意到的那樣）。

寫一個好的API涉及到一定數量的巧妙邊緣。

來源

2009-01-10 20:24:18

在API中暴露多少低級別內容？

回答

相關問題