カプセル化がOOPの主要な原則と見なされるのはなぜですか？
私は現在、OOPの4つの原則である抽象化、カプセル化、継承、およびポリモーフィズムをより深く理解しようとしています。
4つの原則を調べた後、なぜカプセル化がOOPの4つの主要な原則の1つであると考えられているのか完全には理解できません。
カプセル化は非常に一般的であり、OOPで役立ちますが、抽象化の一部として使用するテクニックや戦略のように思えます。
抽象化の良い定義：
'抽象化は詳細からフォーカスを移動するの概念であり、物事の具体的な実装型（つまりクラス）、利用可能な操作（すなわち、メソッド）などであり、プログラミングをより簡単、より一般的、より抽象的にします。 '
一方、カプセル化は次のとおりです。
'クラスの内部実装の詳細を隠す外部のソフトウェアの世界から、そして他のソフトウェアエンティティがそのクラスと通信して操作するためのインターフェイスを提供します。`
もしそうなら、カプセル化はほとんどがソフトウェアシステムで物事をより抽象化する手法であるように思えます。したがって、それはそれ自体で主要な原則というよりも、抽象化の概念を実装する戦略のように機能します。これは「原則」と見なすことができ、テクニックだけでなく、より一般的な抽象化の原則の一部であり、それ自体は主要な原則ではありません。
誰か同意しますか？私が間違っている場合、その理由を説明してください。
私は同意します、それらの説明は本当に似ています。しかし、抽象化は、状態と機能を意味のあるバンドルに統合するという考えです。カプセル化はprotectingに関するバンドルであり、部外者が侵入したり、ルールを破ったり、状態を乱したりすることはありません。
- 抽象化には、状態に対する排他的なドメインがあり、カプセル化は、それを保証する方法です。
カプセル化のもう1つの側面は、実装が抽象化よりも複雑になる可能性があることです。だからあなたはメソッド（疑似コード）を持っているかもしれません：
リスト
<Thing>getRelatedThings（）
しかし内部的には、モノのリストはリストとしてまったく表されていません。多分それは複雑なデータ構造の混乱であり、そこからリストを抽象化します。
または多分それisモノのリストだけですが、後で気が変わった方がいいでしょう。抽象化は同じままですが、カプセル化によって実装が保護されます。
- したがって、別の違いは次のとおりです。抽象化は単純化に努めますが、カプセル化は複雑さを隠します。
編集：もう1つ...カプセル化はデカップリングの重要な側面です。それで、本当に似ている2つのクラスがあるとします。カプセル化しないと、これらの抽象化は重複し始め、時間の経過とともにますます絡み合う可能性があります。カプセル化では、いいえ、この抽象化はその抽象化とは異なります。
共通の抽象化がある場合は、それを分解して基本クラスを抽象化します。
（今は2つの問題があります;））（...申し訳ありませんが、これは「継承よりも構成を優先する」ジョークです。それが意味をなさない場合は、そこに到達します。）
- カプセル化により、抽象化の境界を明確に保つ
私は同意します、カプセル化は原則というよりメカニズムです。実装継承についても同じことが言えます。これは、サブタイプ化を実現するための（ 間違いなく危険 ）メカニズムであり、これが 1種類のポリモーフィズム です。正直なところ、継承はOOP=の基本原則とはまったく見なされません。オブジェクトはインターフェイスに関するものであり、継承ツリーに関するものではありません。
そのメモでは、「4つの原則」は、信頼できる情報源があるかのように言っています。あるとは思わない。 OOPは多くの人にとって多くのことを意味します。個人的に、私は [〜＃〜] solid [〜＃〜] の原則が役立つと思いますが、どちらを購読するかは、目的を達成するための手段にすぎません。正しさ、モジュール性、明快さの順で重要であると私は主張します。
OOPは一般的に、カプセル化、継承、および多型として定義されていました。 lotの周りでこの定義を見てきましたが、抽象化、カプセル化、継承、およびポリモーフィズムを何度か見ただけです。 Matt Weisfeldの「オブジェクト指向の思考プロセス」は、3つの部分の定義を認め、リストの最後に構成を追加します。
OOは については誰も同意しませんが） 定義 はたくさんあります。
カプセル化/継承/ポリモーフィズムは元々、OOが何であるかの定義として設定されたものであり、その後、人々は個々のポイントを原則として言及し、その後、人々は全体への言及をやめました。定義として、代わりにそれらを一連の原則と呼んだところ、人々は継承はポリモーフィズムの原則がOOPでどのように実装されたものであるかに気づきましたが、実装としてのカプセル化に対応する原則がリストされていなかったため、それを追加しました。次に、これらの原則のすべてが同じ抽象化レベルにあるわけではないことに気づきました。私はそれがこの順序で起こったという証拠はありませんが、開始と終了が何であったかはわかっています。
4つの「原則」を定義として採用し、カプセル化と継承を実装としてスローすると、抽象化+多態性がOOPの定義として取得されます。これは、オブジェクトをまったく持たない多くの言語に両方のオブジェクトがあるため、ばかげています。それらの。
オブジェクトをシステムの主要な単位と考えるためには、抽象化のレベルとカプセル化の原則の両方が必要です。
OO以前は、データを操作する関数が主要な単位でした。これは、それ自体がデータに作用する操作であるマシンコードの抽象化でした。 OOのコンテキストでの抽象化の原則は、基本的に、関数について考えるのをやめ、現実世界（オブジェクトにつながる）のように収集された動作の単位について考えることを始めることです。
カプセル化は、収集されたこれらの動作の単位は、それら自身の動作に対して単独で責任を負う必要があり、他の動作の単位がそれを妨害しないようにする必要があります（これもオブジェクトにつながります）。
そのため、オブジェクトは、自身の振る舞いに責任を持つ振る舞いの別個の単位であることを考えると、オブジェクトに到達するには、抽象化とカプセル化の両方が本当に必要です。
共通の動作の個別のユニットがあるシステムを想像することは可能ですが、これらのプロトオブジェクトは、他のプロトオブジェクトが動作に影響を及ぼしたり制限したりすることはありません。実際、これは最もひどく設計されたOOソフトウェアを記述しており、ゲッターとセッターと公開されたプライベートメソッドでいっぱいです。
カプセル化なしでは、ケイのような人々が想像したような「オブジェクト」がないので、行動の単位への抽象化は十分ではありません。