問題タブ [information-hiding]

抽象化とは、「実装の詳細」を非表示にすることを意味します。.....したがって、抽象化の目標は、情報の非表示を実現することです。そして、実装の詳細でない場合、情報隠蔽に何が隠されていますか？そして、情報隠蔽の手法はどのように抽象化されているのでしょうか。

インターフェイスは情報を隠すためにも使用され、ユーザーが使用できるメソッドのサブセットのみをユーザーに提供します。たとえば、PersonクラスとインターフェイスがありますIPerson。

今メインで、私はすることが許可されています

また

だから本当に私はまだPersonを使うことに制限されていません。では、インターフェースはどのようにして本当にデータを隠すのでしょうか？

jarファイルで一部のクラスを非表示にすることは本当に不可能ですか?

クラスをより柔軟に保つために、クラスの直接インスタンス化を許可したくありませんでした。この jar のファクトリ (またはファサード) のみが表示されます。

2 つのプロジェクトを作成する以外に、この問題を解決する方法はありますか? (2 つのプロジェクト: 最初のプロジェクトにはクラス (実装) が含まれ、もう 1 つのプロジェクトには最初のプロジェクトへの参照とファクトリが含まれます。後で 2 番目のプロジェクトのみが参照されます)

私は何度もAPIの設計/実装に携わっており、このジレンマに直面しています。

私は情報隠蔽を非常に強力に支持しており、内部クラス、プライベートメソッド、パッケージプライベート修飾子などを含むがこれらに限定されないさまざまな手法を使用しようとしています。

これらの手法の問題は、優れたテスト容易性を妨げる傾向があることです。そして、これらのテクニックのいくつかは解決できますが（たとえば、クラスを同じパッケージに入れることによるパッケージのプライベート性）、他のテクニックはそれほど簡単に取り組むことができず、反射魔法または他のトリックが必要です。

具体的な例を見てみましょう。

公開しないことには大きな理由がありますInnerFoo。他のクラスはありません。ライブラリは公開契約を定義しておらず、作成者が意図的にアクセスできるようにしたくないため、ライブラリにアクセスする必要があります。ただし、100％TDDコーシャであり、リフレクショントリックなしでアクセスできるようにするには、InnerFoo次のようにリファクタリングする必要があります。

この例には3つの属性しか含まれていませんが、5〜6を使用するのはかなり合理的であり、OuterFooコンストラクターは8〜10のパラメーターを受け入れる必要があります。ゲッターを上に追加すると、すでに100行の完全に役に立たないコードがあります（テスト用にこれらの属性を取得するには、ゲッターも必要になります）。はい、ビルダーパターンを提供することで状況を少し改善することができますが、これは過剰なエンジニアリングであるだけでなく、TDD自体の目的を損なうものだと思います。

この問題の別の解決策は、クラスの保護されたメソッドを公開し、Fooそれを拡張してFooTest、必要なデータを取得することです。protected繰り返しになりますが、メソッドはコントラクトを定義し、それを公開することで暗黙的に署名したため、これも悪いアプローチだと思います。

誤解しないでください。テスト可能なコードを書くのが好きです。簡潔でクリーンなAPI、短いコードブロック、読みやすさなどが好きです。しかし、単体テストが簡単であるという理由だけで情報隠蔽に関して犠牲を払うのは好きではありません。

誰かがこれについて（一般的に、そして特に）何か考えを提供できますか？与えられた例のための他のより良い解決策はありますか？

これはばかげているように聞こえるかもしれませんが、本当に知りたいです:)現在c＃を学んでいます。

ご存知のように、「オブジェクト」（ボタン、ラベル、テキスト、変数など）をパブリックまたは好きなものに設定する必要があります。

ただし、次のようなコードを記述する必要があります。

では、他の形式で到達できないようにするポイントは何ですか? なぜすべてが公開されていないか、デフォルトで公開されていないのですか?

ありがとう。

...逆アセンブリを参照してもパスワードがすぐに公開されないようにします（静的変数として宣言されています）。例として、zip ファイルが添付されているプログラムを想像してみてください。このファイルは、アセットのために開く必要がありますが、詮索好きな人には簡単にアクセスできません。

そのジッパーを完全に隠したり保護したりすることは不可能であることはわかっていますが、少なくともカジュアルなスヌーパーを阻止するためにどのような手段が利用できるのか興味があります.

ありがとう！

最近、Android アプリケーションにカスタムVideoViewを作成する必要がある状況に遭遇しました。MediaPlayer オブジェクトにアクセスし、いくつかのリスナーを追加する必要がありました。

残念ながら (私にとって)、VideoView クラスのすべてのメンバーはプライベートであるため、クラスを拡張しても MediaPlayer オブジェクト (またはその他のもの) にアクセスするのに役立ちません。変更。

まあ、「大変な作業」に文句を言っているように聞こえますが、この場合、クラスを拡張するよりも簡単です (すべてのソースが利用可能であるため...)。隠蔽。これは、主要なコンポーネントを変更/アクセスできるようにしておくよりも良い方法ですか (保護されていますが、公開されていません)? つまり、VideoViewクラスを拡張すると、いつかVideoViewクラスで何かが変更されて問題が発生する可能性があることは理解していますが、クラスが変更される場合、自分の（複製した）バージョンの方が大きな違いがあります私の目標は、独自のビデオ ビューを作成することではなく、利用可能な VideoView を拡張することです。

このデザインを選ばない理由:

これの代わりに：

ソース ファイルで定義された変数と静的関数を使用して、実装の詳細を非表示にしてコンパイルを高速化できますか? そうでない場合、この設計 (継承以外) の何が問題になっていますか?

Command Pattern を読みましたが、何かが足りないと思います。Command オブジェクトは、Receiver オブジェクトの詳細を抽象化するために存在します。ここでやめて、Command オブジェクトへの参照を保持し、適切なメソッドを適切なタイミングで実行できるように思えます。

では、なぜ Invoker が必要なのでしょうか? この追加の間接化にはどのような利点がありますか? レシーバーの詳細はコマンドの背後にすでに隠していますが、コマンドをクライアントからも隠す理由は何ですか?

jboss サーバーの情報をユーザーから隠したい。(サーブレット 2.5; JBoss-5.0/JBossWeb-2.1、JSF/1.2)

これを行う方法 ？