問題タブ [encapsulation]

以下は、説明のための非常に単純化された例です。

カウンターにアトムを使用するなど、実装の詳細をカプセル化できます。

しかし、それは機能を追加するためにすべてを再定義する必要があることを意味します (継承なし):

一方、1 つの関数だけを拡張することが可能であれば、次のようになります。

または、アトムを公開して、独立した機能を持たせることもできました。

「継承」(または、より正確には拡張) が必要な場合は、カプセル化を放棄することが最善の選択肢のようです。

カプセル化と抽象化の両方が情報の隠蔽に関連しているので、カプセル化を抽象化のサブセットとして理解できますか？

次のスクリプトを参照してください。

x（123）.y（）を呼び出すと、メッセージに123が表示されます。x（）内で宣言された関数y（ ）

ここで、 x（）の外部にあるが、 y（）と同じように動作する別の関数z（）を宣言したいと思います[ x（）に関連付けます]

出来ますか？可能であればどのように？

私がC＃クラスを持っているとしましょう：

クライアントはそれを呼び出すことができます：

Addの読み取り専用バージョンのみ_barListが返されるため、メソッドを失敗させる方法はありますか？

テスト駆動開発の関係者から、暗黙のうちに大量の情報を取得する関数を持つことは悪いことだとよく耳にします。テストの観点からこれが悪いことはわかりますが、カプセル化の観点からは必要な場合があるのではないでしょうか? 次の質問が頭に浮かびます。

Random と OrderBy を使用するのは良いシャッフル アルゴリズムですか?

基本的に、誰かが C# で配列をランダムにシャッフルする関数を作成したいと考えていました。何人かの人々は、乱数ジェネレーターをパラメーターとして渡す必要があると彼に言いました。これは、テストが容易になるとしても、カプセル化のひどい違反のように思えます。配列シャッフル アルゴリズムがシャッフルしている配列以外の状態を必要とするという事実は、呼び出し元が気にする必要のない実装の詳細ではないでしょうか? この情報を取得する正しい場所は、暗黙のうちに、おそらくスレッドローカル シングルトンからではないでしょうか?

以下を定義し、要素で埋めました。

しかし、特定のキーを持つ要素を削除したい...

しかし、それは私を許可しません。そのキーに割り当てられた要素を適切に破棄するにはどうすればよいですか?

私のソフトウェア開発プログラミングのクラスでは、RSS フィード用の「フィード マネージャー」タイプのプログラムを作成することになっていました。FeedItems の実装をどのように処理したかを次に示します。

素晴らしくシンプル：

そのためにマークダウンしました。「正しい」回答例は次のとおりです。

私には、これはばかげているように思えます。正直なところ、これが私のものとまったく同じことをより多くのオーバーヘッドで行うとき、私がマークダウンしたとは信じられません。

C# で人々が常にこれを行う方法を思い出します。

私は彼らがそれを行う理由を取得することを意味します。おそらく、後でセッターでデータを検証するか、ゲッターでデータをインクリメントしたいと考えています。しかし、その状況が発生するまで、なぜあなたはこれをやらないのですか?

申し訳ありませんが、これは一種の暴言であり、実際には質問ではありませんが、冗長性は私にとって腹立たしいです. ゲッターとセッターが必要ないのに、なぜそれほど愛されているのでしょうか?

いくつかの動作コードを抽象化する必要があり、これらの動作を呼び出しているクラス内のオブジェクトを参照しようとすると問題が発生します。説明してみましょう。

私の「親」クラスには、 CurrentPageというプロパティがあります。また、 CurrentPageプロパティを変更する動作ロジックもいくつかあります。現在、これは同じクラスで記述されています。私は今、多くの場所でその動作を再利用する必要があるので、それをカプセル化/抽象化して別の...ええと...クラスにしますか??

自分のニーズに合ったデザイン パターンがおそらくあると感じていますが、どれを使用すればよいかわかりません。

誰か助けてくれませんか??

ありがとう、マーク

(私は C#、Silverlight、および MVVM を使用しています。CurrentPageはフィールドではなく通知プロパティであるため、 Ref型として Behavior サブクラスに渡すことはできません)

更新: 要求に応じて追加された例:

DoWork() を別のクラスに抽出しようとしています。

データ、ビジネス、UIプロジェクトに配置されたWebアプリケーションがあります。システムが進化するにつれて、3つのプロジェクトすべてを構築し、それらを1つのパッケージに展開することで、変更が展開されます。これはうまく機能し、通信に取り組むことなく「3層」の錯覚を可能にし、真に別個のシステムの問題をバージョン管理しました。

そこで、いくつかのデータのXML要約の要求があり、私の考えは、いつの日か私の「Web API」になる可能性のある豪華なWCFサービスに変わります（ああ…心..それはなんて邪悪な小猿なのか）。それで、これが生き残ると仮定すると、「それは本当に最高のアイデアですか？」ここでのテストは私の質問です：

1つの進化する「モデル」からコンテンツを提供する2つの進化する「クライアント」でポーズをとったときに、どのような構造で最も成功しましたか？