問題タブ [encapsulation]

既にご存知かもしれませんが、.NET Framework のprotected internalアクセス修飾子は奇妙な方法で動作します。クラスがprotected AND internalであることを意味するのではなく、クラスがprotected OR internalであることを意味します。つまり、変更されたクラスまたはメンバーは、同じアセンブリ内および同じ階層からアクセスできます。

それで、これを知ってください：いつそれを使いますか？例を挙げていただけますか？.NET Base Class Library 内に適切でわかりやすい使用例はありますか?

問題を解決したい人が、公式のインターフェースをスキップして、基礎となる実装の詳細に直接アクセスしたい場合、私は時々苦労します。

彼らは、そうすることで問題をより迅速に解決できると主張しています。そうすることで、アーキテクチャがより緊密に結合され、新しい要件が出現しても変更が困難になると私は主張します。

現在の設計に費やされたすべての作業、設計の哲学、および柔軟性の価値、壊れやすいコードを維持および変更しようとするコスト、カプセル化とデータの隠蔽、階層化されたアーキテクチャの価値、および堅牢であることを指摘します。仕様の小さな変更は、コードの小さな変更につながります。そして彼らは「しかし、これはもっと簡単だろう」と言います。

これらの人々をどのように扱いますか？

以前は、アプリケーション用のカスタム設定クラスがありました。私の次の趣味のプロジェクトでは、Preferences API に切り替えたいと考えていました。しかし、put 関数と get 関数にはデフォルト値が必要であり、ソース ファイル全体にデフォルト値を広げたくありません。私のプロジェクトは小さいですが、ソースコード全体でデフォルト値を変更することは想像できません. 皆さんはAPIをどのように使っていますか? 設定 API を別のクラスにラップすることを考えていますが、ファイルをディスクに保存する負担を取り除くだけなので、API を使用する意味は何ですか? 私は要点を逃していますか？

私はWebサービスの世界に手を出しており、数学演算を模倣した単純なWebサービスを作成しています。最初は単純で、2つの整数を渡してから、呼び出されたメソッドに応じて2項演算子がこれら（プラス、マイナスなど）に適用されます。

次に、物事をもう少し複雑にしてオブジェクトの受け渡しを開始することにしましたが、Webサービスはクラスのデータ側のみを公開し、機能側は公開しないことに気付きました。

これに対処する良い方法は、サービス側のクラスを部分クラス（クラスカプセル化フォームのこちら側）にし、クライアント側に別の部分クラス（クラスのこちら側が機能をカプセル化する）にすることだと言われました。 ）。これは物事を行うためのエレガントな方法のようです。

そこで、上記のように2つのクラスを設定しましたが、言われたとおりに機能していないようです。

私が試みていることは可能ですか？もしそうなら、私はどこが間違っているのですか？

特定の汎用トランザクションの永続化メカニズムを管理する境界クラスにイベント ハンドラーがあります。

SimpleTransaction および TransactionPErsistor オブジェクトをラップするために、ある種の TransactionManager を用意したほうがよいでしょうか?

さらにカプセル化する必要があるかどうかを理解するのに役立つ経験則はありますか?

現時点で私が従う経験則は、「メソッドが大きくなりすぎたら、それについて何かをする」です。境界イベント ハンドラーを扱う場合、手続き型とオブジェクト指向の間の適切なバランスを見つけるのが難しい場合があります。

何か意見はありますか？

乾杯

C# や VB.NET などの OOP 言語では、スーパー クラスでプロパティやメソッドを作成するprotectedと、フォームではアクセスできません。それらは、そのスーパー クラスを継承するクラスでのみアクセスできます。

これらのプロパティまたはメソッドにアクセスするにはpublic、カプセル化を無効にするか、継承を無効にするクラスに再書き込みする必要があります。

これを行う正しい方法は何ですか？

「クラスは、引数として受け取るクラスのコントラクト、または使用する内部コントラクトについてのみ知っておくべきである」という行に沿って何かを述べているオブジェクト指向エンジニアリングの原則があります。

C++ での反例は次のとおりです。

この原則に名前はありますか？また、上記の私の言い換えではなく、実際の原則が見られるとよいでしょう。

カプセル化の種類は何ですか？

これは基本的に、抽象化、ポリモーフィズム、継承などの中心的なオブジェクト指向の概念を指していると思いますか？

カプセル化についての私の理解は、それがデータ/機能を隠す方法であるということですが、ポリモーフィズムがオブジェクトの正確なタイプを隠すことができるので、ポリモーフィズムがカプセル化と見なされる方法を見ることができますが、私は実際にはポリモーフィズムまたは継承をカプセル化の形式とは見なしませんでしたと相互作用しています。

それで、それはそれについてだと思いますか、それとも私はいくつかのコアコンセプトを欠いていますか？

編集誰かがプライベート/パブリックメソッドを参照している可能性があるとコメントで気づいたのですが、おそらく私は質問を考えすぎて、実際よりも複雑な答えを期待していますか？

@interfaceで定義せずに、クラスの@implementationでメソッドを作成するにはどうすればよいですか？

たとえば、初期化を行ってからファイルからデータを読み取るコンストラクターがあります。ファイル読み取りコードを別のメソッドに分解して、コンストラクター内から呼び出したいと思います。このメソッドはこの@implementationコンテキストに対してのみプライベートであるため、ヘッダーでこのメソッドを定義したくありません。

これは可能ですか？

これが私の例です。ファイルからTodoタスクリストを読み取る小さなプログラムがあります。

@interfaceは次のとおりです。

そしてここに@implementationの一部があります：

私がやりたいのは、インターフェースで以下を定義する必要がないことです。

免責事項

はい、私が尋ねていることは完全に愚かであり、製品コードでそのようなことを試みたい人は誰でも解雇および/または撃たれるべきであることを十分に認識しています. 私は主に、できるかどうかを見ています。

クラス外から C++ のプライベート クラス メンバーにアクセスする方法はありますか? たとえば、ポインタのオフセットでこれを行う方法はありますか?

(ナイーブで本番環境に対応していないテクニックを歓迎します)

アップデート

コメントに記載されているように、この質問をしたのは、過剰カプセル化 (およびそれが TDD に与える影響) に関するブログ投稿を書きたかったからです。「プライベート変数の使用は、C++ であっても、カプセル化を強制する 100% 信頼できる方法ではない」と言う方法があるかどうかを確認したかったのです。最後に、問題がなぜ問題なのかよりも、問題を解決する方法にもっと焦点を当てることにしたので、ここで取り上げたもののいくつかは、計画していたほど目立つようには取り上げませんでしたが、それでもリンクを残しました.

いずれにせよ、それがどのように生まれたかに興味がある人は、次 のとおりです。