抽象是一種以簡化的形式來看待復雜操作的能力，類的接口為隱藏在其后的具體實現提供了一種抽象，類的接口應能提供一組明顯相關的子程序。
    如果類的接口不能展現出一直的抽象，那么它的內聚性就很弱，應該考慮把一些子程序重新組織到只能更專一的類里去，在這些類的接口中提供更好的抽象。
    對創建類的抽象接口的指導建議：
   （1）類的接口應該展現一致的抽象層次：在考慮類的時候有一種很好的方法，就是把類安坐一種用來實現ADT的機制。每個類應該實現一個ADT，并且僅實現這個ADT，如果你發現某個類實現了不止一個ADT，或者你不能確定究竟它實現了何種ADT，就應該把這個類重新組織為了一個或多個更加明確的ADT。
   （2）一定要理解類所實現的抽象是什么。
   （3）提供成對的服務：大多數操作都有和其對應的、相等的以及相反的操作，如果有一個操作用來把燈打開，那么很可能也需要另一個操作來把燈關閉。在設計一個類的時候，要檢查每一個公用子程序，決定是否需要另一個與其互補的操作。不要盲目的創建相反操作，一定要考慮，看看是否需要它。
   （4）盡可能讓接口可編程，而不是表達語義：每個接口都有一個可編程的部分和一個語義部分組成，可編程的部分由接口中的數據類型和其他屬性構成，編譯器能強制性的在編譯時檢查錯誤，而語義部分則是由“本接口將會被怎樣使用”的假定組成，而這些是如法通過編譯器來強制實施的。
   （5）謹防在修改時破壞接口的抽象性。
   （6）不要添加與接口抽象不一致的公用成員：每次向類添加子程序時，問問“這個子程序與現有接口所提供的抽象一直嗎？”如果發現不一致，就要換另一種方法來進行修改，以便能夠保持抽象的完整性。
   （7）同時考慮抽象性和內聚性：一個呈現出很好的抽象的類接口通常也有很高的內聚性【如果一個類表現出很好的抽象性，那么接口一定是朝著一致的方向努力的，從而會具有很好的內聚性】。而具有很強的內聚性的類往往也會呈現為很好的抽象，但是關系不如前者強烈。一般關注類的抽象性比關注類的內聚性更有助于理解類的設計。 
   封裝是一個比抽象更強的概念，抽象通過提供可以讓你忽略實現細節的模型來管理復雜度，而封裝則強制阻止你看到細節。抽象和封裝是緊密相關的，沒有封裝，則抽象就容易被打破。一般而言，要么封裝與抽象兩者皆有，要么就是兩者皆失。
   （1）盡可能的限制類和成員的可訪問性：讓可訪問性盡可能低是促成封裝的原則之一。
   （2）不要公開暴露成員數據：暴露成員數據會破壞封裝性，從而限制你對這個抽象的控制能力?！救绻┞读顺蓡T數據，就不知道何時數據被修改了】
   （3）避免把私用的實現細節放入類的接口中。
   （4）不要對類的使用者做出任何假設：類的設計和實現應該符合在類的接口中所隱含的契約。不應該對接口會被如果使用或不會被如何使用做出任何假設。
   （5）避免使用友元類：一般情況下，友元類會破壞封裝，因為它讓你在同一時刻需要考慮更多的代碼量，從而增加復雜度。
   （6）不要因為一個子程序里僅使用了公用子程序，就把它歸入公開接口：一個子程序僅僅使用公用的子程序這一事實并不是十分重要的考慮因素。相反，應該問的問題是，把這個子程序暴露給外界后，接口所展示的抽象是否還是一致的。
   （7）讓閱讀代碼比編寫代碼更方便：閱讀代碼的次數要比編寫代碼的次數多的多，即使在開發的初期。
   （8）要警惕從語義上破壞封裝性：每當你發現自己是通過查看那類的內部實現來得知如何使用這個類的時候，你就不是在針對接口編程了，而是在透過接口針對內部實現編程了，如果你透過接口來編程的話，封裝性就被破壞了，而一旦封裝性開始遭到破壞，抽象能力就快遭殃了。
   （9）留意過于緊密的耦合關系。
   耦合性與抽象和封裝性有著非常緊密的聯系，緊密的額耦合性是發生在抽象不嚴禁或者封裝性遭到破壞的時候，如一個類提供了一套不完整的服務，其他的子程序就可能要去直接讀寫該類的內部數據，這樣一來，就把類給拆開了，把他從一個黑合盒子變成了一個玻璃合資，從而事實上消除了類的封裝性。