コンストラクターのみのサブクラス：これはアンチパターンですか？

私は同僚と議論をしていましたが、最終的にはサブクラス化の目的に関して直感が矛盾することになりました。私の直感では、サブクラスの主な機能がその親の限られた範囲の値を表現することであれば、おそらくサブクラスであってはならないということです。彼は反対の直観を主張しました：サブクラス化はオブジェクトがより「特定的」であることを表し、したがってサブクラス関係がより適切であるということです。

私の直感をより具体的に言うと、親クラスを拡張するサブクラスがあるが、サブクラスがオーバーライドする唯一のコードがコンストラクターである場合（そう、コンストラクターは一般に「オーバーライド」しないことを知っています。本当に必要だったのは、ヘルパーメソッドです。

たとえば、このやや現実的なクラスを考えてみましょう。

public class DataHelperBuilder
{
    public string DatabaseEngine { get; set; }
    public string ConnectionString { get; set; }

    public DataHelperBuilder(string databaseEngine, string connectionString)
    {
        DatabaseEngine = databaseEngine;
        ConnectionString = connectionString;
    }

    // Other optional "DataHelper" configuration settings omitted

    public DataHelper CreateDataHelper()
    {
        Type dataHelperType = DatabaseEngineTypeHelper.GetType(DatabaseEngine);
        DataHelper dh = (DataHelper)Activator.CreateInstance(dataHelperType);
        dh.SetConnectionString(ConnectionString);

        // Omitted some code that applies decorators to the returned object
        // based on omitted configuration settings

        return dh;
    }
}

彼の主張は、次のようなサブクラスを持つことが完全に適切だということです。

public class SystemDataHelperBuilder
{
    public SystemDataHelperBuilder()
        : base(Configuration.GetSystemDatabaseEngine(),
               Configuration.GetSystemConnectionString())
    {
    }
 }

だから、質問：

1. 設計パターンについて話す人々のうち、これらの直観のうち正しいものはどれですか？上記のサブクラス化はアンチパターンですか？
2. アンチパターンの場合、その名前は何ですか？

これが簡単にグーグル検索可能な答えであったことが判明した場合、私は謝罪します。グーグルでの私の検索は、ほとんどが望んでいるものではなく、テレスコープコンストラクターのアンチパターンに関する情報を返しました。

特定の引数でクラスXを作成するだけであれば、クラスと継承が提供する機能を使用していないため、サブクラス化はその意図を表現する奇妙な方法です。それは本当にアンチパターンではありません、それはただ奇妙であり、少し無意味です（他の何らかの理由がない限り）。この意図を表現するより自然な方法はFactory Methodで、この場合は「ヘルパーメソッド」の空想的な名前です。

一般的な直観に関して、「より具体的」と「限定された範囲」の両方が、サブクラスについて有害な考え方である可能性があります。どちらも、SquareをRectangleのサブクラスにすることが良い考えだからです。LSPのような形式的なものに依存することなく、サブクラスが基本インターフェースの実装を提供するか、インターフェースを拡張していくつかの新しい機能を追加することは、より良い直観だと思います。

これらの直観のうち正しいのはどれですか？

あなたの同僚は正しいです（標準タイプのシステムを想定しています）。

考えてみてください、クラスは可能な法的な値を表します。クラスAに1バイトフィールドがある場合、256の正当な値があるFと思うかもしれませんがA、その直感は間違っています。A「これまでの値のすべての置換」を「フィールドFは0-255にする必要があります」に制限しています。

を拡張AしBて別のバイトフィールドFFがある場合、制限が追加されます。「Fバイトの値」の代わりに、「バイトの値F&& FFもバイト」があります。古いルールを保持しているため、ベースタイプで機能するすべてのものがサブタイプでも機能します。しかし、ルールを追加しているので、「何でも可能」からさらに離れて専門化しています。

それとも別の方法を考えるために、その前提とA：サブタイプの束を持っていたB、CとD。タイプの変数はAこれらのサブタイプのいずれかである可能性がありますが、タイプの変数Bはより具体的です。（ほとんどの型システムでは）a CまたはaにはできませんD。

これはアンチパターンですか？

え？特殊なオブジェクトを持つことは有用であり、コードに明らかに有害ではありません。サブタイピングを使用してその結果を達成することは、おそらく少し疑わしいですが、使用できるツールに依存します。より優れたツールを使用しても、この実装はシンプルで簡単で堅牢です。

これはアンチパターンとは見なしません。どのような状況でも明らかに間違っていて悪くないからです。

いいえ、アンチパターンではありません。私はこのための多くの実用的なユースケースを考えることができます：

1. コンパイル時チェックを使用して、オブジェクトのコレクションが1つの特定のサブクラスのみに準拠していることを確認する場合。たとえば、あなたが持っている場合MySQLDaoと、SqliteDaoお使いのシステムでは、何らかの理由であなたはあなたが、コンパイラは、この特定の正しさを検証することができます説明するように、あなたがサブクラスを使用する場合は必ずコレクションは唯一、一つのソースからのデータを含むようにしたいです。一方、データソースをフィールドとして保存すると、これは実行時チェックになります。
2. 現在のアプリケーションでは、AlgorithmConfiguration+ ProductClassとの間に1対1の関係がありAlgorithmInstanceます。つまり、プロパティファイルでを構成FooAlgorithmする場合、その製品クラスに対してProductClass1つしか取得できませんFooAlgorithm。FooAlgorithm特定の2つのを取得する唯一の方法ProductClassは、サブクラスを作成することFooBarAlgorithmです。これは、プロパティファイルを使いやすくするためです（プロパティファイルの1つのセクションに多くの異なる構成の構文は必要ありません）。また、特定の製品クラスに複数のインスタンスが存在することは非常にまれです。
3. @Telastynの答えは、別の良い例を示しています。

結論：これを実行しても実際には害はありません。アンチパターンは、なるように定義されています。

アンチパターン（またはアンチパターン）は、通常は効果がなく、非常に非生産的なリスクが繰り返される問題に対する一般的な対応です。

ここでは非常に逆効果になるリスクはないため、アンチパターンではありません。

何かがパターンやアンチパターンであればあなたが書いているどのような言語や環境に大きく依存します。例えば、forループはパターンあるアセンブリで、C、および同様の言語とLispでアンチパターン。

私がずっと前に書いたコードの話を話しましょう...

LPCと呼ばれる言語で、ゲームで呪文を唱えるためのフレームワークを実装しました。いくつかのチェックを処理する戦闘呪文のサブクラスを持つ呪文スーパークラスがあり、それから個別の呪文（魔法ミサイル、稲妻など）にサブクラス化された単一ターゲットの直接ダメージ呪文のサブクラスがありました。

LPCの動作の性質は、シングルトンであるマスターオブジェクトがあったことです。あなたが「eww Singleton」に行く前に-それはあり、それはまったく「eww」ではありませんでした。呪文のコピーを作成するのではなく、呪文の（事実上）静的メソッドを呼び出しました。マジックミサイルのコードは次のようになりました。

inherit "spells/direct";

void init() {
  ::init();
  damage = 10;
  cost = 3;
  delay = 1.0;
  caster_message = "You cast a magic missile at ${target}";
  target_message = "You are hit with a magic missile cast by ${caster}";
}

そして、あなたはそれを見る？そのコンストラクターのみのクラス。親抽象クラスにある値を設定します（いいえ、セッターを使用するべきではありません-不変です）。ちゃんと動いた。コーディング、拡張、理解が簡単でした。

この種のパターンは、抽象クラスを拡張し、独自のいくつかの値を設定するサブクラスがあるが、すべての機能が継承する抽象クラスにある他の状況に変換されます。一目見に行くのStringBuilder本の例については、Javaでの-なく、かなりコンストラクタだけが、私は（すべてがAbstractStringBuilderである）の方法で自分自身を多くのロジックを見つけることが押されています。

これは悪いことではなく、アンチパターンではありません（一部の言語では、パターンそのものである可能性があります）。

私が考えることができるそのようなサブクラスの最も一般的な使用は例外階層ですが、それは言語がコンストラクタを継承できる限り、通常クラスで何も定義しない退化したケースです。私たちは、それを表現するために継承を使用ReadErrorする特殊なケースであるIOError、というように、しかしReadError、任意のメソッドをオーバーライドする必要はありませんIOError。

これは、型をチェックすることで例外がキャッチされるためです。したがって、必要に応じて誰かがReadErrorallをキャッチせずにのみキャッチできるように、型の特殊化をエンコードする必要がありIOErrorます。

通常、物事の種類をチェックすることはひどく悪い形式であり、それを回避しようとします。回避できた場合、型システムで特殊化を表現する必要はありません。

ただし、たとえば、オブジェクトのログに記録された文字列形式で型の名前が表示される場合など、これはまだ役立つ可能性があります。これは言語であり、フレームワーク固有です。あなたは、原則的に、我々は、その場合には、クラスのメソッドの呼び出し、とどのようなシステムタイプの名前を置き換えることができますより多くの中だけのコンストラクタよりもオーバーライドしSystemDataHelperBuilder、我々はまた、オーバーライドしたいですloggingname()。そのため、システムにそのようなロギングがある場合、クラスは文字通りコンストラクターをオーバーライドするだけですが、「道徳的に」クラス名もオーバーライドするため、実用的な目的ではコンストラクターのみのサブクラスではないことを想像できます。それは望ましい異なる行動をしている、それ '

したがって、SystemDataHelperBuilder明示的にブランチ（タイプに基づいてブランチをキャッチする例外など）のインスタンスをチェックするコードがある場合、または最終的には一般的なコードがあるため、彼のコードは良いアイデアと言えるでしょうSystemDataHelperBuilder便利な方法で名前を使用する（それが単なるログ記録であっても）。

ただし、特殊なケースに型を使用すると、混乱が生じます。これは、何らかの方法で動作が異なる場合ImmutableRectangle(1,1)、最終的に誰かが疑問に思って、そうしないことを望むためです。例外階層とは異なり、ではなくをチェックして、長方形が正方形かどうかをチェックします。あなたの例では、a と作成されたものとはまったく同じ引数で違いがあり、それが問題を引き起こす可能性があります。したがって、「正しい」引数で作成されたオブジェクトを返す関数は、通常私に正しいことです。サブクラスは「同じ」ことの2つの異なる表現をもたらし、あなたが何かをしている場合にのみ役立ちます通常はしないようにします。ImmutableSquare(1)height == widthinstanceofSystemDataHelperBuilderDataHelperBuilder

プログラマーがこれまで考えてきたすべての良いアイデアと悪いアイデアの分類法を提供することはできないと考えているため、デザインパターンやアンチパターンの観点からは話していないことに注意してください。したがって、すべてのアイデアがパターンまたはアンチパターンであるわけではなく、誰かがそれが異なるコンテキストで繰り返し発生することを識別し、それを命名するようになるだけです;-)私はこの種のサブクラス化の特定の名前を知りません。

サブクラス関係の最も厳密なオブジェクト指向定義は、「is-a」として知られています。正方形と長方形の従来の例を使用すると、正方形«is-a»長方形です。

これにより、«is-a»がコードにとって意味のある関係であると感じるあらゆる状況でサブクラス化を使用する必要があります。

コンストラクターのみを持つサブクラスの特定のケースでは、«is-a»の観点から分析する必要があります。SystemDataHelperBuilderは«is-a»DataHelperBuilderであることが明らかであるため、最初のパスはそれが有効な使用であることを示唆しています。

答えるべき質問は、他のコードのいずれかがこの「is-a」関係を活用しているかどうかです。他のコードは、SystemDataHelperBuilderとDataHelperBuilderの一般的な集団を区別しようとしていますか？その場合、関係は非常に合理的であり、サブクラスを保持する必要があります。

ただし、他のコードがこれを行わない場合、あなたが持っているのは«is-a»関係になる可能性のあるrelationshp、またはファクトリで実装される可能性があります。この場合、どちらの方法でもかまいませんが、«is-a»関係ではなくFactoryをお勧めします。別の個人によって記述されたオブジェクト指向コードを分析する場合、クラス階層は主要な情報源です。コードを理解するために必要な「is-a」関係を提供します。したがって、この動作をサブクラスに入れると、「スーパークラスのメソッドを掘り下げた場合に誰かが見つけるもの」から「コードに飛び込む前に誰もが見通すもの」への動作が促進されます。Guido van Rossumを引用して、「コードは書かれているよりも頻繁に読まれます」そのため、今後の開発者がコードの可読性を低下させることは、厳しい代償です。代わりに工場を使用できる場合は、支払わないことを選択します。

スーパータイプのインスタンスを常にサブタイプのインスタンスに置き換え、すべてが正常に機能する限り、サブタイプは決して「間違った」ものではありません。サブクラスがスーパータイプの保証を弱めようとしない限り、これはチェックアウトします。より強力な（より具体的な）保証を行うことができるため、その意味で同僚の直感は正しいです。

それを考えると、おそらくあなたが作ったサブクラスは間違っていません（私はそれらが何をするのか正確にはわからないので、確かに言うことはできません。）壊れやすい基本クラスの問題に注意する必要がありますinterfaceがあなたに利益をもたらすかどうかを検討しますが、それは継承のすべての使用に当てはまります。

この質問に答える鍵は、この特定の使用シナリオを調べることだと思います。

継承は、接続文字列などのデータベース構成オプションを強制するために使用されます。

クラスが単一責任プリンシパルに違反しているため、これはアンチパターンです。これは、「1つのことを行い、それをうまくやる」のではなく、その構成の特定のソースで自身を構成することです。クラスの構成をクラス自体にベイクしないでください。データベース接続文字列を設定する場合、ほとんどの場合、これはアプリケーションレベルで発生し、アプリケーションの起動時に何らかのイベントが発生します。

さまざまな概念を表現するために、コンストラクタのみのサブクラスを非常に定期的に使用しています。

たとえば、次のクラスを考えます。

public class Outputter
{
    private readonly IOutputMethod outputMethod;
    private readonly IDataMassager dataMassager;

    public Outputter(IOutputMethod outputMethod, IDataMassager dataMassager)
    {
        this.outputMethod = outputMethod;
        this.dataMassager = dataMassager;
    }

    public MassageDataAndOutput(string data)
    {
        this.outputMethod.Output(this.dataMassager.Massage(data));
    }
}

次に、サブクラスを作成できます。

public class CapitalizeAndPrintOutputter : Outputter
{
    public CapitalizeAndPrintOutputter()
        : base(new PrintOutputMethod(), new Capitalizer())
    {
    }
}

その後、コード内の任意の場所でCapitalizeAndPrintOutputterを使用でき、どのタイプのアウトプッターかを正確に把握できます。さらに、このパターンにより、DIコンテナーを使用してこのクラスを作成することが実際に非常に簡単になります。DIコンテナがPrintOutputMethodとCapitalizerを知っている場合、CapitalizeAndPrintOutputterを自動的に作成することもできます。

このパターンを使用すると、非常に柔軟で便利です。はい、ファクトリメソッドを使用して同じことを行うことができますが、（少なくともC＃では）型システムのパワーの一部を失い、確かにDIコンテナの使用はより面倒になります。

最初に、コードが記述されているとき、初期化された2つのフィールドは両方ともクライアントコードによって設定可能であるため、サブクラスは実際には親よりも具体的ではないことに注意してください。

サブクラスのインスタンスは、ダウンキャストを使用してのみ区別できます。

これで、アクセスするサブクラスによってDatabaseEngineand ConnectionStringプロパティが再実装されたデザインがある場合Configuration、サブクラスを持つことをより意味のある制約にできます。

とはいえ、「アンチパターン」は私の好みには強すぎます。ここには本当に悪いことは何もありません。

あなたが与えた例では、パートナーは正しい。2つのデータヘルパービルダーは戦略です。一方は他方よりも具体的ですが、初期化されると両方とも交換可能です。

基本的に、datahelperbuilderのクライアントがsystemdatahelperbuilderを受信する場合、何も壊れません。別のオプションは、systemdatahelperbuilderをdatahelperbuilderクラスの静的インスタンスにすることです。