このコーディング方法を説明するアンチパターンはありますか？
プログラマーが意味のない領域に物事をまとめる傾向があるコードベースがあります。たとえば、エラーログがある場合、
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によって呼び出されるメソッド）に変更があると、このメソッドを呼び出すすべてのクライアントコードが失敗するため、これを単一責任の原則に対する違反として説明するかどうかはわかりません。
そこには明らかに継承を使用する方法（またはロギングを必要とするクラスを作成し、ロギングインターフェースを実装する方法）があります。
これが自動的に悪であるかどうかはわかりません。
SomeClass.Logを呼び出している場合、それは間違いなく悪ですが、LogがWITHIN SomeClassからのみ使用されている場合、カップリングが削減されているので、許容できると思います。
または、これを「教えられる瞬間」と見なすこともできます。
あなたの開発者は良いアイデアの半分かもしれません。すべてのビジネスオブジェクトがインテリジェントロギングに対応している必要があるとします。次のように定義できます。
public interface IBusinessObjectLogger
{
void Log(Exception ex, string logMessage)
}
これでオブジェクトの内部で、ErrorLogオブジェクトを使用して実際にロギングを実行できます。SomeClassコードはオブジェクト固有の値をログメッセージに追加します。次に、ロギングAPIをさらに拡張して、ビジネスオブジェクトに手を加えることなく、ファイルベース、データベースベース、またはメッセージベースのロギング機能を実装できます。
偶発的な複雑さは、コンピュータープログラムまたはその開発プロセスで発生する複雑さであり、解決すべき問題に必須ではありません。本質的な複雑さは本質的に避けられないものですが、偶発的な複雑さは、問題を解決するために選択されたアプローチによって引き起こされます。
これは実際には特定のコーディングスタイルではかなり一般的であり、考え方の基本はそれ自体、アンチパターンではありません。
これはおそらく、より広いコードベースの知識がなくても、必要に応じてコーディングしている誰かの結果であると思います。私のために"。それは良い考え方です。しかし、ErrorLogが存在することを知らずに、SomeClassを作成しました。その後、ある時点でErrorLogを発見し、入力したメソッドのすべての使用法を置き換えるのではなく、メソッドをErrorLogに呼び出しました。 Thatは、これが問題になる場所です。
ファサードパターン の乱用/誤解である可能性があります。これまでに使用したコードベースで同様のことがわかりました。開発者は、OO設計の包括的な原則を理解せずに、設計パターンに夢中になっている段階を通過しました。
Facadeパターンを誤用すると、アプリケーションのレイヤー全体で抽象化のレベルがぼやけます。
このプログラマーが行っていることは、ロギングモジュールに直接依存しないように、一部のコードをラップすることです。より具体的な情報がなければ、より具体的なパターンを与えることはできません。 （これらのラッパーが役に立たないというのは、あなたの意見であり、これ以上の情報なしに同意または反対することは不可能です。）
これが該当する可能性のあるパターンはProxy、Delegate、Decorator、Compositeまたは関連するものです通話のラッピング、非表示、または配信。それは開発の不完全な状態でそのようなことの一つかもしれません。
それは文化の違いだと想像できました。たぶん、この特定のコードベースで機能が重複していることには十分な理由があります。そんな理由で書きやすさをイメージできました。 「Pythonプログラマーは、「 1つ-できれば1つ-当然のことですが、それを行うには明らかな方法があるので、それでも悪いと言います。 "ですが、Perlの一部の人は、「 それを行うには複数の方法があります 」という事実に慣れている場合があります。