列挙型はコードの匂いではありませんか？

ジレンマ

オブジェクト指向の実践に関するベストプラクティスの本をたくさん読んでいますが、読んだ本のほとんどすべてに、enumはコードの匂いだと言う部分がありました。列挙型が有効な場合に説明する部分を見逃したと思います。

そのように、私を探していますガイドラインおよび/またはユースケースの列挙型がありませ有効な構文コードのにおいと、実際に。

ソース：

「警告経験則として、列挙型はコードの匂いであり、多態性クラスにリファクタリングする必要があります。[8]」Seemann、Mark 、. 342

[8] Martin Fowler et al。、Refactoring：Improving the Design of Existing Code（New York：Addison-Wesley、1999）、82。

環境

私のジレンマの原因は取引APIです。このメソッドを介して送信することにより、Tickデータのストリームを提供します。

void TickPrice(TickType tickType, double value)

どこ enum TickType { BuyPrice, BuyQuantity, LastPrice, LastQuantity, ... }

変更を壊すことがこのAPIの生き方であるため、このAPIのラッパーを作成しようとしました。ラッパーで最後に受信した各ティックタイプの値を追跡したいので、ダニタイプのディクショナリを使用してそれを行いました。

Dictionary<TickType,double> LastValues

私には、キーとして使用される場合、これは列挙型の適切な使用のように思えました。しかし、私はこのコレクションに基づいて意思決定を行う場所があり、switchステートメントを排除する方法を考えることができないため、工場を使用できますが、その工場にはまだどこかにswitchステートメント。私はただ物事を動かしているように見えましたが、まだ匂いがします。

列挙型のDO N'Tを見つけるのは簡単ですが、DOはそれほど簡単ではありません。人々が自分の専門知識、長所と短所を共有できるなら、私はそれを感謝します。

考え直し

一部の決定とアクションはこれらに基づいておりTickType、enum / switchステートメントを削除する方法を考えることはできないようです。私が考えることができる最もクリーンなソリューションは、ファクトリを使用し、に基づいて実装を返すことTickTypeです。それでも、インターフェイスの実装を返すswitchステートメントがあります。

以下は、間違った列挙型を使用しているのではないかと疑っているサンプルクラスの1つです。

public class ExecutionSimulator
{
  Dictionary<TickType, double> LastReceived;
  void ProcessTick(TickType tickType, double value)
  {
    //Store Last Received TickType value
    LastReceived[tickType] = value;

    //Perform Order matching only on specific TickTypes
    switch(tickType)
    {
      case BidPrice:
      case BidSize:
        MatchSellOrders();
        break;
      case AskPrice:
      case AskSize:
        MatchBuyOrders();
        break;
    }       
  }
}

列挙型は、変数が取り得るすべての可能な値を文字通り列挙したユースケースを対象としています。今まで。曜日や月、ハードウェアレジスタの構成値などのユースケースを考えます。安定性が高く、単純な値で表現できるもの。

腐敗防止レイヤーを作成している場合、ラッピングしているデザインのために、switchステートメントがどこかにあることを避けることはできませんが、それを正しく行う場合は、その1つの場所に制限し、他の場所でポリモーフィズムを使用します。

まず、コード臭は何かが間違っているという意味ではありません。それは何かが間違っているかもしれないことを意味します。enum頻繁に乱用されているためにおいがしますが、それはあなたがそれらを避けなければならないという意味ではありません。入力するだけでenum、停止し、より良い解決策を確認できます。

最も頻繁に発生する特定のケースは、さまざまな列挙型が、さまざまな動作で同じインターフェースを持つさまざまなタイプに対応する場合です。たとえば、さまざまなバックエンドとの対話、さまざまなページのレンダリングなど。これらは、ポリモーフィッククラスを使用してより自然に実装されます。

あなたの場合、TickTypeは異なる動作に対応していません。これらは、さまざまなタイプのイベントまたは現在の状態のさまざまなプロパティです。だから、これは列挙型にとって理想的な場所だと思います。

データ列挙を送信するとき、コードの匂いはありません

私見、データを送信するときにenums、フィールドが制限された（めったに変更されない）値のセットから値を持つことができることを示すのは良いことです。

私は、任意の送信することが望ましい考えますstringsかints。文字列は、スペルや大文字の違いによって問題を引き起こす可能性があります。Intsは範囲外の値の送信を許可し、セマンティクスはほとんどありません（たとえば3、取引サービスから受け取った場合、どういう意味ですかLastPrice？）LastQuantity？他に何か？

オブジェクトの送信とクラス階層の使用は常に可能とは限りません。たとえば、wcfでは、受信側がどのクラスが送信されたかを区別できません。

私のプロジェクトでは、サービスは操作の効果のためにクラス階層を使用し、クラス階層DataContractからオブジェクトを介して送信する直前に、タイプを示すためにunionを含む-のようなオブジェクトにコピーされますenum。クライアントは、値をDataContract使用して階層内のクラスのオブジェクトを受け取り、作成し、正しいタイプのオブジェクトを作成します。enumswitch

クラスのオブジェクトを送信したくないもう1つの理由は、送信されたオブジェクト（などLastPrice）に対して、クライアントとはまったく異なる動作がサービスで必要になる場合があることです。その場合、クラスとそのメソッドを送信することは望ましくありません。

switchステートメントは悪いですか？

私見、に応じて異なるコンストラクタを呼び出す単一の switchステートメントenumは、コードの匂いではありません。型名に基づいたリフレクションなど、他のメソッドよりも必ずしも良いまたは悪いわけではありません。これは実際の状況に依存します。

enumいたるところにスイッチを入れるのはコードのにおいであり、oopはしばしばより良い代替手段を提供します

• オーバーライドされたメソッドを持つ階層のさまざまなクラスのオブジェクトを使用します。すなわち多型。
• 階層内のクラスがほとんど変更されない場合、および（多くの）操作を階層内のクラスに疎結合する必要がある場合は、訪問者パターンを使用します。

より複雑なタイプを使用した場合：

    abstract class TickType
    {
      public abstract string Name {get;}
      public abstract double TickValue {get;}
    }

    class BuyPrice : TickType
    {
      public override string Name { get { return "Buy Price"; } }
      public override double TickValue { get { return 2.35d; } }
    }

    class BuyQuantity : TickType
    {
      public override string Name { get { return "Buy Quantity"; } }
      public override double TickValue { get { return 4.55d; } }
    }
//etcetera

その後、リフレクションからタイプをロードするか、自分でビルドすることができますが、ここで最初に行うことは、SOLIDのOpen Close Principleを保持することです

TL; DR

質問に答えるために、私は今、列挙型がそうではない時間を考えるのに苦労していますあるレベルではコードの匂いでしています。効率的に宣言するという明確な意図がありますが（この値には明確に制限された、限られた数の可能性があります）、本質的に閉じた性質により、それらはアーキテクチャ的に劣ります。

レガシーコードを大量にリファクタリングするので、すみません。/ため息; ^ D

しかし、なぜ？

これがLosTechiesのケースである理由はかなり良いレビューです：

// calculate the service fee
public double CalculateServiceFeeUsingEnum(Account acct)
{
    double totalFee = 0;
    foreach (var service in acct.ServiceEnums) { 

        switch (service)
        {
            case ServiceTypeEnum.ServiceA:
                totalFee += acct.NumOfUsers * 5;
                break;
            case ServiceTypeEnum.ServiceB:
                totalFee += 10;
                break;
        }
    }
    return totalFee;
} 

これには、上記のコードと同じ問題がすべてあります。アプリケーションが大きくなると、同様の分岐ステートメントが含まれる可能性が高くなります。また、より多くのプレミアムサービスを展開すると、このコードを継続的に変更する必要があり、これはオープンクローズドプリンシプルに違反します。ここにも他の問題があります。サービス料金を計算する機能は、各サービスの実際の金額を知る必要はありません。それはカプセル化する必要がある情報です。

ちょっとしたことですが、列挙型は非常に限られたデータ構造です。ラベル付き整数である列挙型を実際に使用していない場合は、抽象化を正しくモデル化するためのクラスが必要です。Jimmyの素晴らしいEnumerationクラスを使用して、クラスをラベルとして使用することもできます。

これをリファクタリングして、多態的な動作を使用しましょう。必要なのは、サービスの料金を計算するために必要な動作を含めることができる抽象化です。

public interface ICalculateServiceFee
{
    double CalculateServiceFee(Account acct);
}

...

これで、インターフェイスの具体的な実装を作成し、アカウントに添付できます。

public class Account{
    public int NumOfUsers{get;set;}
    public ICalculateServiceFee[] Services { get; set; }
} 

public class ServiceA : ICalculateServiceFee
{
    double feePerUser = 5; 

    public double CalculateServiceFee(Account acct)
    {
        return acct.NumOfUsers * feePerUser;
    }
} 

public class ServiceB : ICalculateServiceFee
{
    double serviceFee = 10;
    public double CalculateServiceFee(Account acct)
    {
        return serviceFee;
    }
} 

別の実装事例...

一番下の行は、列挙値に依存する動作がある場合、代わりに値が存在することを保証する同様のインターフェースまたは親クラスの異なる実装を持たないのはなぜですか？私の場合、RESTステータスコードに基づいてさまざまなエラーメッセージを見ています。の代わりに...

private static string _getErrorCKey(int statusCode)
{
    string ret;

    switch (statusCode)
    {
        case StatusCodes.Status403Forbidden:
            ret = "BRANCH_UNAUTHORIZED";
            break;

        case StatusCodes.Status422UnprocessableEntity:
            ret = "BRANCH_NOT_FOUND";
            break;

        default:
            ret = "BRANCH_GENERIC_ERROR";
            break;
    }

    return ret;
}

...おそらく、ステータスコードをクラスでラップする必要があります。

public interface IAmStatusResult
{
    int StatusResult { get; }    // Pretend an int's okay for now.
    string ErrorKey { get; }
}

その後、新しいタイプのIAmStatusResultが必要になるたびに、コーディングします...

public class UnauthorizedBranchStatusResult : IAmStatusResult
{
    public int StatusResult => 403;
    public string ErrorKey => "BRANCH_UNAUTHORIZED";
}

...そして、以前のコードIAmStatusResultがスコープ内にあることを認識しentity.ErrorKey、より複雑なデッドエンドではなく、その参照を参照できるようになりました_getErrorCode(403)。

さらに重要なことに、新しいタイプの戻り値を追加するたびに、それを処理するために他のコードを追加する必要はありません。Whaddyaが知っている、そしてenumそれswitchはおそらくコードのにおいでした。

利益。

列挙型の使用がコードの匂いであるかどうかは、コンテキストに依存します。表現の問題を考えれば、質問に答えるためのいくつかのアイデアを得ることができると思います。したがって、さまざまなタイプのコレクションとそれらに対する操作のコレクションがあり、コードを整理する必要があります。2つの簡単なオプションがあります。

• 操作に従ってコードを編成します。この場合、列挙を使用してさまざまな型にタグを付け、タグ付きデータを使用する各プロシージャにswitchステートメントを含めることができます。
• データ型に応じてコードを整理します。この場合、列挙をインターフェイスで置き換え、列挙の各要素にクラスを使用できます。次に、各操作を各クラスのメソッドとして実装します。

どのソリューションが優れていますか？

Karl Bielefeldtが指摘したように、タイプが修正され、主にこれらのタイプに新しい操作を追加することでシステムが成長することを期待している場合、enumを使用してswitchステートメントを持つことはより良いソリューションです：新しい操作が必要になるたびにクラスを使用する場合は、各クラスにメソッドを追加する必要がありますが、新しいプロシージャを実装するだけです。

一方、かなり安定した操作を期待しているが、時間の経過とともにさらにデータ型を追加する必要があると思われる場合は、オブジェクト指向ソリューションを使用する方が便利です。新しいデータ型を実装する必要があるため、同じインターフェイスを実装する新しいクラスを追加し続けますが、enumを使用している場合は、enumを使用するすべてのプロシージャのすべてのswitchステートメントを更新する必要があります。

上記の2つのオプションのいずれかで問題を分類できない場合は、より洗練されたソリューションを見ることができます（例えば、Wikipediaページをもう一度参照し てください）短い引用については、上記。

そのため、アプリケーションがどの方向に進化するかを理解し、適切なソリューションを選択する必要があります。

あなたが参照する本はオブジェクト指向のパラダイムを扱っているので、それらが列挙型の使用に偏っているのは驚くことではありません。ただし、オブジェクト指向ソリューションが常に最適なオプションとは限りません。

結論：列挙型は必ずしもコードの匂いではありません。