「OOPは状態を隠す」とはどういう意味ですか？[閉まっている]

でcat-v.org上の多くの抗OOPの暴言の一つ、私は以下の通りであったそのうちの一つOOPモデルに対して複数の異議を上げるジョー・アームストロングの通路を見つけました：

異論4 –オブジェクトにはプライベート状態があります

国家はすべての悪の根源です。特に、副作用のある機能は避けてください。

プログラミング言語の状態は望ましくありませんが、現実の世界では状態が豊富です。私は銀行口座の状態に非常に興味があり、銀行に入金または引き出しを行うと、銀行口座の状態が正しく更新されることを期待しています。

状態が現実の世界に存在する場合、プログラミング言語は状態を処理するためにどの機能を提供する必要がありますか？

OOPLは「プログラマーから状態を隠す」と言います。状態は非表示であり、アクセス関数を介してのみ表示されます。従来のプログラミング言語（C、Pascal）は、状態変数の可視性は言語のスコープルールによって制御されると言います。純粋な宣言型言語は、状態がないと言います。システムのグローバルな状態はすべての機能に持ち込まれ、すべての機能から出てきます。モナド（FPL用）やDCG（ロジック言語）などのメカニズムは、プログラマーから状態を隠すために使用され、「状態は重要ではないかのように」プログラムできますが、必要に応じてシステムの状態に完全にアクセスできます。

OOPLによって選択された「プログラマーから状態を隠す」オプションは、最も悪い選択です。国家を明らかにし、国家の迷惑を最小限に抑える方法を見つけようとする代わりに、彼らはそれを隠します。

これはどういう意味ですか？私は、ほとんどの場合OOPの低レベルまたは手順の経験がほとんどないため、これがおそらく私がこれに慣れていないことを説明しています。そして、より現代的な観点から、オブジェクト指向のヒステリーのほとんどが渡されたので（少なくとも私が知る限り）、あなたはあなたはその通過がどれほど正確/関連していると思いますか？

ご協力いただきありがとうございます。

これはどういう意味ですか？

このコンテキストでは、OOPはプログラマーからプログラムを隠しますが、（漏れやすい）アクセサーメソッドを介して表示できるようにすることで、プログラムの状態を隠します。論拠は、状態を不明瞭にすることで、作業が難しくなり、拡張により多くのバグが発生することです。

パッセージはどの程度正確/関連性があると思いますか？

私はそれが関連していると思うが、誤った方向を向いている。クラスがその状態の概念を外部に漏らしている場合、絶対に問題があります。クラスが外部の世界によって操作されるべき状態を隠そうとする場合、絶対に問題があります。ただし、それはOOP全体の失敗ではなく、クラスの個々の設計によるものです。状態自体を隠すことが問題だとは言いません-モナドは関数型プログラミングでこれを常に行います。

最良の場合、OOPは関数型プログラミングと手続きの最適な組み合わせのように機能します。クラスの不変式を保護するために使用されるプライベートステートは隠されているが、自由があるため、人々は「ステートが重要ではないかのように」クラスを使用できますクラスの明確に定義されたパブリック状態を使用して、詳細を抽象化します。

OOPは、人々がこのベストオブケースを達成することを難しくしていますか？おそらく。「Javaスクール」とShape / Circle / RectangleまたはCar全体がWheelsを教えるOOのスクールは、おそらくアプローチ自体よりも多くの責任があります。現代のOOPは関数型プログラミングからかなりの部分を取り、不変のオブジェクトと純粋な関数を奨励し、継承を阻止して適切に機能するクラスの設計を容易にします。

単一の明確な「所有者」を持たない可変状態の断片がある場合、システムについての推論は困難になります。つまり、オブジェクトが変更可能な状態になることは決してありませんが、変更可能な状態を持つオブジェクトは、所有権が不明な場合には使用しないでください。逆に、所有権を追跡せずに自由に渡す必要があるオブジェクトは、不変であること。

実際には、効率的なプログラミングでは、一部のオブジェクトが可変状態であることが頻繁に必要になります。ただし、そのような状態は非共有ワーカーオブジェクトに限定する必要があります。.NET のIEnumerable/ IEnumeratorインターフェイスを考慮してください。コレクションが実装する場合IEnumerable、アイテムを1つずつ読み取ることができます。コレクションを読み取る実際のプロセスでは、多くの場合、どの項目が読み取られたかを追跡する必要があります（可変状態の一部）が、そのような状態はの実装に含まれていませんIEnumerable。代わりに、コレクションからアイテムを読み取ることができる十分な状態を実装して含むオブジェクトを返すIEnumerableというメソッドを提供します。オブジェクトにそのような状態が含まれているという事実は問題になりませんが、GetEnumeratorIEnumeratorオブジェクトの実装IEnumeratorが共有されていない場合。

ほとんどの場合の最良のパターンは、自由に共有されているが変更されない（少なくとも共有された後は）オブジェクトと、明確な所有者がいて、その所有者が自由に変更できるオブジェクトの混合物を使用することです、しかし誰とも共有されることはありません。

質問に答える以上の危険を冒すと、OOPのアイデアに欠陥が見られやすくなりますが、アイデアの力は悪用される能力に反映されると思います。

結局のところ、誰もが自分の好きな言語を持っているので、「非常に強力」という言葉で説明し、本当に好きだということです。しかし、計算の普遍性の不思議は、言語がどれほどすばらしいものであっても、それが本当に強力であれば、アセンブリ言語をシミュレートできることです。そして、できれば、誰かがそれを確認します。（アセンブリ言語に問題があるわけではありません。）

OOPの時流についての私の個人的な感覚は、それがソフトウェアエンジニアリング/コンピューターサイエンスにおける人々の教育の阻害を表しているということです。彼らは、それがすべてデータ構造に関するものだと考えるレベルで発育不良です。クラス、継承、コンテナ、イテレータ、ハッシュマップ、プロパティ、状態の非表示など-データ構造に関するすべて-より楽しい。

私は個人的に、人々が問題を言語的に見て解決することを学ぶ次のレベルを見たいと思っています。ドメイン固有言語の概念を理解する場合、それらを簡単に作成し、作成を問題解決の不可欠な部分にする方法。データ構造が言語であると言っても間違いではありません。人々は言語設計のスキルを持っている必要がありますので、彼らはそれをただぶらぶらしているだけではありません。

それから次のレベルとして、人工知能が再び活性化するのを見たいです。プログラマがバイトやスレッド、仮想関数テーブル、CUDAを超えて、マシンを推論、学習、作成する方法に移行することを望んでいます。私はこれがフィールドの小さなコーナーで非常に遠くまで進んだことを知っていますが、十分に近い場所ではありません。

アクセシビリティはOOPの機能ではなく、JavaやMicrosoft dotNETなどの実装に固有のものです。OOPを定義する主な機能は多態性です。

とにかく、オブジェクトの状態を隠すことで、意味のあるAPIを作成する方法はありません。プレゼンテーションは、実際のOOPの重要なコンポーネントです。同意しない人は、ソフトウェア業界に対して不合理な敵意を持っている可能性が高いため、私の意見からは自分の意見は無関係です。

あなたがリンクしたようなウェブサイトは、新技術に対する非常に厳格な考えと批判で有名です。一部の人々はそれを取得しません。