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

設計パターンは、ソフトウェア設計で一般的に発生する問題に対する一般的な再利用可能なソリューションです。


6
人間が読める最も単純な構成ファイル形式は何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 現在の構成ファイルは次のとおりです。 mainwindow.title = 'test' mainwindow.position.x = 100 mainwindow.position.y = 200 mainwindow.button.label = 'apply' mainwindow.button.size.x = 100 mainwindow.button.size.y = 30 logger.datarate = 100 logger.enable = True logger.filename = './test.log' これは、Pythonを使用してネストされた辞書に読み込まれます。 { 'mainwindow':{ 'button':{ 'label': {'value':'apply'}, ... }, 'logger':{ datarate: {'value': 100}, enable: {'value': True}, filename: {'value': './test.log'} }, …

6
次のコードスニペットからあまりにも多くのif / else-ifから脱出するより良い方法は何ですか?
入力として渡された「アクション」値に基づいてタスクを実行するサーブレットを作成しようとしています。 サンプルは次のとおりです public class SampleClass extends HttpServlet { public static void action1() throws Exception{ //Do some actions } public static void action2() throws Exception{ //Do some actions } //And goes on till action9 public void doPost(HttpServletRequest req, HttpServletResponse res)throws ServletException, IOException { String action = req.getParameter("action"); /** * I find …

6
DDDがOOPを満たしている:オブジェクト指向リポジトリを実装する方法は?
DDDリポジトリの典型的な実装は、save()メソッドなど、あまりオブジェクト指向ではありません。 package com.example.domain; public class Product { /* public attributes for brevity */ public String name; public Double price; } public interface ProductRepo { void save(Product product); } インフラストラクチャ部分: package com.example.infrastructure; // imports... public class JdbcProductRepo implements ProductRepo { private JdbcTemplate = ... public void save(Product product) { JdbcTemplate.update("INSERT INTO …

1
フレンドクラスを使用してプライベートメンバー関数をC ++でカプセル化する-良い習慣ですか?
だから私は、次のようなことをすることでヘッダーにプライベート関数を置くことを避けることが可能であることに気付きました: // In file pred_list.h: class PredicateList { int somePrivateField; friend class PredicateList_HelperFunctions; public: bool match(); } // In file pred_list.cpp: class PredicateList_HelperFunctions { static bool fullMatch(PredicateList& p) { return p.somePrivateField == 5; // or whatever } } bool PredicateList::match() { return PredicateList_HelperFunctions::fullMatch(*this); } プライベート関数はヘッダーで宣言されることはなく、ヘッダーをインポートするクラスのコンシューマーは、それが存在することを知る必要はありません。これは、ヘルパー関数がテンプレートの場合に必要です(代替方法はヘッダーに完全なコードを配置することです)。これが、私がこれを「発見」した方法です。プライベートメンバ関数を追加/削除/変更する場合、ヘッダーを含むすべてのファイルを再コンパイルする必要がないというもう1つの利点があります。すべてのプライベート関数は.cppファイルにあります。 そう... これは有名なデザインパターンですか? 私にとって(Java / C#のバックグラウンドから来て、自分の時間でC …

2
アプリの一部が異なる言語で記述されている場合、データ構造の重複を回避するにはどうすればよいですか?
例として、Javaでアプリを書いているとしましょう。 アプリは、Pythonで記述されたAPIサーバーと通信します。 PythonサーバーはSQLデータベースと通信します。 JavaScriptで記述されたアプリのWebサイトもあります。 4つの異なる言語を使用すると、本質的に同じデータ構造を4回異なるものにするのは簡単です。 たとえば、User型は次のようになります(擬似コード): type User { integer id; string name; timestamp birthday; } プロジェクトのすべての部分には何らかの表現が必要でしょうUser。JavaパーツとPythonパーツには、2つの異なるclass宣言が必要です。データベースにはUserテーブル宣言が必要です。そして、フロントエンドサイトUserも代表する必要があります。 このタイプを4回繰り返すことは、「繰り返しはしない」という原則に反します。また、Userタイプが変更された場合、プロジェクトのさまざまな部分でこれらの変更を繰り返す必要があるという問題があります。 Googleのprotobufライブラリは、特殊な構文を使用してデータ構造を記述し、ライブラリが複数の異なるプログラミング言語で構造宣言を生成するというこの問題に対する一種のソリューションを提供することを知っています。しかし、これでも型の検証ロジックを繰り返さなければならないという問題には対応していません。 これに関する本やブログの投稿への提案やリンクはありますか?

4
クラスは、実装するメソッドのサブセットをユーザーにどのように伝える必要がありますか?
シナリオ WebアプリケーションはIUserBackend、メソッドを使用してユーザーバックエンドインターフェイスを定義します getUser(uid) createUser(uid) deleteUser(uid) setPassword(uid、password) ... 異なるユーザーバックエンド(LDAP、SQLなど)がこのインターフェイスを実装しますが、すべてのバックエンドがすべてを実行できるわけではありません。たとえば、具体的なLDAPサーバーでは、このWebアプリケーションはユーザーを削除できません。したがって、LdapUserBackend実装IUserBackendするクラスはを実装しませんdeleteUser(uid)。 具体的なクラスは、Webアプリケーションがバックエンドのユーザーに対して許可されていることをWebアプリケーションと通信する必要があります。 既知の解決策 私は、要求されたアクションとビット単位でANDされたアクションのビット単位のORの結果である整数を返すメソッドをIUserInterface持っているソリューションを見ましたimplementedActions: function implementedActions(requestedActions) { return (bool)( ACTION_GET_USER | ACTION_CREATE_USER | ACTION_DELTE_USER | ACTION_SET_PASSWORD ) & requestedActions) } どこ ACTION_GET_USER = 1 ACTION_CREATE_USER = 2 ACTION_DELETE_USER = 4 ACTION_SET_PASSWORD = 8 .... = 16 .... = 32 等 そのため、Webアプリケーションは、必要なものでビットマスクを設定し、implementedActions()それらをサポートするかどうかをブール値で答えます。 意見 私にとってこれらのビット操作はC時代の遺物のように見えますが、きれいなコードの観点からは必ずしも簡単に理解できるとは限りません。 …

1
文法に基づいてレクサーを作成するときに従う手順は何ですか?
文法、レクサー、パーサーに関する質問Clarificationに対する回答を読んでいると、答えは次のように述べています。 [...] BNF文法には、字句解析と構文解析に必要なすべてのルールが含まれています。 パーサーは文法に基づいているのに対し、これまでは常に字句解析は文法に基づいていないと考えていたため、これはやや奇妙に思えました。レクサーの作成に関する多数のブログ投稿を読んだ後、この結論に至りました。デザインの基礎として1つのEBNF / BNF を使用したことはありません。 パーサーと同様にレクサーがEBNF / BNF文法に基づいている場合、そのメソッドを使用してレクサーを作成するにはどうすればよいでしょうか?つまり、特定のEBNF / BNF文法を使用してレクサーを構築するにはどうすればよいですか? EBNF / BNFをガイドまたは設計図として使用してパーサーを記述することを扱った多くの投稿を見てきましたが、レクサーデザインと同等のことを示すものは今のところ見つかりませんでした。 たとえば、次の文法を取ります。 input = digit| string ; digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ; string = '"', { all characters - …

5
円に最も近い最適なものを見つける
以下は、真ん中に白い点のポイントがあり、すべての赤い円がすでに存在する場合に青い円(明らかにそれを配置した場所にある)に最も近い場所を見つけたい場合の画像例です。 。その場所を見つけるにはどうすればよいですか? 私にとってパフォーマンスは、このアプリケーションにとって大きな関心事ではありません。

8
顧客ごとに異なる可能性のある1つのメソッドを持つクラスの適切な設計
顧客の支払いの処理に使用するクラスがあります。このクラスの1つを除くすべてのメソッドは、すべての顧客で同じです。ただし、顧客のユーザーが負う金額を(たとえば)計算するものを除きます。これは顧客ごとに大きく異なる可能性があり、カスタムファクタはいくつも存在する可能性があるため、計算のロジックをプロパティファイルのようなものにキャプチャする簡単な方法はありません。 customerIDに基づいて切り替えるいコードを書くことができます。 switch(customerID) { case 101: .. do calculations for customer 101 case 102: .. do calculations for customer 102 case 103: .. do calculations for customer 103 etc } ただし、新しい顧客を獲得するたびにクラスを再構築する必要があります。より良い方法は何ですか? [編集]「複製」の記事はまったく異なります。私はswitchステートメントを回避する方法を求めているのではなく、このケースに最も適したモダンなデザインを求めています-恐竜のコードを書きたい場合はswitchステートメントで解決できます。そこで提供されている例は一般的なものであり、本質的には「スイッチはある場合には非常にうまく機能し、他の場合には機能しない」と言っているため、役に立たない。 [編集]次の理由から、トップランクの回答(標準インターフェイスを実装する顧客ごとに個別の「顧客」クラスを作成する)を採用することにしました。 一貫性:他の開発者によって作成された場合でも、すべてのCustomerクラスが同じ出力を受け取って返すことを保証するインターフェイスを作成できます。 保守性:すべてのコードは同じ言語(Java)で記述されているため、デッドシンプルな機能を維持するために他の誰かが別のコーディング言語を学ぶ必要はありません。 再利用:コードで同様の問題が発生した場合、Customerクラスを再利用して、任意の数のメソッドを保持して「カスタム」ロジックを実装できます。 親しみやすさ:私はすでにこれを行う方法を知っているので、すぐにそれを完了させ、他のより差し迫った問題に進むことができます。 欠点: 新しい顧客ごとに、新しいCustomerクラスのコンパイルが必要です。これにより、変更をコンパイルおよびデプロイする方法が複雑になる場合があります。 新しい顧客はそれぞれ、開発者が追加する必要があります。サポート担当者は、プロパティファイルのようなものにロジックを追加することはできません。これは理想的ではありません...しかし、サポート担当者が必要なビジネスロジックをどのように書き出すことができるのか、特に多くの例外を伴う複雑な場合(そうである可能性が高い場合)もわかりませんでした。 多くの新しい顧客を追加した場合、うまく拡張できません。これは予期されていませんが、もしそうなった場合、コードの他の多くの部分とこの部分を再考する必要があります。 興味のある方は、Java Reflectionを使用して名前でクラスを呼び出すことができます。 Payment payment = getPaymentFromSomewhere(); try { String …


3
フラックスパターンを理解する
私は実際にフラックスのパターンを研究していますが、ストアに関して理解できないことがあります。 彼らは正確に何ですか? 私は多くの記事を読みましたが、それはドメインに関係しているようです。 これは、API呼び出しまたはバックエンド呼び出しに関連する「抽象的な」部分であることを意味しますか? 私にはあまりはっきりしていません。 編集:それは角度の工場と同じものでしたか?リモートデータの取得、ビジネスタスクの作成、アプリの状態の保存(現在のユーザーの接続など)

2
「zip」がコレクションのぶら下がり尾を無視するのはなぜですか?
C#、Scala、Haskell、Lisp、およびPythonのzip動作は同じです。1つのコレクションがより長い場合、テールは黙って無視されます。 例外もスローされる可能性がありますが、このアプローチを使用している言語は聞いていません。 これは私を困惑させます。誰かがzipそのように設計されている理由を知っていますか?新しい言語の場合は、他の言語がこの方法で行うため、完了します。しかし、根本的な理由は何でしたか? ここで、事実に基づいた、歴史に基づいた質問をしている。誰かがそれを好むのか、それとも良いアプローチか悪いアプローチなのかではない。 更新:どうすればよいかと聞かれたら、例外をスローします。配列をインデックス化するのとほとんど同じです(「古い」言語はあらゆる種類のマジックを行いましたが、境界外のインデックス、UB、配列を展開する方法、等)。

2
ロガーの障害をどのように処理すればよいですか?
当社のアプリケーションのいくつかでは、カスタムロガーを使用しています。かなり堅牢ですが、将来NLogのようなものに置き換える可能性があります。ロガーのタスクの1つは、アプリケーションで発生した例外をログに記録することです。 私が常に抱えていた懸念の1つは、ロガー内の例外処理がサイレント障害を許容することです。つまり、ログが特定の例外(ロガーのエラーのため)に書き込まれていない場合、どのようにログを処理し、(どういうわけか)ロガー自体に例外を記録する必要がありますか? WriteLog関数が例外をスローするとします。関数を何回か、または例外がスローされなくなるまで呼び出そうとしますか?スローされた例外をロガーで書き込もうとする必要があります(これにより、例外が発生する可能性が高くなります。最初にカスタムロガーを実装していたときを除いて、この状況に出会えないほど幸運でした。一方で、ロガーがアプリケーションの例外(独自の例外のため)のログに失敗したかどうかを現時点で知る方法はありません。 私はオンラインといくつかのSEサイトで検索しようとしましたが、すべての投稿がロガーのエラー(潜在的な例外とそれらのログ方法ではありません)またはロガー外の例外を扱っているため、これまでのところ無駄です。

3
コードでExcel(xlsx)ファイルを生成するための良いデザインパターンは何ですか?
詳細については、下部の更新を参照してください。 Excelファイル(xlsx形式)としてデータを出力する必要があるプロジェクトがときどきあります。通常、プロセスは次のとおりです。 ユーザーが私のアプリケーションのいくつかのボタンをクリックする 私のコードはDBクエリを実行し、結果を何らかの方法で処理します 私のコードは、Excel com相互運用ライブラリまたはサードパーティライブラリ(Aspose.Cellsなど)を使用して* .xlsxファイルを生成します これをオンラインで行う方法のコード例を簡単に見つけることができますが、より堅牢な方法を探しています。私のコードがいくつかの設計原則に従って、私のコードが維持可能で簡単に理解できるようにしたいと思います。 xlsxファイルを生成する最初の試みは次のとおりです。 var wb = new Workbook(); var ws = wb.Worksheets[0]; ws.Cells[0, 0].Value = "Header"; ws.Cells[1, 0].Value = "Row 1"; ws.Cells[2, 0].Value = "Row 2"; ws.Cells[3, 0].Value = "Row 3"; wb.Save(path); 長所:それほど多くはありません。動作するので、それは良いことです。 短所: セル参照はハードコーディングされているため、コード全体にマジックナンバーが散らばっています。 多くのセル参照を更新せずに列と行を追加または削除することは困難です。 サードパーティのライブラリを学ぶ必要があります。一部のライブラリは他のライブラリと同様に使用されますが、それでも問題が発生する可能性があります。com interopライブラリが1ベースのセル参照を使用し、Aspose.Cellsが0ベースのセル参照を使用するという問題がありました。 上に挙げたいくつかの短所に対処する1つのソリューションを次に示します。データのテーブルを、セルの操作や他のセル参照を妨害することなく移動したり変更したりできる独自のオブジェクトとして扱いたいと思いました。擬似コードは次のとおりです。 var headers = new Block(new …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.