このコーディング方法を説明するアンチパターンはありますか？[閉まっている]

プログラマーが意味をなさない領域に物事をまとめる傾向があるコードベースがあります。たとえば、エラーログがある場合、次の方法でログインできます。

ErrorLog.Log(ex, "friendly message");

彼は、まったく同じタスクを達成するために他のさまざまな手段を追加しました。例えば

SomeClass.Log(ex, "friendly message");

単に向きを変えて最初のメソッドを呼び出します。これにより、利点が追加されずに複雑さが増します。これを説明するアンチパターンはありますか？

それが合理的に広まっている場合、いくつかの悪いコーディング習慣をアンチパターンと呼ぶだけです。

残りは「ごみコード」と呼んでいます...

この特定の悪い習慣の名前を提案する場合、それは「強迫観念障害」になります:-)

いいえ、アンチパターンではありませんが、次の問題を提起します。

単一の責任原則の違反

SRPは、クラスには変更する理由が1つあるべきだと言っています。ロガーメソッドを追加すると、ロギングロジックを変更する必要がある場合、クラスも変更する必要があります。

is-a関係の違反

基本クラスは、いくつかの便利なメソッドを追加できるツールボックスではありません。

そうすることで、継承されたすべてのクラスが基本クラスの実装に効果的に結合されます。

それを作曲と比較してください。

これで受け入れられるわけではありませんが、これは未完成のリファクタリングにすぎない可能性があります。おそらく、SomeClass.log（）には独自のロジックがあり、最初に実装されました。その後、彼らはErrorLog.Log（）を使用する必要があることに気付きました。したがって、SomeClass.Log（）が呼び出される100箇所を変更するのではなく、ErrorLog.Log（）に委任するだけです。個人的には、ErrorLog.Log（）へのすべての参照を変更するか、少なくともSomeClass.log（）をコメントして、そのように委任する理由を説明します。

考慮すべきこと

「ラザニアコード」という言葉が思い浮かびますが、どうやら人によって異なることを意味しているようです。私の解釈は常に「階層化のために階層化されています」。

ErrorLogメソッドシグネチャ（SomeClassによって呼び出されるメソッド）に変更があると、このメソッドを呼び出すすべてのクライアントコードが失敗するため、これを単一の責任原則に対する違反として説明することはできません。

そこには明らかに、継承を使用する方法（またはロギングインターフェースを実装するロギングを必要とするクラスを作成する方法）があります。

または、これを「教えることができる瞬間」と見なすこともできます:)

あなたの開発者は良いアイデアに中途半端かもしれません。すべてのビジネスオブジェクトがインテリジェントロギングに対応できるという要件が必要だとします。以下を定義できます。

   public interface IBusinessObjectLogger
   {
       void Log(Exception ex, string logMessage)
   }

オブジェクトの内部で、ErrorLogオブジェクトを使用して実際にロギングを行うことができますが、SomeClassコードはオブジェクト固有の値をログメッセージに追加します。その後、ロギングAPIをさらに拡張して、ビジネスオブジェクトに触れることなく、ファイルベース、データベースベース、またはメッセージベースのロギング機能を実装できます。

これが自動的に悪かどうかはわかりません。

SomeClass.Logを呼び出している場合、それは間違いなく悪意がありますが、LogがSomeClassからのみ使用されている場合、カップリングが削減され、受け入れられると思います。

これは実際、特定のコーディングスタイルではかなり一般的であり、一連の考え方の基本はそれ自体ではアンチパターンではありません。

おそらく、より広いコードベースの知識なしに誰かが必要に応じてコーディングした結果です。「OK、このコードはエラーを記録する必要がありますが、その機能はコードの主な目的ではありません。私のために"。それは良い考え方です。しかし、ErrorLogの存在を知らずに、SomeClassを作成しました。その後、彼らは後の時点でErrorLogを見つけ、入れたメソッドのすべての使用法を置き換えるのではなく、メソッドをErrorLogに呼び出しました。これが問題になるところです。

偶発的な複雑さは、コンピュータープログラムまたはその開発プロセスで発生する複雑さであり、解決する問題にとって重要ではありません。本質的な複雑さは固有のものであり、避けられませんが、偶発的な複雑さは問題を解決するために選択されたアプローチによって引き起こされます。

http://en.wikipedia.org/wiki/Accidental_complexity

Facade Patternの悪用/誤解である可能性があります。私が使ったコードベースで似たようなものを見てきました。開発者は、OOデザインの包括的な原則を理解することなく、デザインパターンに夢中になっていた段階を経ました。

Facadeパターンの誤用は、アプリケーションのレイヤー全体の抽象化レベルを不鮮明にします。

このプログラマーが行っているのは、ロギングモジュールに直接依存しないように、いくつかのコードをラップすることです。より具体的な情報がなければ、より具体的なパターンを与えることはできません。（これらのラッパーが役に立たないのは、これ以上の情報なしでは同意または反対することが不可能であるというあなたの意見です。）

これに該当する可能性のあるパターンは、Proxy、Delegate、Decorator、Composite、または呼び出しのラッピング、非表示、または配信に関係するものです。開発が不完全な状態にある場合もあります。

文化の違いだと想像できました。この特定のコードベースに重複した機能があるのには、おそらく十分な理由があるのでしょう。書きやすさをそのような理由に想像できました。私の中でPythonプログラマは、まだ「以来、それは、悪いと言うでしょう。好ましくは、それを行うための唯一の--obvious方法が選ぶ-であるべきで、」しかし、いくつかのPerlの人は「事実に慣れているかもしれない多くのものよりもありますそれを行う方法」。