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

したがって、私がかなり頻繁に遭遇する状況は、私のモデルが次のいずれかを開始する状況です。 たくさんの方法でモンスターに成長する または SQLの一部をそれらに渡すことができるため、数百万の異なるメソッドを必要としないほど柔軟です たとえば、「ウィジェット」モデルがあるとします。いくつかの基本的な方法から始めます。 get（$ id） insert（$ record） update（$ id、$ record） 削除（$ id） getList（）//ウィジェットのリストを取得 それはすべてうまくできていますが、いくつかのレポートが必要です。 listCreatedBetween（$ start_date、$ end_date） listPurchasedBetween（$ start_date、$ end_date） listOfPending（） そして、レポートは複雑になり始めます。 listPendingCreatedBetween（$ start_date、$ end_date） listForCustomer（$ customer_id） listPendingCreatedBetweenForCustomer（$ customer_id、$ start_date、$ end_date） これがどこで成長しているのかを見ることができます...最終的には、非常に多くの特定のクエリ要件があるため、大量のメソッドを実装するか、単一の-> query（query $ query）メソッド... ...または単に弾丸を噛んで、次のようなことを始めてください： list = MyModel-> query（ "start_date> X AND end_date <Y AND pending = …

17 design-patterns  mvc 

OOPのバックグラウンド（Java）から来て、私は自分でScalaを学んでいます。不変オブジェクトを個別に使用することの利点はすぐにわかりますが、そのようなアプリケーション全体をどのように設計できるかを見るのは大変です。例を挙げます。 「マテリアル」とそれらのプロパティを表すオブジェクト（ゲームを設計しているので、実際にその問題を抱えている）があり、たとえば水や氷があるとします。このようなすべてのマテリアルインスタンスを所有する「マネージャー」がいます。1つの特性は、凝固点と融点、および材料が凍結または融解するものです。 [編集]すべてのマテリアルインスタンスは「シングルトン」で、Java Enumのようなものです。 「水」は0℃で「氷」に凍結し、「氷」は1℃で「水」に融解すると言います。しかし、水と氷が不変である場合、それらの1つを最初に作成する必要があり、コンストラクターパラメーターとしてまだ存在しない他のものへの参照を取得できなかったため、コンストラクターパラメーターとして相互参照を取得できません。両方のマネージャーへの参照を提供することでこれを解決することができますので、彼らは凍結/融解特性を求められるたびに必要な他の材料インスタンスを見つけるためにクエリすることができますが、マネージャー間で同じ問題が発生しますそして、それらはお互いへの参照を必要としますが、それらのうちの1つのコンストラクターでのみ提供できるため、マネージャーまたはマテリアルは不変にできません。 彼らはこの問題を回避する方法がないのですか、それとも「機能的な」プログラミング技術、またはそれを解決するための他のパタ​​ーンを使用する必要がありますか？

17 design-patterns  immutability 

デザインの乾燥を進めているとき、「今は絶対にない」ということをよく受け入れます。通常、私は、他の知識のシステムのコンテキストで、ある知識についての1つの信頼できる場所の理解を深める必要があると感じています。したがって、私はシステムを「今」設計する傾向があります。 反対に、このプラクティスにより、私はそれを必要としない合理的なチャンスにもかかわらず、かなり前もって構築することになります。 これら2つのパターンはどのように正方形になりますか それらがうまく動作することを保証するためにどのようなプラクティスを使用しますか？ 混乱を招くことなくそれらをどのように教えますか？

17 design-patterns  language-agnostic  philosophy 

ジレンマ オブジェクト指向の実践に関するベストプラクティスの本をたくさん読んでいますが、読んだ本のほとんどすべてに、enumはコードの匂いだと言う部分がありました。列挙型が有効な場合に説明する部分を見逃したと思います。 そのように、私を探していますガイドラインおよび/またはユースケースの列挙型がありませ有効な構文コードのにおいと、実際に。 ソース： 「警告経験則として、列挙型はコードの匂いであり、多態性クラスにリファクタリングする必要があります。[8]」Seemann、Mark 、. 342 [8] Martin Fowler et al。、Refactoring：Improving the Design of Existing Code（New York：Addison-Wesley、1999）、82。 環境 私のジレンマの原因は取引APIです。このメソッドを介して送信することにより、Tickデータのストリームを提供します。 void TickPrice(TickType tickType, double value) どこ enum TickType { BuyPrice, BuyQuantity, LastPrice, LastQuantity, ... } 変更を壊すことがこのAPIの生き方であるため、このAPIのラッパーを作成しようとしました。ラッパーで最後に受信した各ティックタイプの値を追跡したいので、ダニタイプのディクショナリを使用してそれを行いました。 Dictionary<TickType,double> LastValues 私には、キーとして使用される場合、これは列挙型の適切な使用のように思えました。しかし、私はこのコレクションに基づいて意思決定を行う場所があり、switchステートメントを排除する方法を考えることができないため、工場を使用できますが、その工場にはまだどこかにswitchステートメント。私はただ物事を動かしているように見えましたが、まだ匂いがします。 列挙型のDO N'Tを見つけるのは簡単ですが、DOはそれほど簡単ではありません。人々が自分の専門知識、長所と短所を共有できるなら、私はそれを感謝します。 考え直し 一部の決定とアクションはこれらに基づいておりTickType、enum / switchステートメントを削除する方法を考えることはできないようです。私が考えることができる最もクリーンなソリューションは、ファクトリを使用し、に基づいて実装を返すことTickTypeです。それでも、インターフェイスの実装を返すswitchステートメントがあります。 以下は、間違った列挙型を使用しているのではないかと疑っているサンプルクラスの1つです。 public class ExecutionSimulator { …

17 c#  design-patterns  object-oriented  refactoring  enum 

私は現在、より大きなソロプロジェクトに取り組んでおり、インスタンスを作成する理由がわからないクラスがいくつかあります。 たとえば、現在のダイスクラスはすべてのデータを静的に格納し、そのメソッドもすべて静的です。サイコロを転がして新しい値を取得したいときは、を使用するだけなので、初期化する必要はありませんDice.roll()。 私はこのような主な機能を1つだけ持っているいくつかの類似したクラスを持ち、すべてのイベントを担当する一種の「コントローラー」クラスで作業を開始しようとしています（プレイヤーが移動したとき、そうです）、このクラスでも同じ考えに従うことができることがわかりました。これらの特定のクラスに対して複数のオブジェクトを作成する予定はないので、それらを完全に静的にすることは悪い考えでしょうか？ Javaに関しては、これが「悪い習慣」と見なされるのかと思っていました。私が見たものから、コミュニティはこのトピックに関して一種の分裂のように思われますか？とにかく、私はこれに関するいくつかの議論が大好きだし、リソースへのリンクも素晴らしいでしょう！

16 java  design  design-patterns  object-oriented-design  static-access 

私は過去4年間javascriptを扱ってきました。私は自分の問題解決スキルに非常に自信があり、コードの品質が向上していることがわかります。私はコミュニティの最新情報を取得しようとしていますが、現在ES2015とReact.jsを使用しています。しかし、プログラミングの設計パターンをまったく把握できないと感じています。私はこれについてのリソースを見つける場所を知っており、私はすでにそれについての本を読んでいます。私はプロジェクトの構造について意思決定をするのに先輩に頼っていますが、それに取り組むのに問題はありません。 自分で何かを開始する必要があるときはいつでも、次の2つのパスを探します。もっと小さいものを使用している場合は、モジュールパターンを使用します。このテーマに関する理解が深まると、より良い決定を下せるようになることはわかっていますが、今のところは完全に失われています。 これに関する優れた教育を探すべきですか？このテーマに関する指導者は必要ですか？私はただ愚かですか？これは本当に理解しにくいですか？

16 design-patterns  javascript 

GUIコントロールを表すクラスの階層があります。このようなもの： Control->ContainerControl->Form さまざまなことを行うオブジェクトで動作する一連のアルゴリズムを実装する必要があり、Visitorパターンが最もクリーンなソリューションになると考えています。たとえば、オブジェクトの階層のXML表現を作成するアルゴリズムを考えてみましょう。「クラシック」アプローチを使用して、私はこれを行います： public abstract class Control { public virtual XmlElement ToXML(XmlDocument document) { XmlElement xml = document.CreateElement(this.GetType().Name); // Create element, fill it with attributes declared with control return xml; } } public abstract class ContainerControl : Control { public override XmlElement ToXML(XmlDocument document) { XmlElement xml = base.ToXML(document); // …

16 c#  design-patterns  object-oriented-design 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私は8〜10年前にC ++を広範囲に記述していました。それ以来、専門的な理由でC＃に移行しました。しかし、時々私は次のような声明を見ます 「まだポインタ参照を手動で追跡している場合は、間違っています」 または 「C ++は、RAIIのような最新のコンセプトを使用しており、回復中のC開発者のようにメモリを手動で割り当てない限り、完全に安全です。」 どちらも10年前の標準的な手順でした。最近、C ++がかなり改善されているのを見てきました。特にC ++ 0xには、いくつかの新しい機能があるようです。「C / old C ++」プログラマーが「最新」のC ++パターンとプラクティスに追いつくための最適なリソースは何ですか？

16 c++  design-patterns  c  programming-practices  c++11 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 OOPの継承の概念を説明しようとする場合、一般的な例は哺乳類の例です。私見、これは本当に悪い例です。なぜなら、初心者がこの概念を間違った方法で使用するようになるからです。さらに、彼らが日々のデザインの仕事で直面するのは一般的なデザインではありません。 それでは、継承を使用して解決される素敵でシンプルで具体的な問題は何でしょうか？

16 design-patterns  object-oriented  inheritance 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 プロのプログラマーとしての短い時間で、教育を受けたプログラマーによって書かれた多くのアプリケーションを、.NET 2.0ブックの最初の数章を読んでいるように見ました。 私が始めたとき、私はそれらのアプリケーションのほとんどを書きました！ AWESOME .NETアプリケーションを作成するために重要な最大の設計パターンは何ですか？ 素晴らしいとは、私も内側を意味します！

16 c#  .net  design-patterns 

プログラミングのパターンとアンチパターンに対する強迫観念を誰かが説明できますか？どんなパターンが何を意味するのか全くわからないからです。プログラミングタスクに直面したとき、問題について少し考え、関連すると思われるデータ構造を書き留め、ソリューションのプロトタイプを作成し、いくつかのモジュールを分離して繰り返します。プロセスのどこにも「ああ、ここにFunkyLookyTasticパターンが必要」とは思いません。

16 programming-practices  design-patterns  anti-patterns 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 デザインパターンの分野で同僚を教育しようとしています。オリジナルのGang of Fourパターンの一部は少し難解なので、すべてのプログラマーが知っておくべき「必須」パターンのサブグループがあるのではないかと思っています。リストを見ると、おそらく使用したと思う- 抽象工場 工場工法 シングルトン ブリッジ ファサード コマンド 実際にどれを実際に使用しますか、また何に使用しますか？ パターンのリストが必要な人のためのリンク

16 design-patterns 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私はそこにある設計パターンの量に気づかずにはいられません。 誰が私がそれらを学ぶべきである注文について提案をしますか？または、それらをランダムに選択する必要がありますか？ これまでのところ、私が知っているのはシングルトンだけです。

16 learning  design-patterns 

考慮してください： public class CtorInjectionExample { public CtorInjectionExample(ISomeRepository SomeRepositoryIn, IOtherRepository OtherRepositoryIn) { this._someRepository = SomeRepositoryIn; this._otherRepository = OtherRepositoryIn; } public void SomeMethod() { //use this._someRepository } public void OtherMethod() { //use this._otherRepository } } に対して： public class MethodInjectionExample { public MethodInjectionExample() { } public void SomeMethod(ISomeRepository SomeRepositoryIn) { //use SomeRepositoryIn } …

16 design-patterns  programming-practices  dependency-injection  patterns-and-practices 

if / thenの場合にコードを書くことができるのに、なぜ戦略パターンを使用するのが有益なのですか？ 例：TaxPayerクラスがあり、そのメソッドの1つが異なるアルゴリズムを使用して税金を計算します。では、なぜif / thenケースを持ち、戦略パターンを使用する代わりに、そのメソッドで使用するアルゴリズムを見つけられないのでしょうか？また、なぜTaxPayerクラスの各アルゴリズムに個別のメソッドを実装できないのですか？ また、実行時にアルゴリズムが変更されるとはどういう意味ですか？

15 design  design-patterns  object-oriented-design  patterns-and-practices  strategy