一部のオブジェクト指向言語 (Smalltalk など) では、現在のレシーバー オブジェクト以外のフィールドへのアクセスが許可されていません。例: this.good や this.like:=false などの式は有効ですが、x.like や this.like.good などの式は無効です。
私が理解していないのは、なぜですか??
そのような制限の論理的根拠は何ですか?
一部のオブジェクト指向言語 (Smalltalk など) では、現在のレシーバー オブジェクト以外のフィールドへのアクセスが許可されていません。例: this.good や this.like:=false などの式は有効ですが、x.like や this.like.good などの式は無効です。
私が理解していないのは、なぜですか??
そのような制限の論理的根拠は何ですか?
これは、カプセル化と呼ばれる OOP の中心的なアイデアの 1 つです。オブジェクト自体以外の誰も、その内部状態について知りません。
これにより、内部状態が時間の経過とともに変化する可能性があり、直接アクセスしている場合は、より優れた分離が提供されます。また、誰かがオブジェクトの状態を直接いじることができる場合、ランタイム中に予期しないときに何かが変更されるかどうかはわかりません。
一般に、アクセサを定義することは難しくありません。最終的にはx like
、x like: false
smalltalkx.like()
ではx.setLike(false)
、C ライクな言語では になります。Ruby と Scala では、スペースを使用してメソッドを定義し、括弧なしで呼び出すことができるため、フィールド アクセスのように見えます: x.like
, x.like = false
. アクセサーを書かなければならない場合は大きなオーバーヘッドはありませんが、プログラマーがオブジェクトの状態でやりたいことを何でもできるようにすると、コードに混乱が生じます。これは実際には大きな問題です。
使用しないと起こりうるすべての悪いことを理解するには、ある程度の時間が必要です。開発を始めると、フィールドを公開したままにしておくと何が起こるかわかりません。そのため、C++ は、初心者にとって直接フィールド アクセスを扱う方が簡単なため、始めるのに適していません。
また、フィールドに直接アクセスすることを考えると、OOP の概念全体が壊れます。手続き型言語のように、持っている任意のデータを使用できるため、クラスはデータ構造を定義する関数をグループ化する役割を果たします。
ウィキペディアでカプセル化の詳細を読むことができます。また、 What is Object Oriented Programming: A Critical Approachに関する非常に興味深い投稿もあります。
アデル・ゴールドバーグは、「尋ねる、触れないでください」という格言を使って、かなりグラフィカルに表現しました。