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

そのため、システム全体で次のコードを使用しています。現在、ユニットテストを過去にさかのぼって記述しています（私の議論ではなかったよりも遅くなっています）が、これがどのようにテスト可能かはわかりませんか？ public function validate($value, Constraint $constraint) { $searchEntity = EmailAlertToSearchAdapter::adapt($value); $queryBuilder = SearcherFactory::getSearchDirector($searchEntity->getKeywords()); $adapter = new SearchEntityToQueryAdapter($queryBuilder, $searchEntity); $query = $adapter->setupBuilder()->build(); $totalCount = $this->advertType->count($query); if ($totalCount >= self::MAXIMUM_MATCHING_ADS) { $this->context->addViolation( $constraint->message ); } } 概念的には、これはどの言語にも適用できるはずですが、私はPHPを使用しています。このコードは、オブジェクトに基づいてElasticSearchクエリオブジェクトを構築するだけで、Searchオブジェクトはオブジェクトから構築されEmailAlertます。これらSearchとEmailAlert'sは単なるPOPOです。 私の問題は、SearcherFactory（静的メソッドを使用する）をモックアウトする方法や、インスタンスSearchEntityToQueryAdapterからの結果を必要とするをモックアウトできないことです。メソッド内の結果から構築されたものを注入するにはどうすればよいですか？たぶん私が知らないいくつかのデザインパターンがありますか？SearcherFactory::getSearchDirector Search 助けてくれてありがとう！

13 design-patterns  php  unit-testing  testing 

私は、Microsoftテクノロジーをベースにした中小企業のデータベース開発者として新しい仕事を始めました。私は、ベストプラクティス、設計パターン、テスト、およびプロジェクト管理に関して、学校で教えられたものからどれだけのプラクティスが逸脱しているかに早く気づきました。 私を最も悩ませているのは、メインのデータベース開発者（以下、「ジョン」と呼びます）がデータベースにモデルスキーマを保持する方法です！これを行うには、3つの「マジック」テーブルを使用します。1つはデータベーススキーマ用、1つはテーブル用、もう1つは列用です。 レコードを「テーブル」テーブルに挿入すると、実際の対応するテーブルが（データベーストリガーを介して）生成されます。「Rows」テーブルに行を挿入すると、参照されているテーブルがその行で更新されます。これらは、彼の手作りのC＃プログラムによって順番に読み取られ、C＃モデルを生成します。これは、フロントエンド開発者がコントローラーおよび外部向けに使用します。 これとは別に、ほとんどの開発はASP.NET MVCフレームワークに従って行われます。 このアプローチにはいくつかの欠陥があります。 ORMを維持するために彼が必要であり、そうする時間はめったにありません（ジョブのセキュリティは良いです！） 「テーブル」および「行」テーブルのトリガーに欠陥があります。テーブルの更新も、チェック制約や「高度な」機能もサポートしていません。それらを確実に改善することはできましたが、これが道筋かどうかはまだわかりません。 データベース内のプログラムロジックを維持することは、奇妙で制限されているように感じます（ただし、C＃を使用してモデルを拡張することは可能です）。 彼のC＃モデルジェネレーターは、3人のうちの1人（私は1人）によって手動で実行する必要があり、まだ自動化されたビルドプロセスに含まれるほど成熟していません。 Entity Frameworkのような真のテスト済み製品への段階的導入を提案した人もいますが、彼はそれを却下し、ビジネスロジックをコード層に保持することは小規模なアプリケーションとスタートアップのブートストラッププロジェクトにのみ適していると主張しました。 この投稿は、意見を述べた議論のように見えるものに向かっていますが、それは私の意図ではありません。私たちのアーキテクチャのアプローチに関する明確化が必要です。 データベースにドメインモデルを保持することは、成長中の企業にとって持続可能なソリューションになりますか？

13 design-patterns  database  mvc 

例から始めましょう。 たとえば、exportDBスキーマに大きく依存するというメソッドがあります。また、「大きく依存する」ということは、特定のテーブルに新しい列を追加すると、頻繁に（非常に頻繁に）対応するexportメソッドが変更されることを知っています（通常、エクスポートデータにも新しいフィールドを追加する必要があります）。 プログラマーは、exportメソッドを変更することを忘れることがよくあります。これを確認する必要があるかどうかは明確ではないからです。私の目標は、プログラマーがメソッドを見るのを忘れたのか、エクスポートデータにフィールドを追加したくないだけなのかを明確に決定するようプログラマーに強制することexportです。そして、私はこの問題の設計ソリューションを探しています。 私には2つのアイデアがありますが、どちらにも欠点があります。 スマートな「すべてを読む」ラッパー すべてのデータが明示的に読み取られるようにするスマートラッパーを作成できます。 このようなもの： def export(): checker = AllReadChecker.new(table_row) name = checker.get('name') surname = checker.get('surname') checker.ignore('age') # explicitly ignore the "age" field result = [name, surname] # or whatever checker.check_now() # check all is read return result そのため、読み取られなかった別のフィールドが含まれてcheckerいるかどうかをアサートしtable_rowます。しかし、このことはすべて重そうに見え、（おそらく）パフォーマンスに影響します。 「その方法を確認する」unittest 最後のテーブルスキーマを記憶し、テーブルが変更されるたびに失敗するunittestを作成するだけです。その場合、プログラマーは「exportメソッドをチェックアウトするのを忘れないでください」のようなものを見るでしょう。警告プログラマーを非表示にするには、問題をチェックアウトしexport、手動で（別の問題です）新しいフィールドを追加してテストを修正します。 私には他にもいくつかのアイデアがありますが、それらは実装するのが面倒で、理解するのが難しすぎます（そして、プロジェクトをパズルにしたくないのです）。 上記の問題は、私が時々遭遇するより広範なクラスの問題の例です。いくつかのコードやインフラストラクチャをバインドしたいので、それらのいずれかを変更すると、すぐにプログラマに別のコードをチェックするよう警告します。通常、一般的なロジックの抽出や信頼性の高い単体テストの作成などの簡単なツールがありますが、より複雑なケースのツールを探しています。

13 design  design-patterns  architecture  unit-testing 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 コレクションに何かを追加する最も一般的な方法はAdd、コレクションが提供する何らかの方法を使用することだと思います。 class Item {} var items = new List<Item>(); items.Add(new Item()); そして、それについて実際に異常なことは何もありません。 しかし、なぜこのようにしないのでしょうか。 var item = new Item(); item.AddTo(items); 最初の方法よりも自然な方法のようです。これには、Itemクラスに次のようなプロパティがあるときにandvantange がありますParent。 class Item { public object Parent { get; private set; } } セッターをプライベートにすることができます。もちろんこの場合、拡張メソッドを使用することはできません。 しかし、おそらく私は間違っており、このパターンはあまり見られないので、これまで見たことがないでしょうか？そのようなパターンがあるかどうか知っていますか？ でC#拡張メソッドは、そのために有用であろう public static T AddTo(this T item, IList<T> list) { list.Add(item); return …

13 design-patterns  language-agnostic 

Google Guiceのような依存性注入フレームワークは、その使用（ソース）に次の動機を与えます。 オブジェクトを構築するには、まずその依存関係を構築します。しかし、各依存関係を構築するには、その依存関係などが必要です。したがって、オブジェクトを作成するときは、オブジェクトグラフを作成する必要があります。 手作業でオブジェクトグラフを作成するのは手間がかかり（...）、テストが困難になります。 しかし、私はこの議論を買いません。依存性注入フレームワークがなくても、インスタンス化が簡単で、テストが便利なクラスを作成できます。たとえば、Guiceの動機付けページの例を次のように書き換えることができます。 class BillingService { private final CreditCardProcessor processor; private final TransactionLog transactionLog; // constructor for tests, taking all collaborators as parameters BillingService(CreditCardProcessor processor, TransactionLog transactionLog) { this.processor = processor; this.transactionLog = transactionLog; } // constructor for production, calling the (productive) constructors of the collaborators public BillingService() …

13 design-patterns  object-oriented  dependency-injection  ioc-containers 

Webコンテンツ管理システムのコンテンツタイプを表すC＃クラスがあります。 Webコンテンツエディターがオブジェクトの表示方法のHTMLテンプレートを入力できるフィールドがあります。基本的に、オブジェクトプロパティ値をHTML文字列に代入するためにhandlebars構文を使用します。 <h1>{{Title}}</h1><p>{{Message}}</p> クラス設計の観点から、フォーマットされたHTML文字列（置換あり）をプロパティまたはメソッドとして公開する必要がありますか？ プロパティとしての例： public class Example { private string _template; public string Title { get; set; } public string Message { get; set; } public string Html { get { return this.ToHtml(); } protected set { } } public Example(Content content) { this.Title = content.GetValue("title") as string; this.Message …

13 c#  design-patterns  class-design  methods  properties 

次のようなS＃arpアーキテクチャを使用して実装されたCQRSパターンの一部があります。 public class MyCommand { public CustomerId { get; set; } // some other fields } public class MyCommandHandler<MyCommand> : ICommandHandler<MyCommand, CommandResult> { Handle(MyCommand command) { // some code for saving Customer entity return CommandResult.Success; } } なぜCommandデータと処理メソッドの両方を含むクラスを持たないのでしょうか？コマンド処理ロジックをコマンドプロパティとは別にテストする必要がある場合、一種のテスト容易性の利点ですか？または、さまざまな実装で1つのコマンドを処理する必要がある、頻繁なビジネス要件ICommandHandler<MyCommand, CommandResult>ですか？

13 c#  design-patterns  architecture  cqrs 

私はRails AntiPatternsという本を読んでいて、彼らはデメテルの法則を破らないために委任を使うことについて話しています。主な例は次のとおりです。 彼らは、コントローラでこのようなものを呼び出すことは悪いと信じています（そして私は同意します） @street = @invoice.customer.address.street 提案された解決策は、次のことを行うことです。 class Customer has_one :address belongs_to :invoice def street address.street end end class Invoice has_one :customer def customer_street customer.street end end @street = @invoice.customer_street ドットを1つしか使用しないため、ここでデメテルの法則に違反していないと述べています。あなたはまだ顧客を通り抜けて住所を通り、請求書の番地を取得しているので、これは間違っていると思います。私は主に私が読んだブログ投稿からこのアイデアを得ました： http://www.dan-manges.com/blog/37 ブログの投稿では、主な例は class Wallet attr_accessor :cash end class Customer has_one :wallet # attribute delegation def cash @wallet.cash end end …

13 design  design-patterns  object-oriented  ruby-on-rails 

私は、依存関係の逆転の原則を（ほとんどは後輩の）同僚に説明しようとしています。ソフトウェアの「高レベルポリシー」と「低レベル詳細」を定義するにはどうすればよいですか？たとえば、ソフトウェアが複数のビジネスアプリケーションのワークフローを自動化する場合、ワークフローの自動化が高レベルのポリシーであり、ビジネスアプリケーションが詳細であると言うのはなぜですか？

13 design-patterns  object-oriented  solid  design 

だから、私は少し前に書いた認証モジュールを持っています。今、私は自分のやり方のエラーを見、それのための単体テストを書いています。単体テストを書いている間、私は良い名前とテストする良い領域を思いつくのに苦労しています。例えば、私は次のようなものを持っています RequiresLogin_should_redirect_when_not_logged_in RequiresLogin_should_pass_through_when_logged_in Login_should_work_when_given_proper_credentials 個人的には、「適切」に見えても、少しthoughいと思います。また、テストをスキャンするだけでテストを区別するのに苦労しています（失敗したものを知るには、メソッド名を少なくとも2回読む必要があります） だから、機能を純粋にテストするテストを書く代わりに、シナリオをカバーするテストのセットを書くかもしれないと思った。 たとえば、これは私が思いついたテストスタブです： public class Authentication_Bill { public void Bill_has_no_account() { //assert username "bill" not in UserStore } public void Bill_attempts_to_post_comment_but_is_redirected_to_login() { //Calls RequiredLogin and should redirect to login page } public void Bill_creates_account() { //pretend the login page doubled as registration and he made an …

13 design-patterns  .net  testing  unit-testing  user-story 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 Clojureをしばらく使ってきましたが、重要なプロジェクトでは使用していません。基本的に、構文といくつかのイディオムに慣れてきました。OOPのバックグラウンドから来て、Clojureが私が非常によく見た最初の関数型言語であるため、私は当然、物事の関数型の方法にそれほど満足していません。 とはいえ、大規模な機能アプリケーションの作成に共通する特定のワークフローやデザインパターンはありますか 「実際に」関数型プログラミングの使用を開始したいのですが、現在の専門知識の不足により、大失敗に終わるのではないかと心配しています。 「4つのギャング」はOOプログラマーにとって非常に標準ですが、機能的なパラダイムにより向けられた類似のものはありますか？私が見つけたほとんどのリソースには、優れたプログラミングナゲットがありますが、一歩踏み込んで、より広範な、よりアーキテクチャ的な外観を与えることはできません。

13 design-patterns  functional-programming  application-design 

文書化されたデザインパターンを使用していなかったすべての古いアプリケーションを正常にスケーリングできます。どのようなパターンであれ、私は知りません。大部分は、単純なOOPコンセプトを使用する必要があると感じただけです。 デザインパターンの概念は複雑で理解しにくいものです。実装時に、実装が正しく、アプリケーションが実際の疎結合を持っているかどうかを判断する方法は？

13 design-patterns 

システムエラー、例外処理（Java、C ++、Perl、PHP）を公開/許容/回復するための設計パターン/アプローチを推奨できますか？ いくつかのエラーを報告する必要があります。 一部のエラーは、内部的に処理することができます（再試行によるか、重要ではありません（無視できます）。 それらをキャッチするコードをどのように構成しますか？ ただし、すべてのエラーを記録する必要があります。 どんなベストプラクティスがありますか？ そして、それらの影響を受けるコンポーネントを完全にテストできるようにそれらをシミュレートするには？ いくつかの現代のプログラミング言語に適用可能な一般的な非プログラミング言語固有の質問ですが、Java、C ++、PHP、およびPerlのパターン、アプローチ、哲学の例図を歓迎します。 （stackoverflowでも尋ねました：https ://stackoverflow.com/questions/7432596/recommend-a-design-pattern-approach-to-exposing-tolerating-recovering-from-systemです が、プログラマーにも尋ねるべきだと思いましたプログラマーのQ＆Aは、より広範なソフトウェア/プログラミングの問題をカバーしているのに対し、stackoverflowは技術的な実装に関するものです（IMHO）。

13 design-patterns  philosophy  error-handling  exception-handling 

私はASP.NET MVCアプリに取り組んでおり、便利で便利なゲッターをモデル/エンティティクラスに入れる習慣を身につけています。 例えば： public class Member { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public string PhoneNumber { get; set; } public string FullName { get { return FirstName + " " + LastName; } } …

13 c#  design-patterns  asp.net-mvc 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 だから、2つの質問を連続して尋ねるのは奇妙ですが、それらはあまり関連しておらず、私はそれらを結合したくありませんでしたが、私は質問をスパムしません、私は約束します！ とにかく、私は最近の大学卒業生であり、私の教育はデザインパターンにのみ触れました...私たちはいくつかの簡単なものを実装し、もっと複雑なものがあるという事実に触れ、GoF本に目を向けるように指示されましたもっと学びたかった。私の質問は、GoFの本のパターンを学ぶ価値があるかどうかです。私にとって、問題を古典的なパターンに当てはめようとすることは常に直感に反するように思えますが、明らかに本とパターンは理由があることで有名です。彼らは私がそれらを学ぶべきであるほど十分に現れますか？ 再度、感謝します！

13 learning  design-patterns