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

私はDI / IOCの大ファンです。ハードな依存関係の処理/抽象化に最適であり、作業が少し楽になります。 しかし、私はそれについて少し不満があり、それを解決する方法がわかりません。 DI / IOCの基本的な考え方は、オブジェクトがインスタンス化されると、その依存関係はすべてコンストラクター内で事前に入力されるということです。 ただし、IMHOには、コンストラクター用のパラメーターのタイプがいくつかあります（特にオブジェクトが不変の場合）。 依存関係（オブジェクトが機能するために必要なオブジェクト） 構成（作業を行うために必要な環境に関する情報） パラメーター（作業が行われるデータ） IOCは依存関係でうまく機能することがわかりました。しかし、私はまだ他の2つに対処する最善の方法を考えています。ただし、コンストラクターはIOCコンテナーによって実行されるように実行されるため、これらのアイテムをIOCコンテナーに配置する必要があるようです。 人々が採用している戦略/パターンと、人々が発見した利点と欠点を知りたい。 NB。これは非常に主観的な質問であることを認識しており、SEガイドラインに従って「良い」主観的な質問にしようとしました。

18 design-patterns  configuration-management  inversion-of-control 

私は、最適な答えに達することなく、これについて本当に長い間考えてきました。 まず第一に、私はプログラミングを愛する医師ですが、家庭学習と何年もの間自由な時間にコードをいじる以外は、実際に勉強したことはありません。 現在、私は自分のクリニックを管理するための小さなプロジェクトを構築しようとしています。それを行うために、私ができるようにしたいオプションのリストを作成することから始めました。 例： アクティブな患者記録。 さまざまな役割による認証（例：patient、nurse、dr） 予定表（予定表に予定の予防接種/手術などを含む） 医師が独自のプラグインを作成できるようにします。 医師が統計を表示するためのダッシュボード それから、codeigniter / mysql / php / jqueryでコーディングを開始しました。 開発中の私のステップ：- 最初のデータベース。 まず、必要なすべてのテーブルを作成しました。 これらのテーブルを処理するためにすべてのモデルを作成しました（テーブルの関係も考慮しながら、基本的な読み取り/書き込み/更新/検証を処理する1つのマスターモデル その後、ビューとコントローラーのコーディングを開始します。最初にビューHTMLを作成してから、このビューを処理するコントローラーを作成し、ビューの相互作用を機能させるためのコーディング関数を開始しました。 予約ビューをコーディングする場合の例（controller booking.php）： ユーザーがクリックすると、このレイアウトが作成され、テーブルtdがクリック可能になります：jquery get（booking / add_patient_form）and pop up ユーザーが保存するとき：予約/保存に投稿-予定を保存してからindex（）関数を再読み込みします など。そして、ビュー全体とプロジェクト全体を達成するために、このビューに必要なすべてのロジックを含むビューとそのコントローラーを作成する同じステップを続けました。 最後にすべてのターゲット機能が正常に機能しましたが、最初から計画がなく、プロジェクト全体がこれまでに何の計画もなくブレインストーミングとデバッグのパンチであったため、このプロジェクトに行った後、保守性と柔軟性にこだわっています！そしてそれらを一緒にリンクすることはできません。 私は、ウェブサイトのすべてのページが他のページから完全に分離されていると感じています。各ページがどのように読み込まれ、どの機能が内部にあるのかを覗き見ることさえ思い出せません！ とにかくこれを回復してデザインを出すことができますか？

18 php  mysql  design-patterns  workflows 

ブリッジ設計パターンは、プログラムのインターフェースから実装を分離します。 なぜこれが有利なのですか？

18 design-patterns 

私はプログラミングの記事を読んでいて、デコレーターパターンについて言及していました。私はしばらくの間プログラミングを行ってきましたが、正式な教育やトレーニングは一切受けていませんが、標準的なパターンなどについて学ぼうとしています。 それで、デコレータを調べて、ウィキペディアの記事を見つけました。デコレータパターンの概念は理解できましたが、この文章に少し混乱しました。 例として、ウィンドウシステムのウィンドウを考えます。ウィンドウのコンテンツのスクロールを許可するには、必要に応じて、水平または垂直のスクロールバーを追加することができます。ウィンドウはWindowクラスのインスタンスによって表され、このクラスにはスクロールバーを追加する機能がないと想定します。それらを提供するサブクラスScrollingWindowを作成するか、この機能を既存のWindowオブジェクトに追加するScrollingWindowDecoratorを作成できます。この時点で、どちらのソリューションでも問題ありません。 ここで、ウィンドウに境界線を追加する機能も必要であると仮定します。繰り返しますが、元のWindowクラスにはサポートがありません。ScrollingWindowサブクラスは、新しい種類のウィンドウを効果的に作成したため、問題を引き起こします。すべてのウィンドウに境界線のサポートを追加する場合、サブクラスWindowWithBorderおよびScrollingWindowWithBorderを作成する必要があります。明らかに、この問題は新しい機能が追加されるたびに悪化します。デコレータソリューションの場合、新しいBorderedWindowDecoratorを作成するだけです。実行時に、既存のウィンドウをScrollingWindowDecoratorまたはBorderedWindowDecorator、あるいはその両方で装飾することができます。 OK、すべてのウィンドウに境界線を追加するように言ったら、オプションを許可するために元のWindowクラスに機能を追加するだけではどうですか？私の見方では、サブクラス化はクラスに特定の機能を追加したり、クラスメソッドをオーバーライドしたりするためのものです。既存のすべてのオブジェクトに機能を追加する必要がある場合、スーパークラスを変更するだけではいけないのはなぜですか？ 記事には別の行がありました： デコレータパターンは、サブクラス化の代替です。サブクラス化はコンパイル時に動作を追加し、変更は元のクラスのすべてのインスタンスに影響します。装飾は、個々のオブジェクトの実行時に新しい動作を提供できます。 「...変更は元のクラスのすべてのインスタンスに影響します」と言っている場所がわかりません-サブクラス化は親クラスをどのように変更しますか？それがサブクラス化のポイントではないでしょうか？ この記事は、多くのWikiのように、明確に書かれていないことを前提としています。その最後の行で、デコレータの有用性を確認できます-「...個々のオブジェクトに対して実行時に新しい動作を提供します。」 このパターンを読んでいなくても、個々のオブジェクトの実行時の動作を変更する必要がある場合、おそらく、この動作を有効または無効にするメソッドをスーパークラスまたはサブクラスに組み込みます。デコレータの有用性、そして初心者の考え方に欠陥がある理由を本当に理解してください。

18 programming-languages  object-oriented  design-patterns 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 SOでPACについての質問に出会ったばかりで、そのパターンに興味を持ちました。なぜMVCほど広く使用されていないのだろうか？PACと比較したMVCの利点は何ですか？

18 design-patterns 

テストビルダーがあり、教師がテスト用の一連の質問を作成できるようにしたとします。 ただし、すべての質問が同じというわけではありません。複数の選択肢、テキストボックス、一致などがあります。これらの質問タイプはそれぞれ、異なるタイプのデータを保存する必要があり、作成者と受験者の両方に異なるGUIが必要です。 私は2つのことを避けたいです： 型チェックまたは型キャスト データコード内のGUIに関連するもの。 私の最初の試みでは、次のクラスになりました。 class Test{ List<Question> questions; } interface Question { } class MultipleChoice implements Question {} class TextBox implements Question {} ただし、テストを表示すると、必然的に次のようなコードになります。 for (Question question: questions){ if (question instanceof MultipleChoice){ display.add(new MultipleChoiceViewer()); } //etc } これは本当に一般的な問題のように感じます。上記の項目を避けながら、多態的な質問をすることができるデザインパターンはありますか？それとも、多型はそもそも間違った考えですか？

17 design-patterns  polymorphism 

私はこの表現とパターンを昔に教えられました。確かに、その名前は、水を汲み出す前に水で満たす必要があった古いポンプに由来しますが、誰が気にしますか？ここでコードについて話しています。 いくつかの本当に良い例と、パターンが達成することの説明は歓迎されます。このパターンは今日どのように考えられていますか？ プライミングは時々、欠陥のあるループを動作させることができますが、DRYを犠牲にします。したがって、より良い設計への道の途中で一時停止することがあります。これはアンチパターンと見なされますか？代替手段はありますか？

17 design-patterns  anti-patterns  loops 

四半世紀前に私がC ++を学んでいたとき、インターフェースは寛容であるべきだと教えられました。消費者は代わりにソースやドキュメントにアクセスできないかもしれないので、メソッドが呼び出される順番を気にしないでくださいこの。 しかし、私がジュニアプログラマーや上級開発者を指導したときはいつでも、彼らは驚いたことに反応し、これは本当にこれが本当のことなのか、それとも流行から外れたのかと疑問に思いました。 泥のように明確ですか？ これらのメソッド（データファイルを作成するための）とのインターフェイスを検討してください。 OpenFile SetHeaderString WriteDataLine SetTrailerString CloseFile もちろん、これらを順番に実行することもできますが、ファイル名（考えてみてくださいa.out）や、含まれているヘッダーとトレーラーの文字列については気にしないと言って、単に呼び出すことができますAddDataLine。 それほど極端ではない例として、ヘッダーとトレーラーを省略する場合があります。 さらに、ファイルを開く前にヘッダーとトレーラーの文字列を設定することもできます。 これは認識されているインターフェイス設計の原則ですか、それとも名前が与えられる前のPOLAの方法ですか？ NBは、このインターフェイスの詳細に動揺することはありません。これは、この質問のための単なる例です。

17 design  design-patterns  interfaces 

ロバートC.マーティンによると、SRPは次のよ​​うに述べています。 クラスが変更される理由は1つだけです。 ただし、彼の本Clean Code、第3章：関数では、次のコードブロックを示しています。 public Money calculatePay(Employee e) throws InvalidEmployeeType { switch (e.type) { case COMMISSIONED: return calculateCommissionedPay(e); case HOURLY: return calculateHourlyPay(e); case SALARIED: return calculateSalariedPay(e); default: throw new InvalidEmployeeType(e.type); } } そして次のように述べます： この機能にはいくつかの問題があります。まず、それは大きく、新しい従業員タイプが追加されると成長します。第二に、非常に明確に複数のことを行います。第三に、変更する理由は複数あるため、単一責任原則（SRP）に違反しています。[強調鉱山] まず、SRPはクラスに対して定義されていると思いましたが、関数にも適用できることがわかりました。第二に、この関数には複数の変更理由がありますか？従業員の変更が原因で変更が確認できます。

17 design-patterns  single-responsibility 

以下の例を考えてください。ColorChoice列挙の変更は、すべてのIWindowColorサブクラスに影響します。 列挙型は脆弱なインターフェースを引き起こす傾向がありますか？多態的な柔軟性を可能にする列挙型よりも優れたものはありますか？ enum class ColorChoice { Blue = 0, Red = 1 }; class IWindowColor { public: ColorChoice getColor() const=0; void setColor( const ColorChoice value )=0; }; 編集：私の例として色を使用して申し訳ありませんが、それは質問についてのものではありません。これは、ニシンを避け、柔軟性の意味についてより多くの情報を提供する別の例です。 enum class CharacterType { orc = 0, elf = 1 }; class ISomethingThatNeedsToKnowWhatTypeOfCharacter { public: CharacterType getCharacterType() const; void setCharacterType( const CharacterType …

17 design-patterns  c++  interfaces  enum  abstract-class 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 ソフトウェアデザインパターンを使用しない場合、どのような問題に直面する可能性がありますか？標準のオブジェクト指向技術を使用して設計にアプローチする際の問題について教えてください。

17 design-patterns 

初期化するいくつかのオブジェクトの異なる実装を使用する必要がないコンストラクターを考えると、DIを使用することは依然として実用的ですか？結局のところ、まだ単体テストが必要な場合があります。 問題のクラスは、コンストラクター内の他のいくつかのクラスを初期化し、使用するクラスは非常に具体的です。別の実装を使用することはありません。インターフェイスにプログラムしようとするのを避けることは正当化されますか？

17 design-patterns  dependency-injection 

この画像は、ドメイン駆動のデザインとパターンの適用：C＃および.NETの例を使用したものです。 これは、a がその存続期間中に異なる状態を持つことができる状態パターンのクラス図ですSalesOrder。異なる状態間では特定の遷移のみが許可されます。 これでOrderStateクラスはabstractクラスになり、そのすべてのメソッドはそのサブクラスに継承されます。Cancelled他の状態への遷移を許可しない最終状態であるサブクラスを考慮する場合override、このクラスのすべてのメソッドで例外をスローする必要があります。 サブクラスは親の振る舞いを変えてはいけないので、今ではそれはリスコフの代用原則に違反していないのですか？抽象クラスをインターフェイスに変更すると、これが修正されますか？ これはどのように修正できますか？

17 java  c#  design-patterns  object-oriented-design  liskov-substitution 

LSPは、クラスがその基本クラスの代わりになるべきであると述べています。つまり、派生クラスと基本クラスは意味的に同等でなければなりません。 しかし、LSPはインターフェイスを実装するクラスにも適用されますか？言い換えると、クラスによって実装されたインターフェイスメソッドが、ユーザーが期待するものと意味的に異なる場合、これはLSPの違反と見なされますか？

17 design-patterns  design-principles  liskov-substitution 

リポジトリを実装します。リポジトリのコンシューマは複数の操作を実行でき、一度にコミットしたいので、UOWパターンを使用したいと思います。 問題に関するいくつかの記事を読んだ後、他の方法で行われている記事によっては、この2つの要素を関連付ける方法がまだわかりません。 UOWはリポジトリの内部にある場合があります。 public class Repository { UnitOfWork _uow; public Repository() { _uow = IoC.Get<UnitOfWork>(); } public void Save(Entity e) { _uow.Track(e); } public void SubmittChanges() { SaveInStorage(_uow.GetChanges()); } } そして時々それは外部です： public class Repository { public void Save(Entity e, UnitOfWork uow) { uow.Track(e); } public void SubmittChanges(UnitOfWork uow) { SaveInStorage(uow.GetChanges()); …

17 design-patterns  architecture  unit-of-work  repository-pattern