1
私の同僚は、次のようなクラスを設計する傾向があります。この初期設定のアンチパターンと、場合によっては他のパターンとの間に、簡潔でよく書かれた議論がどこにありますか？
class ImportantClass
{
public SomeClass ImportantField;
public SomeOtherClass OtherImportantField;
// etc.
}
コンストラクタは書きません。
ImportantClass x;
try
{
// This is problematic enough to begin with, as every field (which is public)
// is set manually, which causes code duplication wherever this type is
// instantiated as well as maintenance problems in the event new fields are
// introduced or internal implementation is changed.
x = new ImportantClass();
x.ImportantField = new SomeClass();
x.OtherImportantField = new SomeOtherClass();
}
catch (Exception ex)
{
// ...what's even worse: now x can easily be in a totally invalid state,
// with some fields initialized and some not.
HandleAnyException(ex);
}
明らかに、上の例は単純すぎる（誇張された）例です。しかし、私はあなたがポイントを得ると思います。
私は同僚を批判するためにこれを投稿していません。むしろ、私はこのようなクラスを開発する上で多くの問題を抱えて彼に正しい方向に向かわせたいと思っています。私は個人的には、このデザインはかなり貧しいものの、簡単に「固定」されていると感じています。
私が主に関心を持つのは、彼を説得したいのであれば、強い（よくサポートされている）、理解しやすい、の簡潔な議論を持つことが重要です。彼のコードを変更する必要があると思う理由を伝える2ページの電子メールを読んでください）。
このようなうまく作られた議論を提供する良いリソースはありますか？これと他の悪いアドバイスされたデザインのアンチパターンの欠点に取り組んでいますか？ 「共通のソフトウェア設計ミス」の概要のようなものが存在する場合、非常に有益です。
メモ：単にそれについて話すことは、アドバイスを与えるための最も直接的でおそらく最も破壊的ではない方法であることを認識しています。私はちょうど考えている、もしこのようなリソースが存在すれば、私が参照として指し示すことができるこのリソースを持っていることもまたうれしい。
ワウ。彼らはそのようなものを書くために彼に支払う？ –