問題タブ [encapsulation]

プロジェクトの規模が大きくなるにつれて、C コードをモジュール化するために知っている方法、慣例、規則は何ですか?

これらのどれが最もクリーンまたは使用するのに最適であると考えられるのか、そしてその理由は何か疑問に思っています。

1つは乗客のリストを公開し、ユーザーが追加や削除などを行えるようにします。もう1つはリストを非表示にし、ユーザーが乗客を列挙して特別な方法で追加することのみを許可します。

例1

例2

私が言う最初のクラスはよりよくカプセル化されています。そして、この正確なケースでは、それがより良いアプローチかもしれません（おそらくバスに残っているスペースがあることを確認する必要があるためなど）。しかし、2番目のクラスも役立つ場合があると思いますか？クラスがリストを持っている限り、そのリストがどうなるかをクラスが本当に気にしない場合のように。どう思いますか？

ここのプロジェクトでRunCodeAnalysisを実行しようとしましたが、次のような警告がいくつか表示されました。

CA1002：Microsoft.Design： ' SomeClass.SomeProtectedOrPublicProperty 'の'List < SomeType >'を、Collection、ReadOnlyCollection、またはKeyedCollectionを使用するように変更します

なぜCollection<T>代わりに使用する必要がありList<T>ますか？msdnのドキュメントを見ると、ほぼ同じように見えます。警告のエラーヘルプを読んだ後、私はそれを見つけました

System.Collections.Generic.List（T）_は、継承ではなくパフォーマンスを目的として設計された汎用コレクションであるため、仮想メンバーは含まれていません。

しかし、これは本当にどういう意味ですか？そして、私は代わりに何をすべきですか？

List<T>内部で使用し続ける必要がありますが、プロパティでnew Collection<T>(someList)代わりにを返しますか？または、Collection<T>代わりに使用を開始する必要がありList<T>ますか？

そのため、アプリケーションが公開するこの公開 API を使用して、顧客がプラグインを作成できるようにしています。この例のために、次のような非常に単純なキーと値のペア システムであるとしましょう。

Keyここで、公開してはならないいくつかの属性 (データベース ID など) が内部的にあるとしましょう。私が現在行っていることは、次のようなものです。

これは理想的とは言えません。責任を再配置してキャストを回避し、内部/外部カプセル化を維持する方法はありますか?

現実の世界では、これよりもかなり複雑であることに注意してください。同等のKeyものにはかなりのメタデータが添付されており、誰かが単純な値を取得する以外にやりたいことがたくさんあるので、Map.Entry代わりに - のようなオブジェクトを公開するだけでは、必ずしも問題が解決するとは限りません。

私が思いついた唯一のことは、内部キーと外部キーを完全に分離し、Map<Key, InternalKey>. しかし、その場合、DRY に違反するメタデータをコピーするか、DRY に違反する への外部Key委任を行う必要がInternalKeyありMapます。

誰かもっと賢いものを考えられますか？

私たちのほとんどは、ある時点でこれに対処しなければならないと思うので、質問したいと思いました.

BLL に多くのコレクションがあり、同じ古いインライン (匿名) 述語を何度も書いていることがわかった場合、明らかにカプセル化のケースがありますが、それを達成するための最良の方法は何ですか?

私が現在取り組んでいるプロジェクトは、昔ながらの、すべてに答える、静的クラスのアプローチ (たとえば、User クラスと静的 UserPredicates クラス) を採用していますが、それはやや手間がかかり、少し面倒に思えます。

私は主に C# で作業しているので、そのコンテキストを維持することが最も役立ちますが、これは他の言語について聞くのに十分な一般的な質問だと思います。

また、LINQ と Lambda の出現により、これを実現する方法に違いがあると予想されるので、.Net2.0 と 3.0/3.5 の両方のスタイルでこれを行う方法を知りたいと思います。

前もって感謝します。

約20個のPOSTパラメータを処理する必要がありますが、どこで処理すればよいかわかりません。

それぞれをモデル上のメソッドの引数として定義し、メソッドが呼び出されたときにコントローラーからそれらを渡すことができます。これにより、かなりの作業が発生し、引数の数が原因で関数呼び出しが読みにくくなります。

または、モデルのメソッドを呼び出して、パラメーターに直接アクセスすることもできます。

パラメータを引数として渡すと、関数がアクセスするパラメータをより細かく制御でき、ドキュメントはよりわかりやすくなります。ただし、後で新しいパラメーターを追加した場合は、既存のすべての呼び出しを中断しないように、メソッド呼び出しの最後にパラメーターを追加する必要があります。引数を論理的にグループ化できないため、これが数回発生すると非常に混乱するだろうと思います。

モデル内のパラメーターにアクセスする場合、コントローラーからモデルにパラメーターを渡す必要がないため、メソッドはterserを呼び出します。ただし、アクセスされるパラメーターは簡単に制限なしで追加または削除できるため、私はパラメーターを制御できません。これには他の開発者からのより大きな規律が必要であり、遅かれ早かれ誰かが「これを本当に素早く（追加|変更|修正）する」ことに縛られているので、私はそれに依存するのは嫌です。

どちらに行けばいいのかわかりません。私はモデルですべてを行う傾向があります。これは、記述が速く、保守が容易であり（引数の混乱がない）、概念的にはモデルのビューによりよく適合するためです。一方、モデルの見方が正しいかどうかはわかりません。他の開発者に変更のたびに常にドキュメントを更新するように頼ると、モデルが混乱してしまうかどうかはわかりません。

だから、私は何をすべきですか？

クラスのメソッドをカプセル化して、それらを消費するクラス内に公開することは可能かどうか疑問に思っています。例（JFTR、このコードが間違っていることは知っています）

最終的には、単一の制御クラスのコンテキスト外で直接参照できないコンポーネントを作成できるようにしたいと考えています。

多くの人がこの記事を知っています：ゲッターとセッターの詳細。ゲッター/セッターの邪悪な側面を描写するという説得力のある仕事をしていると思います。また、既存のプロジェクト（未完成）をゲッター/セッターなしのコードに変換してテストしました。機能した。コードの可読性が大幅に向上し、コードが減り、最初は本当に必要だと思っていたゲッター/セッターを取り除くことができました。1か所を除いて。

モデルをビュー部分に配置することは、このアプローチがポイントを逃していると私が思うところです。この記事では、作成者はビルダーを使用してモデルをエクスポートします。問題は、ゲッターで得られるものと同じくらい多くの制御がビルダーに入れられることです。はい、モデルでの表現方法である実装を非表示にします。しかし、ゲッターは、そこに入れられたものとは非常に異なる何かをモデルから抜け出すことはありません。コンストラクターを介して「5」を渡すMoneyオブジェクトを作成する場合、money.getAmount（）は、これを他の通貨に変換したり、1つの要素「5」を含む配列として返したりしません。

あなたが設定したものが得られます。そして、ビューを介して値を設定し、最初に設定したものを保持することになっているオブジェクトから値を要求（取得）するときに期待する値を設定します。これらをエクスポートするビルダーは、同じことを期待しています。

これは質問には少し長いです。しかし、私は自分の見解に挑戦したいと思います。ゲッターとセッターは、モデルデータをビューレイヤーに転送するのに悪ですか？

ゲッター/セッターはまったく悪ではないと考える人はたくさんいます。私が言及した以外の場所では彼らは悪であると思うので、これも私が擁護したいと思っていることではありません。

カプセル化に関するウィキペディアの記事には、次のように記載されています。

「カプセル化は、ユーザーがコンポーネントの内部データを無効または一貫性のない状態に設定するのを防ぐことにより、コンポーネントの整合性も保護します」

私はフォーラムでカプセル化に関する議論を開始しました。その中で、上記のカプセル化のルールを維持するために、常にセッターやゲッター内でオブジェクトを複製する必要があるかどうかを尋ねました。メイン オブジェクト内のオブジェクトがメイン オブジェクトの外部で改ざんされていないことを確認したい場合は、常にそれを複製する必要があると考えました。

ある討論者は、この問題では集約と構成を区別する必要があると主張しました。基本的に彼が述べていると思うのはこれです：

• コンポジションの一部であるオブジェクト (たとえば、長方形のポイント) を返したい場合は、それを複製します。
• 集約の一部であるオブジェクト (たとえば、UserManager の一部としてのユーザー) を返したい場合は、参照を壊さずにそれを返します。

それは私にとっても理にかなっています。しかし今、私は少し混乱しています。そして、この件についてご意見をお聞かせいただきたいと思います。

厳密に言えば、カプセル化は常にクローン作成を義務付けますか?

PS .: 私は PHP でプログラムを作成しています。PHP はスクリプト言語であるため、リソース管理はもう少し関連性があるかもしれません。

Java クラスから別のオブジェクトの機能 (メソッド) を使用するための適切な OO 設計について議論していますが、両方のオブジェクトは可能な限り分離されたままです。

たとえば、クラスのある時点で、ロジックを実装するために、ヘルパー クラスなどの別のオブジェクトに属するメソッドを呼び出す必要があります。このヘルパー クラスは、元のクラスに関連している必要はまったくありません。クラスに表示され、クラスで使用できる特定のメソッドが含まれているだけです。

ロジックが実装された後は、ヘルパー メソッド (またはヘルパー オブジェクト) は必要ありません。

明らかに、メソッドを使用するには、このヘルパー オブジェクトへの参照が必要です。しかし、カプセル化を強制するには、元のクラスでインスタンス変数を宣言して、このヘルパー オブジェクトを参照するべきではありませんか? その理屈は正しいですか？また、ヘルパー クラスは、それを使用する可能性のあるクライアント クラスを認識しません。

この場合、ローカル変数の方が適切でしょうか? その機能を利用するメソッドでヘルパー オブジェクトを宣言してインスタンス化しますか? このようなヘルパー オブジェクトを宣言してインスタンス化するのに最適な場所は、元のクラスのどこですか?

高レベルの例があるかどうか、またはオブジェクト指向の記事でもう少し詳しく説明されているかどうか疑問に思っていました。上記のカプセル化に焦点を当てた入力またはヒントをいただければ幸いです。