クラスは、インターフェイスを実装したり、抽象クラスを拡張したりせずに抽象化を実現できますか？
私は多くの抽象化の定義と、Javaおよびインターフェース（Javaのみ）と抽象クラスを使用したC++）のようなプログラミング言語でそれを実現する方法を読みました。
複数のクラスが抽象メソッドの独自の実装を提供して抽象化を実現するには、抽象クラスとインターフェイスが必要であることを理解しています。
プライベートメソッドですべての実装の詳細を隠し、（内部でプライベートメソッドを呼び出す）パブリックメソッドのセットを提供するクラスを、オブジェクト指向の設計に従って抽象化を達成したと見なすこともできますか？
この質問は、抽象化を実現するためにプログラミング言語で利用できるメカニズムに特に関連しています-パブリックメソッドではなくインターフェイスと抽象クラスが一般的に言及されているのがわかります。
抽象化、つまり「抽象化」は、単純な定数から一連のインターフェースまで、たとえばAPI全体。
この範囲には、単一の関数と、メソッドのグループ（つまり、クラスまたはインターフェース）も含まれます。
抽象化の品質は、その使いやすさと完全性に依存します。不完全な抽象化では、クライアントが実装の詳細について知っている必要がある以上の知識が必要になることがよくあります。
したがって、たとえば、単一の定数は抽象化の形式ではありますが、他の定数やメソッドなしではおそらくそれだけでは完全には完成しません。
レイヤリングは、抽象化を提供することの代替であり、その実装は他の抽象化の観点から行われます。理想的には、特定のレイヤー（たとえば、上のレイヤー）のコンシューマーはそのレイヤーとのみ対話し、下位のレイヤーに移動する必要はありません。
もちろん、抽象化はさまざまな方法でパッケージ化することもできます。もちろん、非公式にドキュメント（たとえば、いくつかのメソッドが一緒に機能するドキュメント）を使用する方法と、プログラミング言語に応じて、言語構造をより正式に使用する方法があります。
クラスとインターフェースは、メソッドを抽象化にグループ化する正式なメカニズムです。
名前空間は、クラスとインターフェース（およびその他の名前空間）をより大きなAPIの抽象化にグループ化する正式なメカニズムです。