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

この質問では、Decoratorパターンを使用して、大きなクラスのオブジェクトにほとんど機能を追加しないようにしています。 古典的なDecoratorパターンに従って、次のクラス構造を検討してください： たとえば、これがゲーム内で発生するとします。のインスタンスは、「ラッピング」しているConcreteCharacterDecorator機能に小さな機能を追加するためConcreteCharacterのものです。 たとえば、キャラクターが敵に与えるダメージを表す値をmethodA()返しますint。ConcreteCharacterDecorator単純にこの値に追加されます。したがって、必要なのはコードをに追加することだけmethodA()です。の機能はmethodB()変わりません。 ConcreteCharacterDecorator このようになります： class ConcreteCharacterDecorator extends AbstractCharacterDecorator{ ConcreteCharacter character; public ConcreteCharacterDecorator(ConcreteCharacter character){ this.character = character; } public int methodA(){ return 10 + character.methodA(); } public int methodB(){ character.methodB(); // simply delegate to the wrapped object. } } これは、2つのメソッドを含む小さなクラスでは問題ありません。 しかし、AbstractCharacter15のメソッドを定義するとどうなるでしょうか。 ConcreteCharacterDecorator少しの機能を追加することだけを目的としていますが、すべてを実装する必要があります。 少し機能を追加する1つのメソッドと、単純に内部オブジェクトに委譲する別の14のメソッドを含むクラスになります。 次のようになります。 class ConcreteCharacterDecorator extends AbstractCharacterDecorator{ ConcreteCharacter …

8 design-patterns  clean-code  composition 

ユーザーインターフェイスベースのJavaプログラムで作業する場合、動作を特定のアクション（ボタンのクリックなど）に関連付ける1つの方法は、匿名クラスを使用することです。以下の例では、GUIフレームワークはSWTですが、SwingまたはAndroid UIコンポーネントでも同じ問題があります。つまり、私のプログラムの構造化です。 MenuItem sampleMenuItem = new MenuItem(popupMenu, SWT.NONE); sampleMenuItem.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent event) { doSomething(); // handle all table entries for (int i=0; i<10; i++) { doSomething2(); } doSomething3(); doSomething4(); } }); もちろん、上のサンプルのコードの量はすでにロジックを含む専用クラスの作成を保証していると主張する人もいます。これは、Sonarの「匿名クラスは行が多すぎてはならない」という規則によっても示唆されています。 興味深いことに、このルールは次のことも指定しています。 squid：S1188-Javaでのクロージャーのサポートを待つ間、匿名クラスは、専用クラスを作成せずに動作を注入する最も便利な方法です。ただし、これらの匿名内部クラスは、動作が数行で実行できる場合にのみ使用してください。より複雑なコードでは、名前付きクラスが必要です。 ただし、Javaにはまだクロージャーが到着していないため、私の質問は次のようなエレガントな解決策があるかどうかです。 あらゆる種類の欠点（再利用が制限されている、コード内の移動が遅い、など）がある匿名クラス内で一連のコードを書く 膨大な数の専用クラスを作成し、それ自体が非常に限られた機能しか持たない可能性があります（つまり、オーバーエンジニアリングなど）。 私の質問を拡張します。JavaベースのUIアプリケーションのこの側面に関するベストプラクティスは何ですか？確立されたパターンはありますか？

8 java  design-patterns  ui 

私はまだここでデザインパターンを理解しようとしています。抽象ファクトリパターンを学習した後、このパターンはうまくスケーリングしないことに気付きました。抽象ファクトリー・パターンのUMLダイアグラムを見てください。 新しい「AbstractProductC」を作成する必要がある場合は、ConcreateFactory1とConcreateFactory2の両方の実装に影響を与える「AbstractFactory」に抽象メソッド「CreateProductC」を追加する必要があります。 ここでの私の質問は、Abstract Factoryパターンはまったくスケールしますか（または）私はここで間違った方向に考えていますか？ 前もって感謝します

8 design  design-patterns 

データソースの上にビジネスロジックを追加するWebサービスがあるとします。このサービスの各APIはほとんどのように見えます-一連の制約が与えられた場合、これらの制約を満たすデータソースからのアイテムを提供します。APIからデータソースの「ビュー」を取得したと言えます。 ここで、時間の経過とともに、データソースに対してさまざまな種類のビューを返すように求められます。「十分に異なる」ビューごとに新しいAPIを追加するか、ギアを切り替えて、目的のビューの種類を指定するパラメーターを取得するgetFooDataView（）APIを提供するオプションがあります。どちらの方法に行くかを決定するために、いくつかの競争圧力があります。 あなたのサービスの既存の大きなクライアントは怠惰であることを好み、データの新しいビューが必要なときに新しいAPIまでコーディングする必要はありません。 ただし、一部のリクエストパラメータ（制約）は一部のビューでのみ意味があり、他のビューでは意味がありません。「XYZビューが必要な場合は、 "foo"パラメータを設定すると、APIコントラクトを緩くする必要があります。一部のビューではそうであるとしても、 "foo"を必須パラメーターにすることができないという残念な副作用があります。 新しいクライアントがサービスを活用したいというケースはますます増えています。どちらがより混乱するかを決定することはできません-異なるがより厳密に定義されたAPIと、パラメーターのどの組み合わせが本当に必要なものを提供するかを知る必要がある1つのAPIを選択する必要があります。 これを抽出するために、既存のAPIのバリエーションとは対照的に、何かが独自のAPIである必要があるという線を描くのはいつですか？2人のクライアントの要求を意味的に区別する理由については、協力しなければならない人によって見方が異なるため、この問題についてコンセンサスを得るのは難しい場合があります。また、将来のクライアントがサービスを利用するのが極端に難しくならないようにする必要もあります。この種の選択を行うためのいくつかのベストプラクティスは何ですか？

8 design  design-patterns  web-services  api-design  usability 

構文解析ツリー、抽象構文ツリー、および制御フローグラフがあり、それぞれが前のものから論理的に派生しているとします。原則として、解析ツリーがあれば各グラフを作成するのは簡単ですが、解析ツリーが変更されたときにグラフを更新する複雑さをどのように管理できますか？私たちはツリーがどのように変更されたかを正確に知っていますが、管理が難しくならない方法で変更を他のツリーにどのように伝播できますか？ 当然ながら、依存グラフは最初のグラフが変更されるたびに最初から再構築するだけで更新できますが、依存グラフの変更の詳細を知る方法はありません。 現在、この問題を解決する方法は4つありますが、それぞれに問題があります。 従属ツリーのノードはそれぞれ、元のツリーの関連ノードを監視し、必要に応じて自身と元のツリーノードのオブザーバーリストを更新します。これの概念的な複雑さは困難になる可能性があります。 元のツリーの各ノードには、それに依存する従属ツリーノードのリストがあり、ノードが変更されると、従属ノードにフラグを設定して、従属ノードの親を含め、ダーティとしてマークします。ルートに。変更のたびに、依存グラフを最初から作成するアルゴリズムとよく似たアルゴリズムを実行しますが、クリーンノードをスキップして各ダーティノードを再構築し、再構築されたノードが実際にダーティノードと異なるかどうかを追跡します。これも注意が必要です。 元のグラフと従属グラフの間の論理的な接続を、おそらく宣言型言語を使用して設計された制約のリストのようなデータ構造として表すことができます。元のグラフが変更された場合、違反している制約と違反を修正するために依存ツリーをどのように変更する必要があるかを見つけるためにリストをスキャンするだけで、すべてデータとしてエンコードされます。 既存の依存グラフがないかのように、依存グラフを最初から再構築し、既存のグラフと新しいグラフを比較して、どのように変化したかを確認できます。違いを検出するために利用できるアルゴリズムがあることを知っているので、これが最も簡単な方法であると確信していますが、それらはすべて非常に計算コストが高く、原則として不要と思われるため、このオプションは意図的に避けています。 この種の問題に対処する正しい方法は何ですか？確かに、このすべてをほぼ簡単にするデザインパターンがなければなりません。この一般的な説明のすべての問題に対して適切な解決策があると便利です。このクラスの問題には名前がありますか？ この問題が引き起こすトラブルについて詳しく説明しましょう。この問題は、プロジェクトの2つの部分がグラフを操作するたびにさまざまな場所で発生します。各グラフは、ソフトウェアの実行中に変化する同じものの異なる表現です。これはインターフェースのアダプターを作成するようなものですが、単一のオブジェクトまたは固定数のオブジェクトをラップする代わりに、任意のサイズのグラフ全体をラップする必要があります。 私がこれを試す度に、私は混乱して維持不可能な混乱に終わります。オブザーバーの制御フローは、複雑になると追跡が困難になる可能性があります。あるグラフを別のグラフに変換するアルゴリズムは、通常、レイアウトが明確で複数のクラスにまたがっていない場合に追跡するには十分な注意が必要です。問題は、元のグラフが変更されているときに、単純で単純なグラフ変換アルゴリズムだけを使用する方法がないように見えることです。 当然のことながら、通常のグラフ変換アルゴリズムを直接使用することはできません。ゼロから開始する以外の方法で変更に対応できないためです。代わりの方法は何ですか？おそらく、アルゴリズムは継続渡しスタイルで記述できます。この場合、アルゴリズムの各ステップは、ビジターのように、元のグラフのノードのタイプごとにメソッドを持つオブジェクトとして表されます。次に、さまざまな単純なビジターを組み合わせてアルゴリズムを組み立てることができます。 別の例：JPanelsとレイアウトマネージャーを使用して、Java Swingの場合と同じようにレイアウトされたGUIがあるとします。複雑なレイアウトマネージャーの代わりにネストされたJPanelsを使用することでそのプロセスを簡略化できるため、レイアウト目的でのみ存在し、それ以外の場合は無意味なノードを含むさまざまなコンテナーのツリーになります。ここで、GUIの生成に使用されたものと同じツリーがアプリケーションの別の部分でも使用されていると想定しますが、ツリーをグラフィカルにレイアウトする代わりに、抽象表現ツリーをフォルダーのシステムとして生成するライブラリーを操作します。このライブラリを使用するには、レイアウトノードを持たないバージョンのツリーが必要です。レイアウトノードを親ノードにフラット化する必要があります。 もう1つの見方：可変ツリーを操作するというまさにその概念は、デメテルの法則に違反しています。構文解析ツリーや構文ツリーが通常のように値である場合は、実際には法律違反にはなりませんが、その場合は何も最新の状態に保つ必要がないため問題はありません。それで、この問題はデメテルの法則に違反した直接の結果として存在しますが、ドメインがツリーまたはグラフの操作に関するものであるように思われる場合、一般的にどのようにそれを回避しますか？ 複合パターンは、 1つのオブジェクトにグラフを回すとデメテルの法則に従うための素晴らしいツールです。ある種類のツリーを別の種類のツリーに効果的に変換するために複合パターンを使用することは可能ですか？抽象構文木や制御フローグラフのように機能するように、複合解析ツリーを作成できますか？単一責任の原則に違反せずにそれを行う方法はありますか？複合パターンは、クラスが彼らが触れるすべての責任を吸収する傾向がありますが、おそらくそれは戦略パターンと何らかの形で組み合わせることができます。

8 design  design-patterns  language-agnostic  data-structures  object-oriented-design 

私は以前から、さまざまな規模のクライアントを抱えるコンサルティング会社で働いており、非常に単純なものから複雑なものまで、さまざまなWebアプリケーションを見てきました。 MVC サービス層 EF DB 本当に複雑に： MVC うわー DI / IoC リポジトリー サービス UIテスト ユニットテスト 統合テスト しかし、スペクトルの両端で、品質要件はほぼ同じです。単純なプロジェクトでは、新しい開発者/コンサルタントは、何が起こっているのかを理解するために6層の抽象化をたどる必要がなく、複雑な抽象化を誤解し、コストを下げるリスクを冒すことなく、期待に応え、変更を加え、すぐに貢献できます。 すべての場合において、実際にコードをスワップ可能または再利用可能にする必要はありませんでした。また、要件が変更されたため、テストが実際に最初の反復を超えて維持されることはありませんでした。 だから-最終的に- テストとインターフェースは使用されません 迅速な開発（読み取り：コスト削減）が優先事項 プロジェクトの要件は開発中に大きく変化します ...エンタープライズクライアントに複雑な問題を解決するためであっても、超シンプルなアーキテクチャを推奨するのは間違っているでしょうか？エンタープライズソリューションを定義するのは複雑ですか、それとも信頼性、同時ユーザー数、保守の容易さ、またはこれらすべてですか。 私はこれが非常に曖昧な質問であることを知っており、どの回答もすべてのケースに当てはまるわけではありませんが、私はしばらくの間ビジネスに携わっており、これらのさまざまな程度の複雑さで機能している開発者/コンサルタントからの連絡に興味があります、少なくともプロジェクトの開発中は、クールだが高価な抽象化が全体的なコストに見合うかどうかを聞くため。

8 web-development  design-patterns  architecture  freelancing 

私が持っているabstract class A抽象メソッドを宣言しているがdoStuff。現在、を継承しAて実装するクラスが多数ありますdoStuff。 クラスのインスタンスはAFactory、ユーザー入力に基づいて実行時に初期化されます。元々、すべてのクラスには同じ単一のパラメーター（ユーザー入力）がありました。しかし今、私はAニーズを継承する新しいクラスだけである追加のパラメーターを持っています。 だから私はそれを次のロジックで分解します： ユーザー入力（AFactoryもちろん使用）に基づいてインスタンスを生成するインタープリタークラスは、この追加のパラメーターを認識していませんでした。 それをクラスインタープリタクラスにプッシュしようとすると、本当に厄介なことになります。それは、いつファクトリーに渡すかを知らなければならず、そもそもファクトリーを持つという全体の目的に反するためです。 それを何かに使うかもしれないと期待して盲目的にファクトリーに送ることも、かなり醜いようです。 私の現在の解決策：一方、にリファクタリングA.doStuff(Param param)することにしましたA.doStuff(AParams params)。 AParams必要なパラメータをすべて保持doStuffでき、興味がない場合は無視できます。これは私にとっても少し厄介なようで、WIN32APIで構造体を送信することを抑制します。この構造体は、醜く役に立たない多くのパラメーターを保持する可能性があり、私はそれが好きではありません。 この問題に取り組むよりエレガントな方法はありますか？それとも私が見落とし、これを解決したいくつかのデザインパターン？ 注： Java 1.7を使用しています クラスの名前は、理論上の設計上の問題を強調するためにばかげていますが、実際には、わかりやすく意味のある名前が付けられています。 私はかなり多くのことを検索しましたが、（このコードをXスローしている理由とは対照的に）特定の抽象的な理論的な問題をWebで検索するのは非常に難しいことがわかったExceptionので、とにかく尋ねることにしたので、これが複製。 編集1： 明確化：サブクラス固有の引数をdoStuffメソッドに渡す必要があります。 編集2： 私はKilian Fothの意図を完全には理解していなかったので、問題をよりよく説明し、解決策を理解するのに役立つJava疑似コードをいくつか書きました。そう： これは私の問題の骨組みです。 これは私のソリューションの骨組みです。 これは キリアンフォスの解決策かもしれないと思いますが、よくわかりません。

8 java  design  design-patterns  abstraction  abstract-class 

Mark Seemannの 'Ploeh'ブログを含むいくつかのソースで、IoCコンテナーのコンポジションルートの適切な配置がアプリケーションのエントリポイントに可能な限り近いことについて読んだことがあります。 .NETの世界では、これらのアプリケーションは、一般的にWebプロジェクト、WPFプロジェクト、コンソールアプリケーション、一般的なUIを持つもの（読み取り：ライブラリプロジェクトではない）と考えられているようです。 構成ルートをライブラリプロジェクトのグループの論理的なエントリポイントを表し、このようなプロジェクトグループのクライアントが他の誰かの作業である場合、構成ルートをライブラリプロジェクトのエントリポイントに配置することは、この賢明なアドバイスに本当に反していますか？ 、その作者が自分のプロジェクト（UIプロジェクトまたはさらに別のライブラリプロジェクトでさえ）にコンポジションルートを追加できない、または追加しないだろう？ 私はIoCコンテナー実装としてNinjectに精通していますが、必要なすべてのバインディング構成を含むモジュールをスキャンできるという点で、他の多くも同じように機能すると思います。これは、バインディングモジュールを独自のライブラリプロジェクトに配置して、メインライブラリプロジェクトの出力でコンパイルできることを意味します。クライアントが構成を変更したい場合（私のケースではありえないシナリオ）、置換DLLをドロップして、バインディングモジュールを含むライブラリ。 これにより、最も一般的なクライアントが依存関係の注入とコンポジションのルートを処理する必要がなくなり、ライブラリプロジェクトグループのAPIが最もクリーンになります。 しかし、これはこの問題に関する従来の知恵に直面して飛んでいるようです。そこにあるほとんどのアドバイスは、開発者が自分のケースではなく、UIプロジェクトの開発にも何らかの調整を行っていることを前提としているだけですか？

8 design-patterns  .net  dependency-injection  architectural-patterns  ioc-containers 

設定ファイルを生成するGUIアプリケーションに取り組んでいます。構成モデルのクラス階層があり、その階層のオブジェクトツリーをいくつかの異なるコンテキストで使用しています。現在、ビジターパターンを使用して、コンテキスト固有のコードでモデルクラスを汚染しないようにしています。 interface IConfigurationElement { void acceptVisitor(IConfigurationElementVisitor visitor); } 以前のバージョンinstanceofでは、ビジターの代わりに一連の条件を使用していました。2つのアプローチを比較すると、次のトレードオフが見られます。 ビジター 新しいを追加する方が簡単で安全IConfigurationElementです。新しい宣言をに追加するだけIConfigurationElementVisitorで、コンパイラはすべてのビジター実装に対してエラーを生成します。ではinstanceofチェーンあなたは、新しい構成要素を拡張する必要があるすべての場所を覚えておく必要があります。instanceof複数の場所でロジックを複製するため、基本的にDRY原則に違反します。 訪問者パターンは一連の条件よりも効率的ですinstanceof instanceof の大きな利点instanceofは、その柔軟性です。たとえば、場合instanceof によっては同様にIConfigurationElement処理する必要がある実装のさまざまなサブセットに対して特別なソリューションを定義できます。対照的に、Visitorでは毎回、各実装クラスのメソッドを実装する必要があります。 この種の問題に対する一般的な解決策はありますか？どういうわけかビジターを適応させることができるので、いくつかのケースに共通のソリューションを提供できますか？

8 java  design-patterns  object-oriented-design 

非常に使いにくいだけでなく、非常に便利なCライブラリの周りに拡張可能なC ++ラッパーを作成しました。目標は、オブジェクトの割り当て、プロパティの公開、オブジェクトの割り当て解除、セマンティクスのコピーなどのためにc ++の便利さを持たせることです... 問題はこれです。Cライブラリは、基になるオブジェクト（オブジェクトへのポインタ）を必要とする場合があり、クラスデストラクタは、基になるメモリを破棄しないでください。ほとんどの場合、デストラクタは基になるオブジェクトの割り当てを解除する必要があります。bool hasOwnershipクラスにフラグを設定して、デストラクタ、代入演算子などが、基礎となるメモリを解放する必要があるかどうかがわかるように実験しました。ただし、これはユーザーにとって煩雑であり、別のプロセスがそのメモリをいつ使用するかを知る方法がない場合もあります。 現在、基本的な型と同じ型のポインターから割り当てが行われる場合に、hasOwnershipフラグを設定するように設定しています。オーバーロードされたコンストラクターがcライブラリーからのポインターを使用して呼び出されたときも、同じことを行います。それでも、ユーザーがオブジェクトを作成し、それをc_apiを呼び出す関数の1つに渡した場合、これはまだ処理されません。ライブラリは、後で使用するためにポインターを格納します。オブジェクトを削除した場合、Cライブラリでsegfaultが発生することは間違いありません。 このプロセスを簡略化するデザインパターンはありますか？多分ある種の参照カウント？

8 c++  design-patterns  object-oriented-design 

イベントリスニングインターフェイスを提供するAPIの設計では、リスナーの追加/削除の呼び出しを処理する方法が2つ競合しているようです。 addListenerを複数回呼び出しても、1つのリスナーのみが追加されます（セットに追加するなど）。removeListenerを1回呼び出すだけで削除できます。 addListenerを複数回呼び出すと、毎回リスナーが追加されます（リストに追加するなど）。removeListenerへの複数の呼び出しでバランスを取る必要があります。 私はそれぞれの例を見つけました：（1）-ブラウザーのDOM addEventListener呼び出しはリスナーを1回だけ追加し、同じリスナーを2回追加する要求を静かに無視します（2）-jQuery .on動作はリスナーを複数回追加します。 SWTやSwingイベントリスナーなど、他のほとんどのリスナーAPIは（2）を使用しているようです。（1）を選択した場合、同じリスナーを2回追加する要求があったときに、通知なしに失敗するのか、エラーで失敗するのかという問題もあります。 私の実装では、よりクリーンなセットアップ/ティアダウンタイプのインターフェースを提供し、「セットアップ」が意図せずに2回行われ、私が見たほとんどの実装と一致するバグを明らかにするため、私は（2）に固執する傾向があります。 これは私の質問につながります-他の実装に向いている特定のアーキテクチャまたは他の基本的な設計はありますか？（つまり、なぜ他のパターンが存在するのですか？）

8 design-patterns  api 

私はDDDに不慣れで、貧弱なモデルのトランザクションスクリプトアプリ、または単にBig Balls of Mudでのみ働いていたので、私が乱用した用語を許してください。 ドメインモデルとリポジトリの適切な分離を理解しようとしています。（信じられないほど単純化された）オブジェクトをステータス（戻り値enumerable）またはIDでクエリする必要があると仮定して、データベースからのドメインオブジェクトを構築する適切な方法は何ですか。 ファクトリはオブジェクトを構築し、DIedリポジトリを使用してメソッドを公開する必要がGetByStatus()ありGetByID()ますか？ DTOからドメインモデルを構築する方法を知っていて、リポジトリを直接呼び出す必要がありますか？ ドメインモデルには、IDによる取得用のコンストラクターがあり、DIedリポジトリを使用して初期状態をロードし、リストに他の（？）メソッドを使用する必要がありますか？ 私は最善の方法が何であるか本当にわかりません、そしてこの質問はそれぞれを擁護する答えを持っています（これらは確かに相互に排他的です）。

8 design-patterns  domain-driven-design 

現在、複数の列でのフィルタリングを許可している剣道UIグリッドがあります。外側のswitchステートメントを削除する代替アプローチがあるかどうか疑問に思っていますか？ 基本的には、拡張メソッドを作成して、フィルターを適用できるようIQueryable<T> にしたいのですが、外側のcaseステートメントを削除して、列名を切り替える必要がないようにします。 private static IQueryable<Contact> FilterContactList(FilterDescriptor filter, IQueryable<Contact> contactList) { switch (filter.Member) { case "Name": switch (filter.Operator) { case FilterOperator.StartsWith: contactList = contactList.Where(w => w.Firstname.StartsWith(filter.Value.ToString()) || w.Lastname.StartsWith(filter.Value.ToString()) || (w.Firstname + " " + w.Lastname).StartsWith(filter.Value.ToString())); break; case FilterOperator.Contains: contactList = contactList.Where(w => w.Firstname.Contains(filter.Value.ToString()) || w.Lastname.Contains(filter.Value.ToString()) || (w.Firstname + " " …

8 c#  design-patterns 

1つのサービス内に2つのリポジトリを持つ方法は正しいですか？それはアプリケーションまたはドメインサービスですか？ Passport（政府ID）オブジェクトを含むべきPassengerオブジェクトがあるとします。PassengerRepositoryからPassengerを取得しています。PassengerRepositoryはサーバーへのリクエストを作成し、受信したデータを解析してリポジトリ内に保存するよりもデータ（json）を取得します。 PassportをEntityとして保存してPassportRepositoryに置きたいのですが、パスワードに関するすべての情報に、上記で受け取ったものよりもjsonの内部が含まれているため、混乱しました。 removePassport, addPassport, getAllPassengerなどのいくつかのメソッドでPassengerRepositoryとPassportRepositoryを含むPassengerServiceを作成する必要があると思います。 更新： したがって、より良い方法はPassportをVOとして表し、すべてのパスポートをPassenger集約内に格納することだと思います。ただし、別の質問があります。管理乗客のパスポートのメソッド（メソッドはサーバーAPIを呼び出す）をどこに置くべきですか。乗客の集合体のほうがいいと思います。

8 design  design-patterns  object-oriented  architecture  domain-driven-design 

コンテキスト：パイプラインモデルに従うマルチスレッド（Linux-C）アプリケーションに取り組んでいます。 各モジュールには、データの処理を行うプライベートスレッドとカプセル化されたオブジェクトがあります。各ステージには、次のユニットとデータを交換する標準形式があります。 アプリケーションはメモリリークがなく、データを交換するポイントでロックを使用してスレッドセーフです。スレッドの総数は約15で、各スレッドには1〜4個のオブジェクトを含めることができます。約25〜30個の奇妙なオブジェクトを作成します。これらすべてに重要なロギングが必要です。 私が見たほとんどの議論は、Log4Jのようなさまざまなレベルと、それ以外の翻訳です。本当に大きな問題は、全体的なロギングが実際にどのように行われるべきかについてです。 1つのアプローチは、すべてのローカルロギングが行うfprintfことstderrです。stderrはいくつかのファイルにリダイレクトされます。ログが大きくなりすぎると、このアプローチは非常に悪くなります。 すべてのオブジェクトが個々のロガーをインスタンス化する場合（そのうちの約30〜40）、ファイルが多すぎます。そして、上記とは異なり、イベントの真の順序についての考えはありません。タイムスタンプは1つの可能性ですが、照合するのはまだ面倒です。 グローバルロガー（シングルトン）のパターンが1つある場合、ログの作成でビジー状態になっている間、非常に多くのスレッドが間接的にブロックされます。スレッドの処理が重い場合、これは受け入れられません。 では、ロギングオブジェクトを構造化するための理想的な方法は何でしょうか。実際の大規模アプリケーションでのベストプラクティスにはどのようなものがありますか？ また、インスピレーションを得るために、大規模アプリケーションの実際のデザインのいくつかから学びたいと思っています。 ====== 編集： ここでの両方の答えに基づいて、私は今残っている質問です： ロガー（ロギングキュー）をオブジェクトに割り当てる場合のベストプラクティスは何ですか？それらがglobal_api（）を呼び出すか、ロガーがコンストラクターでロガーに割り当てられるかどうかです。オブジェクトが深い階層にある場合、この後のアプローチは面倒になります。それらがいくつかのglobal_api（）を呼び出している場合、それはアプリケーションとの一種のカップリングであるため、他のアプリケーションでこのオブジェクトを使用しようとすると、この依存関係がスローされます。これのためのよりきれいな方法はありますか？

8 design-patterns  multithreading  logging