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

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 最近、私はMVCとそれがウェブに合わないことに関するいくつかのブログ投稿を読んでいました。RMR Architectureのような代替パターンについて学びました。 MVCのほかに、人々がWebで使用している他のパターンに興味がありますか？また、パターンを実装するフレームワークがある場合は、そのリンクを投稿してください。

24 design-patterns  architecture  mvc 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 どのデザインパターンが最も人気があると思いますか？

24 design-patterns 

多くのBuilder Pattern例では、Builderビルドするオブジェクトの内部クラスを作成しています。 これは、Builderビルドの内容を示すため、ある程度意味があります。ただし、静的に型付けされた言語では、Builderビルドの内容がわかります。 一方、Builderが内部クラスである場合、の内部を見ずにビルドするクラスを知る必要BuilderがありBuilderます。 また、ビルダーを内部クラスとして使用すると、外部クラスから参照できるため、インポートの数が減ります（気になる場合）。 そして、がBuilder同じパッケージ内にあるが、のような内部クラスではない実用的な例がありStringBuilderます。あなたはそれがそう名付けられているので、構築するBuilder 必要があることを知っていStringます。 そうは言ってもBuilder、内部クラスを作成する理由として考えられる唯一の正当な理由は、クラスのBuilder名前を知らず、命名規則に依存せずにクラスが何であるかを知っているということです。たとえば、もし私がStringBuilder内部クラスだったStringとしたら、おそらく私がそれよりも早く存在したことを知っていただろう（投機的） Builder内なるクラスにする他の理由はありますか、それとも単に好みと儀式に帰着しますか？

24 java  design-patterns  object-oriented 

アクセサーと修飾子（セッターとゲッター）は、次の3つの主な理由で便利です。 これらは変数へのアクセスを制限します。 たとえば、変数にアクセスすることはできますが、変更することはできません。 パラメータを検証します。 彼らはいくつかの副作用を引き起こす可能性があります。 大学、オンラインコース、チュートリアル、ブログ記事、およびWeb上のコード例はすべて、アクセサと修飾子の重要性について強調しています。最近のコードには「必須」のように感じられます。したがって、以下のコードのように追加の値を提供しなくても、それらを見つけることができます。 public class Cat { private int age; public int getAge() { return this.age; } public void setAge(int age) { this.age = age; } } そうは言っても、実際にパラメーターを検証し、無効な入力が提供された場合に例外をスローしたりブール値を返したりする、より有用な修飾子を見つけることは非常に一般的です： /** * Sets the age for the current cat * @param age an integer with the valid values between …

23 design-patterns  constructors  access-modifiers 

バックグラウンド 現在、デバイスが送信および受信するオブジェクトを持っている状況があります。このメッセージには、次のようないくつかの構成要素があります。 public void ReverseData() public void ScheduleTransmission() ScheduleTransmissionこの方法は、必要呼び出すためにReverseData、それが呼ばれるたびにメソッドを。ただし、アプリケーションでオブジェクトがインスタンス化されている場所からReverseData外部で呼び出す必要がある場合があります（名前空間の外側に完全に追加する必要があります）。 「受信」に関してはReverseData、object_receivedイベントハンドラーで外部から呼び出されて、データを元に戻します。 質問 オブジェクトが独自のパブリックメソッドを呼び出すことは一般に許容されますか？

23 c#  design-patterns  object-oriented  methods 

私はデザインに取り組んでいますが、引き続き障害にぶつかっています。私は特定のクラス（ModelDef）を持っています。これは、本質的にXMLスキーマを解析することで構築された複雑なノードツリーの所有者です（DOMを考えてください）。優れた設計原則（SOLID）に従い、結果のシステムを簡単にテストできるようにします。DIを使用してModelDefのコンストラクターに依存関係を渡すつもりです（テスト中に必要に応じてこれらを簡単に交換できます）。 しかし、私が苦労しているのは、ノードツリーの作成です。このツリーは、個別にテストする必要のない単純な「値」オブジェクトで完全に構成されます。（ただし、これらのオブジェクトの作成を支援するために、Abstract FactoryをModelDefに渡すことができます。） しかし、私は、コンストラクターが実際の作業を行うべきではないことを読み続けています（例：Flaw：Constructor does Real Work）。「実際の作業」とは、後でテストのためにスタブアウトする可能性のある重い依存オブジェクトを構築することを意味する場合、これは私にとって完全に理にかなっています。（これらはDI経由で渡される必要があります。） しかし、このノードツリーなどの軽量の値オブジェクトはどうでしょうか。ツリーはどこかに作成する必要がありますよね？ModelDefのコンストラクター（buildNodeTree（）メソッドなどを使用）を使用しないのはなぜですか？ ModelDefの外でノードツリーを作成してから（コンストラクターDIを介して）渡したいとは思いません。スキーマを解析してノードツリーを作成するには、かなりの量の複雑なコードが必要です。 。私はそれを「グルー」コードに委ねたくありません（これは比較的簡単なはずで、おそらく直接テストされません）。 ノードツリーを作成するためのコードを別の「ビルダー」オブジェクトに入れることを考えましたが、実際にはビルダーパターン（テレスコープの排除に関心があると思われる）と一致しないため、「ビルダー」と呼ぶことをためらいます。コンストラクター）。ただし、別の名前（NodeTreeConstructorなど）を呼び出したとしても、ModelDefコンストラクターがノードツリーを構築するのを避けるために、ちょっとしたハックのように感じます。どこかに構築する必要があります。なぜそれを所有しようとしているオブジェクトではないのですか？

23 java  design  design-patterns  dependency-injection  constructors 

Dao、サービス、コントローラーの3つのレイヤーのSpring Webアプリがあります。コントローラーはdaoを直接呼び出すことはなく、サービス層を介して呼び出します。現時点では、ほとんどの場合、処理されないdao例外（ランタイム）があると、エンドユーザーにエラーメッセージを表示するJSPによってキャッチされます。サービス層はすべてのdao例外をキャッチし、それらをサービス例外としてラップする必要がありますか？ try { daoInstance.someDaoMethod(); } catch(DataAccessException dae) { throw new ServiceException("message", dae); } ServiceExceptionもランタイムであり、どちらも処理されないと仮定しましょう。ServiceExceptionの代わりにDataAccessExceptionをスローするだけの違いはありますか？私は、プレゼンテーション層がデータアクセス例外を認識すべきでないと考えました。しかし、単にそれらをラップするだけで回復不能な例外をキャッチするポイントは見当たりません。

23 design-patterns  exception-handling  spring  dao 

この問題に最適な設計パターンは次のとおりです。 オブジェクトAがあります。オブジェクトAは、ユーザーの要求に応じてデータベースに登録または削除できます。 データの検証は、オブジェクトの登録または削除の前に実行されます。オブジェクトを登録する前にチェックするルールのセットと、削除する別のルールのセットがあります。これらのルールの一部は、両方の操作に共通です。 これまでのところ、Chain of Responsibilityのデザインパターンが最も適していると思いますが、実装に問題があります。

23 design-patterns 

Objective-Cのブロックには2つの一般的なパターンがあります。1つはsuccess：/ failure：ブロックのペアであり、もう1つは単一のcompletion：ブロックです。 たとえば、非同期でオブジェクトを返すタスクがあり、そのタスクが失敗する可能性があるとしましょう。最初のパターンは-taskWithSuccess:(void (^)(id object))success failure:(void (^)(NSError *error))failureです。2番目のパターンは-taskWithCompletion:(void (^)(id object, NSError *error))completionです。 成功：/失敗： [target taskWithSuccess:^(id object) { // W00t! I've got my object } failure:^(NSError *error) { // Oh noes! report the failure. }]; 完了： [target taskWithCompletion:^(id object, NSError *error) { if (object) { // W00t! I've got my object …

23 design-patterns  objective-c 

私は素晴らしい投資銀行で2年間働いてきました。 私は、最適化されたコードを作成し、適応された優れたデザインパターン、ソリッド原則、デメテルの法則を尊重し、あらゆる種類のコードの重複を回避することを望んで、いくつかの技術プロジェクトを作りました 本番環境での配信=>バグがゼロの場合、すべてが期待どおりに行われています。 しかし、大部分の開発者は、すべてのコードが読解には複雑すぎることを正確にするために来ました。たとえば、「ifおよびinstanceofをいくつか作成し、ポリモーフィズムを忘れて、緊急の生産バグを修正するのが非常に簡単になるようにします」。私は答えることを好まなかった...... これらの開発者はまったく好奇心がないことを知っており、優れた設計を理解する努力を拒否しています（たとえば、90％の開発者は戦略パターンとは何かを知りません。 ）、私のプロジェクトマネージャーは、私は本当に間違ったやり方であり、世銀の世界にとって理想主義すぎると言った。 私に何をアドバイスしますか？本当に良いコードの欲求を維持するか、そうである開発者の大多数に私を適応させるならば、私によると、私による開発者の仕事のすべての美しさである設計コードによって本当に面白くないです。 それとも逆に、基本的なオブジェクト指向の原則とベストプラクティスを習得して、自分のコードに適応する必要がありますか？

23 java  design  design-patterns  solid 

次の方法を検討してください。 public List<Employee> GetAllEmployees() { using (Entities entities = new Entities()) { return entities.Employees.ToList(); } } public List<Job> GetAllJobs() { using (Entities entities = new Entities()) { return entities.Jobs.ToList(); } } public List<Task> GetAllTasksOfTheJob(Job job) { using (Entities entities = new Entities()) { return entities.Tasks.Where(t => t.JobId == job.Id).ToList(); } …

23 c#  design-patterns  dry 

ファクトリー・パターン（または少なくともの使用FactoryFactory..）は、次のような多くのジョークのお尻です。 RequestProcessorFactoryFactory.RequestProcessorFactoryのような詳細で「創造的な」名前の他に、Java / C ++でプログラミングする必要があり、Abstract_factory_patternのユースケースがある場合、ファクトリパターンに根本的な問題はありますか？ 他の一般的な言語（RubyやScalaなど）を使用して、同様の複雑さを管理する必要はありませんか？ 私が尋ねる理由は、Java / Java EEエコシステムのコンテキストで言及されている工場の批判がほとんど見られますが、他の言語/フレームワークがそれらをどのように解決するかについては説明しません。

23 java  design-patterns 

私たちのコードベースは、私のような古いプログラマーと新しいプログラマーであり、均一性のために行われた方法ですぐにそれを行うことを学びます。私たちはどこかから始めなければならないと考えて、私は自分自身にそれとしてデータホルダークラスをリファクタリングしました： セッターメソッドを削除し、すべてのフィールドを作成しましたfinal（final公理的には "良い"です）。結局のところ、セッターはコンストラクターでのみ使用されていたため、副作用はありませんでした。 Builderクラスを導入しました コンストラクター（そもそもリファクタリングを促したもの）が約3行のコードにわたるため、Builderクラスが必要でした。それは持っている多くのパラメータを。 運が良ければ、チームメイトが別のモジュールで作業していて、たまたまセッターが必要でした。なぜなら、必要な値がフローのさまざまなポイントで利用可能になったからです。したがって、コードは次のようになりました。 public void foo(Bar bar){ //do stuff bar.setA(stuff); //do more stuff bar.setB(moreStuff); } セッターを取り除くことでフィールドが不変のままになることを可能にするため（以前に不変性についての不満を聞いたことがあります）、またビルダーはオブジェクトの作成をトランザクション可能にするため、代わりにビルダーを使用する必要があると主張しました。次の擬似コードをスケッチしました。 public void foo(Bar bar){ try{ bar.setA(a); //enter exception-throwing stuff bar.setB(b); }catch(){} } その例外が発生すると、barデータが破損しますが、ビルダーでは回避できます。 public Bar foo(){ Builder builder=new Builder(); try{ builder.setA(a); //dangerous stuff; builder.setB(b); //more dangerous stuff builder.setC(c); return builder.build(); }catch(){} …

22 design-patterns  teamwork  builder-pattern 

一部の開発者にとって、疎結合は、適切に設計されたソフトウェアの聖杯です。予測可能な将来に発生する可能性のある変更に直面してコードをより柔軟にする、またはコードの重複を回避する場合、それは確かに良いことです。 一方、コンポーネントを疎結合しようとすると、プログラム内の間接参照の量が増え、そのため複雑さが増し、理解が難しくなり、効率が低下することがよくあります。 疎結合のユースケースを使用しない疎結合（コードの重複を回避したり、近い将来発生する可能性のある変更を計画するなど）をアンチパターンと考えていますか？ゆるい結合はYAGNIの傘の下に落ちますか？

22 design  design-patterns  object-oriented 

私は最近、C＃での関数型プログラミングというタイトルの本を読んでいます。関数型プログラミングの不変でステートレスな性質は、依存性注入パターンと同様の結果を達成し、特にユニットテストに関してはより良いアプローチである可能性があります。 両方のアプローチの経験がある人なら誰でも、主な質問に答えるために自分の考えや経験を共有できれば感謝しています。

21 design-patterns  unit-testing  functional-programming  dependency-injection