タグ付けされた質問 「object-oriented-design」

私は最後の数時間を費やして、staticクラスの使用について読み、それらを使用する必要があるかどうかを理解しようとしましたが、それでも何らかの結論には至っていません。議論はどちらにでも行くことができるようです。私のアプリケーションでは、「ヘルパークラス」と呼ばれるものを作成しました。これには、非常に一般的なタスクを実行し、アプリケーション全体（ASP.Net MVCWebアプリを使用C#）から呼び出されるメソッドが含まれています。簡単な質問は、それらが本当に静的かどうかです。 ？ これが私のヘルパーの例です。 public static class ActiveDirectoryHelper { public static PrincipalContext GetPrincipalContext(string ouName) { var fullOUName = string.Concat("OU=", ouName,",DC="); return new PrincipalContext(ContextType.Domain, "", fullOUName, ConfigurationManager.AppSettings["ServiceAccountUser"], ConfigurationManager.AppSettings["ServiceAccountPassword"]); } public static PrincipalSearcher GetAllUsersInOU(string ouName) { var principalContext = GetPrincipalContext(ouName); var userPrincipal = new UserPrincipal(principalContext); return new PrincipalSearcher(userPrincipal); } public static UserPrincipal …

8 c#  object-oriented-design  asp.net-mvc 

私はMVPについて、特にコントローラーの監督について読んでいます。ビューをモデルとどのようにやり取りするかは、頭を抱え込むのが難しい点の1つです。 プレゼンターがモデルを更新する必要があり、ビューがモデルから読み取ることは私の理解でした。プレゼンターは、インターフェイスを介してビューを更新することもできます。これに関するマーティンファウラーの記事は、まさにそれを示しているようです（http://martinfowler.com/eaaDev/SupervisingPresenter.html）。 ただし、他の記事/ブログは、モデルを直接更新するビューを示しています（https://blogs.msdn.microsoft.com/erwinvandervalk/2009/08/14/the-difference-between-model-view-viewmodel-and-other-分離表示パターン/）。 これらは単なるパターンであることを知っているので、さまざまな実装がありますが、モデルを更新するビューは、必要以上に多くのことを行っているようです。 たとえば、名前と電話番号を含む人物クラスがあったとします。ビューには、この名前と番号、および個人の名前と番号を変更するための送信ボタンを表示できます。送信ボタンをクリックすると、ビューではなくプレゼンターで更新が処理されると思います。ただし、私が参照した記事は、ビューがモデルを直接更新できることを提案しています。 それで、ビューはモデルを更新する必要がありますか？それとも、プレゼンターだけが処理する必要がありますか？ 編集： MSDN記事のコード： public class PersonalDataView : UserControl, IPersonalDataView { protected TextBox _firstNameTextBox; public void SetPersonalData(PersonalData data) { _firstNameTextBox.Value = data.FirstName; } public void UpdatePersonalData(PersonalData data) { data.FirstName = _firstNameTextBox.Value; } }

8 design  design-patterns  object-oriented-design  mvp 

たくさんのモジュールがあります。これらのモジュールを、完全で重複しないさまざまなカテゴリに分類できます。例えば、3つのように表すことができるIDを持つカテゴリ、Animal、Vegetable、およびMineral。さらに、これらのカテゴリをサブカテゴリに分類します。サブカテゴリも、明確で完全であり、重複しません。例えば、のように表すことができるIDS Mammal、Reptile、Legume、Root、Rock、Gem。最後に、これらのカテゴリの下に、モジュール自体が存在し、例えばCat、Dog、Iguana、Bean、Quartz、Emerald、など これが私の一般的な使用例です： すべてのモジュールでさまざまなメソッドを呼び出す必要があります。 すべてのモジュールのすべてのデータの現在の状態のフラットスナップショットを取得する必要があります。 特定のカテゴリ（サブカテゴリではない）のすべてのモジュールでさまざまなメソッドを呼び出す必要があります。 既知のIDに基づいて、特定のモジュールでさまざまなメソッドを呼び出す必要があります。 これは、「何かをする」または「自分についてのデータを教えて」のいずれかです。 特定のカテゴリ（サブカテゴリではない）のすべてのモジュールに関する集約データを保存する必要があります。 このデータをどのように保存すればよいですか？ 他のいくつかの関連する事実： カテゴリは実行時に確立されます そのため、最下位レベルのモジュールは共通のインターフェースを共有します。 いったん設定されると、それらはその特定の実行で変更されません-それらは設定ファイルのデータに基づいています。 これが私が現在していることです： を含むクラスがありますMap<Category, CategoryDataStructure>。このクラスは、要件＃2で使用するためのデータの個別のCollection<Module> ビューも保持します。 CategoryDataStructureを介して、メソッドコールをチェーンに送信するチェーンされた委譲メソッドがありますSubCategoryDataStructure。 CategoryDataStructure 要件＃5で使用される集計データも格納します。 それは機能しますが、正直なところかなり扱いにくいです。全体はステートフル/ミュータブルであり、変更が困難です。新しい動作を追加したい場合は、多くの場所に追加する必要があります。現在、データ構造自体にも多くのビジネスロジックがあります。委任方法。また、親データ構造は、特定のモジュールと必要に応じてその親データ構造、および必要に応じてその親のデータ構造を作成するために、多くのビジネスロジックを実行する必要があります。 どういうわけか、データ管理ロジックをデータ構造自体から切り離そうとしていますが、ネストが複雑なためです。ここに私が検討してきた他のいくつかのオプションがあります： シンプルなを作成し、Map<Category, Map<Subcategory, Module>>すべてのコードを配置して、その状態を別のクラスに保持します。これを行う際の私の懸念は要件＃1と＃2です。同じデータを表す2つの異なるデータ構造があるので、ビューの一貫性を保つのは困難です。 すべてをフラットなデータ構造で実行し、特定のカテゴリまたはサブカテゴリを探す場合は、構造全体をループします。

8 java  design  object-oriented-design  data-structures 

通常、Data Mapperは1つの特定のテーブルのデータをマップします。（理論的には、ストレージとドメインオブジェクトの間で通信する必要がありますが、私の場合は不可能なので、テーブルと直接通信しています。） Table1Mappper> Table1 ただし、そのテーブルで別のテーブルからデータを結合する必要がある場合は、1つのテーブルからのマッピングのみを想定していたデータマッパーのスコープを拡張します。 Table1Mapper> Table1：inner-join：Table2 Table2がTable2Mapperデータをマップする独自のマッパーを持っていれば、もっと良いのではないでしょうか？ 考えた場合Yes、Table1Mapperからレコードのリストを表示し、後でTable2Mapperを使用して、結合されるはずだったデータを取得したい場合は、ループでクエリを実行することになりますが、どちらも適切ではありません。 この方法について、どのような洞察がありますか？ 別の方法は、サブテーブルを処理するようにマッパーを変更することですか？ class Table1Mapper { public main_table = 'table1'; public sub_table1 = 'table2'; } これは問題ないと思いますが、マッパー全体のスコープがアプリケーション内の1つの特定のエンティティを処理するまでのみです。たとえばpostとpost_author。しかし、postおよびのようにスコープが異なる場合、gallery上記は理想的なデータマッパーを提供しません。これを説明するには class PostMapper { public table_name = 'tbl_post'; public gallery_table_name = 'tbl_gallery'; } 正しくありませんか？ただし、1つのクエリで1つの投稿のギャラリーを取得する必要があります。ループでクエリのオーバーヘッドを追加することは、優れたソリューションパフォーマンスではないためです。 このようなケースを処理するより良い方法がある場合、DataMapperパターンまたは他のパターンでこれを解決する正しい方法は何だと思いますか？

8 design-patterns  object-oriented-design 

C＃などのオブジェクト指向言語で静的クラスを使用しているプログラマーを目にするたびに、彼らが間違っていることに気づきました。主な問題は明らかにグローバルな状態であり、実行時に、またはテスト中にモック/スタブを使用して実装を交換することの難しさです。 好奇心から、十分にテストされたプロジェクトを選択するプロジェクトのいくつかを見て、実際にアーキテクチャとデザインについて考えようと努力しました。私が見つけた静的クラスの2つの使用法は次のとおりです。 ユーティリティクラス— このコードを今日作成している場合は避けたいものですが、 アプリケーションキャッシュ：そのための静的クラスの使用は明らかに間違っています。MemoryCacheまたはRedis に置き換えたい場合はどうなりますか？ .NET Frameworkを見ると、静的クラスの有効な使用例も見当たりません。例えば： File静的クラスを使用すると、代替クラスに切り替えるのが非常に困難になります。たとえば、分離ストレージに切り替えるか、ファイルをメモリに直接格納する必要がある場合、またはNTFSトランザクションをサポートできる、または少なくとも259文字を超えるパスを処理できるプロバイダーが必要な場合はどうでしょうか。持つ共通のインタフェースと複数の実装は、使用して同じように簡単現れるFileコードベース要件の変更のほとんどを書き換えることではないの恩恵で、直接。 Console静的クラスはテストを非常に複雑にします。ユニットテスト内で、メソッドが正しいデータをコンソールに出力することをどのように確認すべきですか？Stream実行時に注入される書き込み可能に出力を送信するようにメソッドを変更する必要がありますか？非静的コンソールクラスは、静的クラスと同じくらい単純で、静的クラスのすべての欠点がないように思われます。 Math静的クラスも適切な候補ではありません。任意精度の演算に切り替える必要がある場合はどうなりますか？それとも、より新しく、より高速な実装ですか？または、単体テスト中にMathクラスの特定のメソッドが実際にテスト中に呼び出されたことを通知するスタブに？ Programmer.SEで、私は読んだ： C＃で「静的」を使用しないでください。一部の回答は、静的クラスに完全に反しています。他の人は、「静的メソッドは使用しても問題がなく、プログラミングで正当な場所がある」と主張しますが、引数でそれを焼き付けないでください。 シングルトンを使用する場合と静的クラスを使用する場合。ユーティリティクラスには問題があると上記で述べたので、ユーティリティクラスについて説明します。 なぜ、いつクラスを「静的」にする必要がありますか？クラスの「静的」キーワードの目的は何ですか？言及されている唯一の有効な使用法は、拡張メソッドのコンテナです。すごい。 拡張メソッドとは別に、静的クラスの有効な用途は何ですか。つまり、依存性注入またはシングルトンが不可能であるか、設計の品質が低下し、拡張性と保守が難しくなる場合ですか。

8 c#  object-oriented  object-oriented-design 

次のインターフェースがあるとします public interface IUserRepository { User GetByID(int userID); } ユーザーが見つからない場合、このインターフェイスの実装者に例外をスローさせるにはどうすればよいですか？ コードだけで行うことは不可能だと思うので、意図した動作を実装するように実装者にどのように強制しますか？コード、ドキュメントなどを通じてですか？ この例では、具体的な実装により、 UserNotFoundException public class SomeClass { private readonly IUserRepository _userRepository; public SomeClass(IUserRepository userRepository) { _userRepository = userRepository; } public void DisplayUser() { try { var user = _userRepository.GetByID(5); MessageBox.Show("Hello " + user.Name); } catch (UserNotFoundException) { MessageBox.Show("User not found"); …

8 c#  .net  object-oriented-design  interfaces 

構文解析ツリー、抽象構文ツリー、および制御フローグラフがあり、それぞれが前のものから論理的に派生しているとします。原則として、解析ツリーがあれば各グラフを作成するのは簡単ですが、解析ツリーが変更されたときにグラフを更新する複雑さをどのように管理できますか？私たちはツリーがどのように変更されたかを正確に知っていますが、管理が難しくならない方法で変更を他のツリーにどのように伝播できますか？ 当然ながら、依存グラフは最初のグラフが変更されるたびに最初から再構築するだけで更新できますが、依存グラフの変更の詳細を知る方法はありません。 現在、この問題を解決する方法は4つありますが、それぞれに問題があります。 従属ツリーのノードはそれぞれ、元のツリーの関連ノードを監視し、必要に応じて自身と元のツリーノードのオブザーバーリストを更新します。これの概念的な複雑さは困難になる可能性があります。 元のツリーの各ノードには、それに依存する従属ツリーノードのリストがあり、ノードが変更されると、従属ノードにフラグを設定して、従属ノードの親を含め、ダーティとしてマークします。ルートに。変更のたびに、依存グラフを最初から作成するアルゴリズムとよく似たアルゴリズムを実行しますが、クリーンノードをスキップして各ダーティノードを再構築し、再構築されたノードが実際にダーティノードと異なるかどうかを追跡します。これも注意が必要です。 元のグラフと従属グラフの間の論理的な接続を、おそらく宣言型言語を使用して設計された制約のリストのようなデータ構造として表すことができます。元のグラフが変更された場合、違反している制約と違反を修正するために依存ツリーをどのように変更する必要があるかを見つけるためにリストをスキャンするだけで、すべてデータとしてエンコードされます。 既存の依存グラフがないかのように、依存グラフを最初から再構築し、既存のグラフと新しいグラフを比較して、どのように変化したかを確認できます。違いを検出するために利用できるアルゴリズムがあることを知っているので、これが最も簡単な方法であると確信していますが、それらはすべて非常に計算コストが高く、原則として不要と思われるため、このオプションは意図的に避けています。 この種の問題に対処する正しい方法は何ですか？確かに、このすべてをほぼ簡単にするデザインパターンがなければなりません。この一般的な説明のすべての問題に対して適切な解決策があると便利です。このクラスの問題には名前がありますか？ この問題が引き起こすトラブルについて詳しく説明しましょう。この問題は、プロジェクトの2つの部分がグラフを操作するたびにさまざまな場所で発生します。各グラフは、ソフトウェアの実行中に変化する同じものの異なる表現です。これはインターフェースのアダプターを作成するようなものですが、単一のオブジェクトまたは固定数のオブジェクトをラップする代わりに、任意のサイズのグラフ全体をラップする必要があります。 私がこれを試す度に、私は混乱して維持不可能な混乱に終わります。オブザーバーの制御フローは、複雑になると追跡が困難になる可能性があります。あるグラフを別のグラフに変換するアルゴリズムは、通常、レイアウトが明確で複数のクラスにまたがっていない場合に追跡するには十分な注意が必要です。問題は、元のグラフが変更されているときに、単純で単純なグラフ変換アルゴリズムだけを使用する方法がないように見えることです。 当然のことながら、通常のグラフ変換アルゴリズムを直接使用することはできません。ゼロから開始する以外の方法で変更に対応できないためです。代わりの方法は何ですか？おそらく、アルゴリズムは継続渡しスタイルで記述できます。この場合、アルゴリズムの各ステップは、ビジターのように、元のグラフのノードのタイプごとにメソッドを持つオブジェクトとして表されます。次に、さまざまな単純なビジターを組み合わせてアルゴリズムを組み立てることができます。 別の例：JPanelsとレイアウトマネージャーを使用して、Java Swingの場合と同じようにレイアウトされたGUIがあるとします。複雑なレイアウトマネージャーの代わりにネストされたJPanelsを使用することでそのプロセスを簡略化できるため、レイアウト目的でのみ存在し、それ以外の場合は無意味なノードを含むさまざまなコンテナーのツリーになります。ここで、GUIの生成に使用されたものと同じツリーがアプリケーションの別の部分でも使用されていると想定しますが、ツリーをグラフィカルにレイアウトする代わりに、抽象表現ツリーをフォルダーのシステムとして生成するライブラリーを操作します。このライブラリを使用するには、レイアウトノードを持たないバージョンのツリーが必要です。レイアウトノードを親ノードにフラット化する必要があります。 もう1つの見方：可変ツリーを操作するというまさにその概念は、デメテルの法則に違反しています。構文解析ツリーや構文ツリーが通常のように値である場合は、実際には法律違反にはなりませんが、その場合は何も最新の状態に保つ必要がないため問題はありません。それで、この問題はデメテルの法則に違反した直接の結果として存在しますが、ドメインがツリーまたはグラフの操作に関するものであるように思われる場合、一般的にどのようにそれを回避しますか？ 複合パターンは、 1つのオブジェクトにグラフを回すとデメテルの法則に従うための素晴らしいツールです。ある種類のツリーを別の種類のツリーに効果的に変換するために複合パターンを使用することは可能ですか？抽象構文木や制御フローグラフのように機能するように、複合解析ツリーを作成できますか？単一責任の原則に違反せずにそれを行う方法はありますか？複合パターンは、クラスが彼らが触れるすべての責任を吸収する傾向がありますが、おそらくそれは戦略パターンと何らかの形で組み合わせることができます。

8 design  design-patterns  language-agnostic  data-structures  object-oriented-design 

私が以前に本当に考えたことがないもの（AS3構文）： private var m_obj:Object; protected function get obj():Object { return m_obj; } private var m_str:String; protected function get str():String { return m_str; } 少なくともサブクラスはm_objまたはm_strを設定できません（ただし、m_objを変更することはできます）。 私の質問：これは単なる露骨なやりすぎですか？ このプログラマーの質問： 単純にパブリックプロパティにするのではなく、クラスプロパティのゲッター/セッターをいつまたはなぜ使用する必要があるのでしょうか。 重複として提案されています。 その質問は、パブリックプロパティとプライベートプロパティのみを扱い、プロパティをゲッターとセッターでラップする必要があるかどうかという点で異なります。私の質問では、保護された変数と、継承するクラスがそれらの変数とどのように相互作用するかに焦点を当てています。 したがって、代替実装は次のようになります。 protected var m_obj:Object; //more accessible than a private variable with a protected getter protected var m_str:String; //more accessible than a …

8 object-oriented-design  inheritance  encapsulation  properties 

設定ファイルを生成するGUIアプリケーションに取り組んでいます。構成モデルのクラス階層があり、その階層のオブジェクトツリーをいくつかの異なるコンテキストで使用しています。現在、ビジターパターンを使用して、コンテキスト固有のコードでモデルクラスを汚染しないようにしています。 interface IConfigurationElement { void acceptVisitor(IConfigurationElementVisitor visitor); } 以前のバージョンinstanceofでは、ビジターの代わりに一連の条件を使用していました。2つのアプローチを比較すると、次のトレードオフが見られます。 ビジター 新しいを追加する方が簡単で安全IConfigurationElementです。新しい宣言をに追加するだけIConfigurationElementVisitorで、コンパイラはすべてのビジター実装に対してエラーを生成します。ではinstanceofチェーンあなたは、新しい構成要素を拡張する必要があるすべての場所を覚えておく必要があります。instanceof複数の場所でロジックを複製するため、基本的にDRY原則に違反します。 訪問者パターンは一連の条件よりも効率的ですinstanceof instanceof の大きな利点instanceofは、その柔軟性です。たとえば、場合instanceof によっては同様にIConfigurationElement処理する必要がある実装のさまざまなサブセットに対して特別なソリューションを定義できます。対照的に、Visitorでは毎回、各実装クラスのメソッドを実装する必要があります。 この種の問題に対する一般的な解決策はありますか？どういうわけかビジターを適応させることができるので、いくつかのケースに共通のソリューションを提供できますか？

8 java  design-patterns  object-oriented-design 

非常に使いにくいだけでなく、非常に便利なCライブラリの周りに拡張可能なC ++ラッパーを作成しました。目標は、オブジェクトの割り当て、プロパティの公開、オブジェクトの割り当て解除、セマンティクスのコピーなどのためにc ++の便利さを持たせることです... 問題はこれです。Cライブラリは、基になるオブジェクト（オブジェクトへのポインタ）を必要とする場合があり、クラスデストラクタは、基になるメモリを破棄しないでください。ほとんどの場合、デストラクタは基になるオブジェクトの割り当てを解除する必要があります。bool hasOwnershipクラスにフラグを設定して、デストラクタ、代入演算子などが、基礎となるメモリを解放する必要があるかどうかがわかるように実験しました。ただし、これはユーザーにとって煩雑であり、別のプロセスがそのメモリをいつ使用するかを知る方法がない場合もあります。 現在、基本的な型と同じ型のポインターから割り当てが行われる場合に、hasOwnershipフラグを設定するように設定しています。オーバーロードされたコンストラクターがcライブラリーからのポインターを使用して呼び出されたときも、同じことを行います。それでも、ユーザーがオブジェクトを作成し、それをc_apiを呼び出す関数の1つに渡した場合、これはまだ処理されません。ライブラリは、後で使用するためにポインターを格納します。オブジェクトを削除した場合、Cライブラリでsegfaultが発生することは間違いありません。 このプロセスを簡略化するデザインパターンはありますか？多分ある種の参照カウント？

8 c++  design-patterns  object-oriented-design 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 JavaのBigIntegerクラスに、数値リテラルを取得できるコンストラクターがないのはなぜですか？私はBigIntegerを使用するたびに、そして多くの場合、それらについて単に考えているだけで、これは不思議に思います。 Javaの設計者は、存在するはずの1つの圧倒的な便利さにもかかわらず、1つを除外しなければならなかったのはなぜでしょうか。

8 java  design  language-design  object-oriented-design 

私は何年にもわたって多くのJavaScriptを実行してきましたが、特にモジュールパターンを使用して、よりオブジェクト指向のアプローチを使用しています。より大きなコードベースがスパゲッティになることを避けるために、どのようなアプローチを使用しますか？「最善のアプローチ」はありますか？

8 javascript  object-oriented-design 

エンタープライズアプリケーションを開発しようとしているが、アジャイルプロセスから理解できる限り、機能を小さなチャンクに分割し、それらを繰り返し開発します。データベースとアプリケーションのコアを最初に作成してから、これらを繰り返し拡張していました。 問題は、以前に使用していたことを維持する必要がありますか（コアを最初に開発する必要がありますか）、ストーリーの開発にコア開発を分配する必要がありますか？後で、私はコードが将来の拡張のために十分に柔軟であるかどうか確信がありません！ 何か案が？

8 architecture  agile  object-oriented-design