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

OOPの原則を実践する方法として、C ++で中規模のOOPアプリケーションを作成しています。 私のプロジェクトにはいくつかのクラスがあり、それらのいくつかはランタイム構成パラメーターにアクセスする必要があります。これらのパラメーターは、アプリケーションの起動時にいくつかのソースから読み取られます。ユーザーのhome-dirにある設定ファイルから読み込まれるものもあれば、コマンドライン引数（argv）であるものもあります。 そこで、クラスを作成しましたConfigBlock。このクラスは、すべてのパラメーターソースを読み取り、適切なデータ構造に格納します。例としては、構成ファイルまたは--verbose CLIフラグでユーザーが変更できるパスとファイル名があります。次に、ConfigBlock.GetVerboseLevel()この特定のパラメーターを読み取るために呼び出すことができます。 私の質問：このようなすべてのランタイム構成データを1つのクラスに収集することをお勧めしますか？ 次に、クラスはこれらすべてのパラメーターにアクセスする必要があります。私はこれを達成するためのいくつかの方法を考えることができますが、どの方法を取るべきかはわかりません。クラスのコンストラクターは、次のようにConfigBlockへの参照を指定できます。 public: MyGreatClass(ConfigBlock &config); または、CodingBlockの定義を含むヘッダー「CodingBlock.h」を含めるだけです。 extern CodingBlock MyCodingBlock; その後、クラスの.cppファイルのみがConfigBlockのものを含めて使用する必要があります。 .hファイルは、このインターフェイスをクラスのユーザーに導入しません。ただし、ConfigBlockへのインターフェイスはまだありますが、.hファイルからは隠されています。 このように隠すのは良いですか？ インターフェイスをできるだけ小さくしたいのですが、最終的には、構成パラメーターを必要とするすべてのクラスがConfigBlockに接続する必要があると思います。しかし、この接続はどのように見えますか？

15 design-patterns  object-oriented  c++ 

私の上司は、特定のロジックを持つプロジェクトをくれました。ナビゲーターが製品に到着するまで多くの場合をナビゲートする必要があるWebページを開発する必要があります。 これは、サイト内のナビゲーションのパススキームです。 重要！ 製品ページで、ナビゲーターは必要なフィルターを選択できます。 Aの場合、彼/彼女はB（そしてもちろんC）またはCを通過して製品に到達しなければなりません。 Bの場合、彼/彼女はCを通過して製品に到達しなければなりません。 Cの場合、彼/彼女は直接製品に到達します。 もちろん、AIから開始する場合、最長パスをたどり、製品に到達すると3つのアクティブなフィルターがあります。 これまで、私は次のコードを開発しましたが、これは正常に機能します。 if filter_A if filter_B filter_C() .. else .. else filter_C .. else .. else if filter_B filter_C() .. else .. else filter_C() .. else .. この状況で、より専門的なプログラマが何をしたかを尋ねるためにここにいます。私はDRYの原則を尊重しませんでした。私はそれが気に入らず、この種のロジックを開発する別の方法を知りたいです。 関数のコードのすべてのセクションを分割することを考えましたが、この場合は良いアイデアですか？

15 design  design-patterns  language-agnostic  conditions  if-statement 

私は、プロジェクト用のシンプルなウィジェットを次の方法で開発することにかなりの時間を費やしました。 var project = project || {}; (function() { project.elements = { prop1: val1, prop2: val2 } project.method1 = function(val) { // Do this } project.method2 = function(val) { // Do that } project.init = function() { project.method1(project.elements.prop1) project.method2(project.elements.prop2) } })() project.init(); しかし、フォーマットを次のように変更し始めました。 function Project() { this.elements = { prop1: …

15 design-patterns  javascript  prototyping 

戦略デザインパターン、多くの場合、それらが不足している言語のファーストクラスの機能の代替としてみなされています。 たとえば、機能をオブジェクトに渡したいとします。Javaでは、目的の動作をカプセル化する別のオブジェクトをオブジェクトに渡す必要があります。Rubyなどの言語では、機能自体を匿名関数の形式で渡すだけです。 しかし、私はそれについて考えていたので、多分Strategyは単なる匿名関数が提供する以上のものを提供すると決めました。 これは、オブジェクトがメソッドの実行期間とは無関係に存在する状態を保持できるためです。ただし、匿名関数自体は、関数の実行が終了した時点で存在しなくなる状態のみを保持できます。 ファーストクラスの関数をサポートするオブジェクト指向言語では、関数を使用するよりも戦略パターンに利点がありますか？

15 design-patterns  object-oriented  functions 

このトピックに関するドキュメントと他のいくつかの質問のスレッドを読みましたが、私は本当に納得しません。この技術の使用の限界がはっきりとはわかりません。 フラグメントは現在、ベストプラクティスと見なされています。すべてのアクティビティは基本的に1つ以上のフラグメントのサポートであり、レイアウトを直接呼び出すことはありません。 フラグメントは次の目的で作成されます。 Activity多くのフラグメントの使用、それらの間の変更、これらのユニットの再利用を許可します... ==>はアクティビティにFragment完全に依存しているContextため、多くのアクティビティで再利用および処理できるジェネリックが必要な場合は、独自のカスタムレイアウトまたはビューを作成します...フラグメントが追加するこの追加の複雑さ開発レイヤーについては気にしません。 異なる解像度へのより良い処理==>長時間のプロセスの場合、タブレットの同じアクティビティで2つ（またはそれ以上）のフラグメントを表示し、電話で1つずつ表示できるタブレット/電話の場合はOKです。しかし、なぜフラグメントを常に使用するのでしょうか？ フラグメント間を移動するためのコールバックの処理（つまり、ユーザーがログインしている場合はフラグメントを表示し、そうでない場合は別のフラグメントを表示します）。===>フェイスブックSDKログインがこのために持っているバグの数を見てみて、それが本当に（？）であることを理解してください... Androidアプリケーションはアクティビティに基づいていることを考慮すると...仕方。===>これは、フラグメントSDKを使用してAndroid SDKとAndroid Frameworkを見ることに慣れている人の答えです。間違っているとは思いませんが、良い結果が得られるかどうかわかりません...そしてそれは本当に抽象的です... ====>常に使用することで、コーディングが増えて生活が複雑になるのはなぜですか？それ以外の場合、それがいくつかの場合の単なるツールである場合、なぜそれがベストプラクティスであるのですか？これらのケースは何ですか？

15 design-patterns  performance  android  fragmentation 

顧客が、CMSのeショップで製品に新しいプロパティ（色など）を追加する可能性を望んでいると想像してください。 プロパティをフィールドとして持つ代わりに： class Car extends Product { protected String type; protected int seats; } あなたはおそらく次のようなことをすることになります： class Product { protected String productName; protected Map<String, Property> properties; } class Property { protected String name; protected String value; } つまり、既存の型システムの上に独自の型システムを作成します。これは、ドメイン固有の言語を作成しているように見えるかもしれない、またはできないように思えます。 このアプローチは既知の設計パターンですか？問題を別の方法で解決しますか？ランタイムにフィールドを追加できる言語がありますが、データベースはどうですか？上記のように列を追加/変更するか、何かを使用しますか？ お時間をいただきありがとうございます:)。

15 design-patterns  object-oriented 

多くの場合、複数の場所で使用されているメソッドからブール値を返すことで、そのメソッドに関するすべてのロジックを1か所に収めています。（内部）呼び出しメソッドが知る必要があるのは、操作が成功したかどうかだけです。 私はPythonを使用していますが、質問は必ずしもその言語に固有のものではありません。考えられる選択肢は2つだけです 例外は発生しますが、状況は例外ではありません。関数が呼び出されるすべての場所でその例外をキャッチすることを忘れないでください 私がやっているようにブール値を返します。 これは、私が話していることを示す本当に簡単な例です。 import os class DoSomething(object): def remove_file(self, filename): try: os.remove(filename) except OSError: return False return True def process_file(self, filename): do_something() if remove_file(filename): do_something_else() 機能的ではありますが、私はこのようなやり方を本当に嫌いです。「臭い」がし、場合によっては入れ子にされたifが大量に発生することがあります。しかし、もっと簡単な方法は考えられません。 os.path.exists(filename)削除を試みる前に、よりLBYLの哲学に目を向けて使用することもできますが、その間にファイルがロックされないという保証はありません（可能性は低いですが可能です）し、削除が成功したかどうかを判断する必要があります。 これは「受け入れられる」設計ですか。そうでない場合、これを設計するより良い方法は何でしょうか？

15 design-patterns  python  boolean 

問題 ファイルからデータを読み取るためのメソッドDataSourceを提供するクラスReadData（および他のクラスもありますが、物事をシンプルにしましょう）があるとし.mdbます。 var source = new DataSource("myFile.mdb"); var data = source.ReadData(); 数年後、データソースとして.xmlファイルに加えて.mdbファイルもサポートできるようにしたいと決めました。「データの読み取り」の実装は.xml、.mdbファイルとファイルでまったく異なります。したがって、システムをゼロから設計する場合、次のように定義します。 abstract class DataSource { abstract Data ReadData(); static DataSource OpenDataSource(string fileName) { // return MdbDataSource or XmlDataSource, as appropriate } } class MdbDataSource : DataSource { override Data ReadData() { /* implementation 1 */ } } class XmlDataSource …

15 c#  design-patterns  refactoring  factory-method 

メソッドから2つの値を返す必要があります。私のアプローチは次のとおりです。 これらの2つの値を保持するために使用される2つのフィールドを持つ内部クラスを作成します そのクラス内にメソッドを配置します クラスをインスタンス化し、メソッドを呼び出します。 メソッドで変更される唯一のことは、最終的にインスタンスのフィールドにこれらの2つの値を割り当てることです。次に、そのオブジェクトのフィールドを参照することで、これらの値に対処できます。 それは良いデザインですか？それはなぜですか？

15 java  design-patterns 

MVC以外にWebのデザインパターンはありますか？ 次のようなデザインパターンがあることを知っています：Registry、Observer、Factory、ActiveRecord、...、MVCその他のデザインパターンとフォルダー構造のセット。 MVCは他のデザインパターンのセットであるようなデザインパターンはありますか？ 編集：私のプログラミング言語はPHPです。

15 web-development  php  design-patterns  mvc 

MVCを中心としたプロジェクトのアーキテクチャを設計しているときに質問があります。（これはC ++ / Marmalade SDKプロジェクトです。特定のMVCフレームワークは使用していません。作成しています。） いくつかの記事（元のSteve Burbek記事など）で、「MVCトライアド」という概念を読み続けています。初めて読んだとき、アプリケーションは「MVCトライアド」ユニット（想定している各UIピースに1つ）を中心に構築されているように見えましたが、これはかなり柔軟性に欠け、MVCの使用が意図されていなかったと思います。次に、この問題をさらに調査すると、コントローラーとビューの密結合の例、つまり1対1の関係が見つかりました-TextEditViewにはTextEditControllerがあります。 しかし、プロジェクトに戻ると、（AddElementControllerのような「論理ユニット」による）1つのコントローラーと、その特定のコントローラーの複数のビューがあると便利です。 私は、何らかのタブUIが必要なAddElementControllerのようなものについて明確に考えています。AddElementTabViewとタブ用の複数のAddImageView、AddSoundViewなどを持つAddElementControllerが必要ですか？または、タブビューごとに異なる「サブコントローラー」が必要ですか？ 要約すると、MVCパターン（このフレームワークのXフレームワーク固有の理解/実装ではありません）に関して、コントローラーに複数のビューがあるのは正しいですか、または各ビューに特定のコントローラーが必要ですか？ また、いくつかの状態情報をコントローラーに保持するのは正しいですか、それともステートレスである必要があります（つまり、状態を非ドメイン状態モデルに配置する必要があるということですか）。 事前にすべてに感謝します。

15 design  design-patterns  architecture  mvc 

ASP.NET MVC 2を使用して、コントローラー/ビュープレゼンテーションレイヤーと、ビジネスロジックレイヤー、データアクセスレイヤー[ストアドプロシージャおよびストアードプロシージャと通信するクラス/メソッド]で構成されるモデルを使用しています。 ビジネスレイヤー以上では、ほとんどの目的で、Editはオブジェクトの作成とオブジェクトの編集の両方を表すことができるようです。これは、「保存」メソッドを定義するリポジトリ設計パターンとよく一致します。IDが0の場合はストアドプロシージャをチェックインし、0の場合は新しいオブジェクトを作成します。それ以外の場合は、カテゴリIDが1に一致するため、既存のオブジェクトを更新できます。 議論の第一のポイントは、作成を含む編集をDALレイヤーを超えて作成と編集の別々の部分に分割することが最も理にかなっている場合です。 明らかな例をルートとして示すことができます： 作成 - のhttpを：// someurl / somearea /編集/ 0 編集 - のhttp：// someurl / somearea /編集/ 254 対 作成 - のhttp：// someurl / somearea /作成 編集 - のhttp：// someurl / somearea /編集/ 254 これに関して確立された標準やベストプラクティスはありますか？ 私はこれが小さな詳細であることを知っていますが、ロジスティック的に重要だと思います。

15 design  design-patterns  asp.net-mvc 

ここで私が意味しているのは、テンプレートからT add(T a, T b) ...生成されたコードにどのように行くかということです。これを実現するいくつかの方法を考えました。汎用関数をAST Function_Nodeに格納し、それを使用するたびに、元の関数ノードに、すべてのT型が使用されています。例えばadd<int>(5, 6)のための一般的な機能のコピーを保存するaddと、すべてのタイプに置き換えてT コピーで持ちますint。 したがって、次のようになります。 struct Function_Node { std::string name; // etc. Type return_type; std::vector<std::pair<Type, std::string>> arguments; std::vector<Function_Node> copies; }; 次に、これらのコードを生成しFunction_Node、コピーの場所リストにアクセスすると、すべてのコピーcopies.size() > 0で呼び出しますvisitFunction。 visitFunction(Function_Node& node) { if (node.copies.size() > 0) { for (auto& node : nodes.copies) { visitFunction(node); } // it's a generic function so …

15 design-patterns  programming-languages  compiler 

リポジトリパターンの多くを聞いたことがありますが、リポジトリが実際に何をすべきかを理解していませんでした。「リポジトリが実際にすべきこと」と言うとき、私は主にどのメソッドを提供すべきかを心配しています。たとえば、リポジトリは本当にCRUDメソッドを提供する必要がありますか、それとも何らかの種類のメソッドを提供する必要がありますか？ つまり、リポジトリにビジネスロジックを含めるべきですか、それとも単にデータストアと通信し、保存またはロードするエンティティを管理するためのロジックを含めるべきですか？ また、リポジトリは集約の永続性の単位であると聞いています。しかし、それはどうですか？これが実際にどのように機能するのか理解できません。IRepositoryCRUDメソッドを含むインターフェイスを1つだけ持つ必要があると考えました。その後、エンティティには、そのような型をデータストアから保存および取得するためのロジックが含まれます。

15 design-patterns  object-oriented-design  repository 

最近、エンティティ層に単純な計算を配置するのか、それとも生データを保存して計算ロジックをビジネス層に残すだけのエンティティにするのかという質問に直面しました。 私の質問は、エンティティクラスのプロパティに単純な計算をカプセル化することが賢明かどうかです。

15 design-patterns