問題タブ [anti-patterns]

認められたアンチパターンを使用すると、特定のケースで実際に機能することが証明されたことがありますか? アンチパターンを使用して、プロジェクトで問題を解決したり、何らかの利益を得たりしたことがありますか?

誰かが OOP のインターフェイスの膨張とは何かを説明できますか (できれば例を挙げて)。

代替テキストhttp://img8.imageshack.us/img8/8558/classdiagram.png

AbstractCrudDaoImpl簡単な説明：同じ親（）から継承されたインターフェースと抽象クラスの両方を実装するのが正常かどうか疑問ReadOnlyDaoです。

そのため、バックグラウンドで実行されるライブラリに束またはマルチスレッド コードを書いています。そのため、SynchronizationContext オブジェクトで UI パスを使用しているため、イベントをメインの UI スレッドに戻すことができます。

多くの異なるオブジェクトには、UI がサブスクライブできるパブリック イベントがあります。最初に、ライブラリを初期化するような作成呼び出しに SyncContext オブジェクトをパラメーターとして追加するだけです。渡されたら、それを静的クラスの静的変数に格納して、グローバルにアクセスできるようにします (内部ですが)。

UIスレッドでコードを実行する必要があるときはいつでも、多くのコードを変更せずに簡単に実行できるため、これが気に入っています. しかし、それは私のコードの多くが明示的ではない Static クラスに依存していることを意味します。依存関係を明示的にすると、変数を使用するクラスのコンストラクターに依存関係を追加し、それを必要とするオブジェクトを作成するクラスに参照を格納するために、多くのコード変更が必要になります。

だから私にはオプションがあります

A) SynchronizationContext の依存関係を隠す静的変数

B) ほぼすべてのクラスが、私の SynchronizationContext を認識し、受け渡します。

このような状況に適した別のパターンはありますか?

.net フレームワーク 3.5。メインの UI は WPF になる予定ですが、winform でも動作するようにしたいと考えています。

Microsoft Excel、Gnumeric、OpenOffice.org Calc などのプログラムが、行数と列数の制限をハードコードして設計されているのはなぜですか? これは、スプレッドシートが要求の厳しいアプリケーションと見なされ、動的メモリ割り当てが「ハイエンド」と見なされていた時代の古いプログラミング手法のようです。「それ以上のものを必要とする人はいない」という前提で、一部のリソースが静的に割り当てられていることを示しているため、アプリケーションに非常に恣意的な制限が導入されていると思います。その背後にあるロジックは何ですか？

注: この質問はプログラミングに関係ないと主張する人がいることは知っています。ここに先制的な反論があります: この質問はプログラミングに関連しています。なぜなら、普及していて一見時代遅れに見えるプログラミング方法論が使用されている理由を尋ねているからです。

サーバーベースのアプリケーションのいくつかのアーキテクチャの問題を熟考するのに苦労した後、目標を達成するにはシングルトンを使用する必要があると感じています。純粋に次の理由からです（私の匂いを正当化します）：

• 高価なオブジェクトをコール スタックの奥深くに渡す必要がない
• 任意のコンテキスト内でシングルトン管理オブジェクトに対して機能を実行できます。(多くのコードが既に存在するため、それ以外の場合は機能するコードの膨大なチャンクを書き直すつもりはありません)

それとは別に、シングルトンは別の問題を示唆しています。私のサーバーベースのアプリケーションは、基本的に、サーバーの複数のインスタンスを呼び出すことができるクラスを持つ DLL です。サーバー インスタンス クラスには、シングルトン管理オブジェクトが含まれています。通常、これは Windows サービスによって管理されるため、サーバー:マシンの比率は 1:1 になります。

したがって、次のように表示できます (ここで、-> は 1:1、=> は 1:多):

MACHINE -> ServiceHost (Windows サービス?) -> サーバー インスタンス -> シングルトン管理オブジェクト

ただし、ビジネスの必要に応じて複数のサーバーを起動できるサービス ホスト (Windows サービスまたは Win32 アプリケーション) を必要とする SaaS モデルを許可したいと考えています。したがって、物理マシンは、複数のサーバー インスタンスを実行する単一のサーバー ホストを実行できます。

どちらになりますか (ここで -> は 1:1、=> は 1:多):

MACHINE -> ServiceHost (Windows サービス?) =>サーバー インスタンス ->シングルトン管理オブジェクト

問題は、これらのシングルトンがサーバー間で共有されることです。これは起こり得ません。シングルトンは、サーバー インスタンスと 1 対 1 である必要があります。

これらのシングルトンから離れることはできないと仮定すると、サービス インスタンス クラスを個別のプロセス/メモリ空間として呼び出すことによって、これらのサーバー インスタンスを互いに分離することは可能ですか?

サーバー インスタンスごとに 1 つずつ、複数の EXE を起動する (および管理に WCF を使用する) 必要があることだけは想像できます。これは明らかにあまり良くないでしょう。

エンタープライズ向けのアプリケーションを設計する際に避けるべき主なアンチパターンは何ですか? 私たちは C# と SQL Server と Silverlight を使用していますが、アンチパターンのいくつかは言語に依存しないものになると思います。

私は最近、「アンチパターン」と呼ばれる「神オブジェクト」という用語に出くわしました。悪いコーディング慣行について聞いたことがありますが、そのように説明されていることは聞いたことがありません。

そこで、ウィキペディアにアクセスして詳細を調べたところ、 「ラビオリコード」と呼ばれるアンチパターンがあり、「多数の小さく（理想的には）緩く結合されたソフトウェアコンポーネントによって特徴付けられる」と説明されていることがわかりました。

私は困惑しています-なぜこれが悪いことなのですか？

重複の可能性：
デザインパターンについて：シングルトンをいつ使用するのですか？

この質問は、シングルトンが一般的に「有害と見なされる」かどうかに関するものではありません。あなたの経験から、シングルトンがうまく機能しているように見える特定の状況を知りたいだけです。

編集:シングルトンの適切性および/または悪性について一般的 に議論したい場合は、既存の質問があります: 137975、11831

おっとっと！私の質問がすでにここで尋ねられていることを発見しました：デザインパターンについて：シングルトンをいつ使用するのですか？

状況は次のとおりです。同じインターフェースを実装する 2 つのクラスがあり、両方のクラスが連携してビジネス プロセスを完了します。

たとえばnetworkUserManager、メソッドを持つlocalUserManager実装します。 を取得する要求をキューに入れ、応答を返します。 キューから要求を取得し、何らかのデータベースでユーザー情報を見つけて、ユーザー データで応答します。IUserManagergetUser()networkUserManager.getUser()UserlocalUserManager.getUser()

これと似たようなことが行われているのを見たとき、これは設計が悪いのではないかと思わずにはいられませんでした。これは悪い設計ですか?そうでない場合、このようなことをするのが良い考えである例は何ですか?