เมื่อใดที่ enums ไม่มีกลิ่นรหัส

ภาวะที่กลืนไม่เข้าคายไม่ออก

ฉันได้อ่านหนังสือฝึกหัดที่ดีที่สุดมากมายเกี่ยวกับการฝึกฝนเชิงวัตถุและหนังสือเกือบทุกเล่มที่ฉันอ่านมีส่วนที่พวกเขาบอกว่า enums เป็นกลิ่นรหัส ฉันคิดว่าพวกเขาพลาดส่วนที่พวกเขาอธิบายเมื่อ enums ถูกต้อง

ดังนั้นฉันกำลังมองหาแนวทางและ / หรือกรณีการใช้งานที่ enums ไม่ได้กลิ่นรหัสและในความเป็นจริงโครงสร้างที่ถูกต้อง

แหล่งที่มา:

"คำเตือนตามกฎของหัวแม่มือ, enums เป็นรหัสที่มีกลิ่นและควรได้รับการ refactored เพื่อเรียน polymorphic [8]" Seemann, Mark, การฉีดพึ่งพาใน. Net, 2011, p. 342

[8] Martin Fowler et al., Refactoring: การปรับปรุงการออกแบบของรหัสที่มีอยู่ (นิวยอร์ก: Addison-Wesley, 1999), 82

บริบท

สาเหตุของภาวะที่กลืนไม่เข้าคายไม่ออกของฉันคือการซื้อขาย API พวกเขาให้กระแสข้อมูล Tick โดยส่งผ่านวิธีนี้:

void TickPrice(TickType tickType, double value)

ที่ไหน enum TickType { BuyPrice, BuyQuantity, LastPrice, LastQuantity, ... }

ฉันได้ลองทำ wrapper รอบ ๆ API นี้เพราะการแตกการเปลี่ยนแปลงเป็นวิถีชีวิตของ API นี้ ฉันต้องการติดตามมูลค่าของแต่ละประเภทที่ได้รับติ๊กบนเสื้อคลุมของฉันและฉันได้ทำโดยใช้พจนานุกรมของ ticktypes:

Dictionary<TickType,double> LastValues

สำหรับฉันแล้วนี่ดูเหมือนจะเป็นการใช้งาน enum ที่เหมาะสมหากใช้เป็นกุญแจ แต่ฉันมีความคิดที่สองเพราะฉันมีสถานที่ที่ฉันตัดสินใจตามคอลเลกชันนี้และฉันไม่สามารถคิดวิธีที่ฉันสามารถกำจัดคำสั่งเปลี่ยนฉันสามารถใช้โรงงาน แต่โรงงานจะยังคงมี เปลี่ยนงบที่ไหนสักแห่ง สำหรับฉันมันดูเหมือนว่าฉันจะย้ายสิ่งต่าง ๆ รอบ ๆ แต่ก็ยังมีกลิ่น

มันง่ายที่จะหาสิ่งที่ไม่ต้องจ่ายเงิน แต่เป็นสิ่งที่ไม่ง่ายและฉันจะขอบคุณถ้าผู้คนสามารถแบ่งปันความเชี่ยวชาญข้อดีและข้อเสียของพวกเขา

ความคิดที่สอง

การตัดสินใจและการกระทำบางอย่างขึ้นอยู่กับสิ่งเหล่านี้TickTypeและฉันไม่สามารถนึกถึงวิธีที่จะกำจัดคำสั่ง enum / switch TickTypeวิธีการแก้ปัญหาที่สะอาดที่ฉันสามารถคิดจะใช้โรงงานและกลับไปดำเนินการบนพื้นฐานของ แม้ว่าฉันจะยังคงมีคำสั่ง switch ที่คืนค่าการใช้อินเตอร์เฟส

รายการด้านล่างเป็นหนึ่งในกลุ่มตัวอย่างที่ฉันสงสัยว่าฉันอาจใช้ผิด enum:

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;
    }       
  }
}

Enums มีไว้สำหรับกรณีการใช้งานเมื่อคุณระบุค่าที่เป็นไปได้ทุกอย่างที่ตัวแปรใช้ เคย คิดกรณีการใช้งานเช่นวันของสัปดาห์หรือเดือนของปีหรือค่าการกำหนดค่าของการลงทะเบียนฮาร์ดแวร์ สิ่งที่มีทั้งความเสถียรสูงและสามารถแทนค่าได้ง่าย

โปรดจำไว้ว่าถ้าคุณทำเลเยอร์ต่อต้านการทุจริตคุณไม่สามารถหลีกเลี่ยงการใช้คำสั่งสวิตช์ที่ไหนสักแห่งเนื่องจากการออกแบบที่คุณกำลังห่อหุ้ม แต่ถ้าคุณทำถูกต้องคุณสามารถ จำกัด มันไว้ในที่เดียวและ ใช้ความหลากหลายที่อื่น

ประการแรกกลิ่นรหัสไม่ได้หมายความว่ามีบางอย่างผิดปกติ หมายความว่ามีบางอย่างผิดปกติ enumมีกลิ่นเนื่องจากมีการใช้งานในทางที่ผิดบ่อยครั้ง แต่นั่นไม่ได้หมายความว่าคุณต้องหลีกเลี่ยง เพียงคุณพบว่าตัวเองพิมพ์enumหยุดและตรวจสอบวิธีแก้ไขปัญหาที่ดีกว่า

กรณีเฉพาะที่เกิดขึ้นบ่อยที่สุดคือเมื่อ enum ที่แตกต่างกันตรงกับประเภทที่แตกต่างกับพฤติกรรมที่แตกต่าง แต่อินเทอร์เฟซเดียวกัน ตัวอย่างเช่นการพูดคุยกับแบ็กเอนด์ที่แตกต่างกันการแสดงผลหน้าต่างๆและอื่น ๆ เหล่านี้มีการใช้งานอย่างเป็นธรรมชาติมากขึ้นโดยใช้คลาส polymorphic

ในกรณีของคุณ TickType ไม่สอดคล้องกับพฤติกรรมที่แตกต่าง เป็นเหตุการณ์ประเภทต่าง ๆ หรือคุณสมบัติต่าง ๆ ของสถานะปัจจุบัน ดังนั้นฉันคิดว่านี่เป็นสถานที่ที่เหมาะสำหรับ enum

เมื่อส่งข้อมูล enums ไม่มีกลิ่นรหัส

IMHO เมื่อส่งข้อมูลโดยใช้enumsเพื่อระบุว่าเขตข้อมูลสามารถมีค่าจากชุดของค่าที่ถูก จำกัด (ไม่ค่อยมีการเปลี่ยนแปลง) เป็นสิ่งที่ดี

ฉันคิดว่ามันกว่าที่จะส่งสัญญาณโดยพลการหรือstrings intsสายอักขระอาจทำให้เกิดปัญหาจากการสะกดคำและตัวพิมพ์ใหญ่ ints อนุญาตให้มีการส่งออกของค่าช่วงและมีความหมายเล็ก ๆ น้อย ๆ (เช่นผมได้รับ3จากการให้บริการการซื้อขายของคุณมันหมายความว่าอะไร? LastPrice? LastQuantity? สิ่งอื่นใด

การส่งวัตถุและการใช้ลำดับชั้นของคลาสนั้นไม่สามารถทำได้ เช่นwcfไม่อนุญาตให้จุดสิ้นสุดการรับแยกความแตกต่างของคลาสที่ถูกส่ง

ในโครงการของฉันบริการใช้ลำดับชั้นของคลาสสำหรับเอฟเฟกต์ของการดำเนินการก่อนที่จะส่งผ่านDataContractวัตถุจากลำดับชั้นของคลาสจะถูกคัดลอกลงในunionวัตถุที่เหมือนซึ่งมีการenumระบุประเภท ลูกค้าได้รับDataContractและสร้างวัตถุของคลาสในลำดับชั้นโดยใช้enumค่าswitchและสร้างวัตถุประเภทที่ถูกต้อง

อีกเหตุผลหนึ่งที่คนไม่ต้องการส่งออบเจ็กต์ของคลาสคือบริการอาจต้องการพฤติกรรมที่แตกต่างไปจากเดิมอย่างสิ้นเชิงสำหรับวัตถุที่ส่ง (เช่นLastPrice) กว่าไคลเอนต์ ในกรณีนั้นการส่งคลาสและวิธีการไม่พึงประสงค์

งบสวิตช์ไม่ดีหรือไม่?

IMHO ที่เดียว switch -statement ที่เรียกก่อสร้างงานแตกต่างกันขึ้นอยู่กับการ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

จากนั้นคุณสามารถโหลดประเภทของคุณจากการไตร่ตรองหรือสร้างมันขึ้นมาเอง แต่สิ่งที่สำคัญที่สุดที่จะเกิดขึ้นคือคุณกำลังถือหลักการเปิดปิดของโซลิด

TL; DR

เพื่อที่จะตอบคำถามตอนนี้ฉันกำลังนึกถึงเวลาที่ enums ไม่ได้มีกลิ่นรหัสในบางระดับ มีความตั้งใจบางอย่างที่พวกเขาประกาศอย่างมีประสิทธิภาพ (มีความเป็นไปได้ จำกัด จำนวนอย่างชัดเจนของความเป็นไปได้สำหรับค่านี้) แต่ธรรมชาติที่ปิดสนิทของพวกเขาทำให้พวกเขาด้อยกว่าในเชิงสถาปัตยกรรม

ขอโทษด้วยเมื่อฉันสร้างรหัสดั้งเดิมขึ้นอีกครั้ง / ถอนหายใจ; ^ 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;
} 

สิ่งนี้มีปัญหาเหมือนกับรหัสด้านบนทั้งหมด เมื่อแอพพลิเคชั่นใหญ่ขึ้นโอกาสที่จะมีคำสั่งสาขาคล้ายกันเพิ่มขึ้น นอกจากนี้เมื่อคุณเปิดตัวบริการพรีเมียมเพิ่มเติมคุณจะต้องแก้ไขรหัสนี้อย่างต่อเนื่องซึ่งเป็นการละเมิดหลักการ Open-Closed มีปัญหาอื่น ๆ ที่นี่เช่นกัน ฟังก์ชั่นในการคำนวณค่าบริการไม่จำเป็นต้องทราบจำนวนเงินที่แท้จริงของแต่ละบริการ นั่นคือข้อมูลที่จำเป็นต้องได้รับการห่อหุ้ม

ความแตกต่างเล็กน้อย: enums เป็นโครงสร้างข้อมูลที่ จำกัด มาก หากคุณไม่ได้ใช้ enum สำหรับจำนวนเต็มที่มีป้ายกำกับคุณต้องมีคลาสเพื่อจำลองแบบนามธรรมอย่างถูกต้อง คุณสามารถใช้คลาสการแจงนับที่ยอดเยี่ยมของจิมมี่เพื่อใช้คลาสเพื่อใช้เป็นป้ายกำกับ

เราจะทำการ refactor เพื่อใช้พฤติกรรม polymorphic สิ่งที่เราต้องการคือสิ่งที่เป็นนามธรรมซึ่งจะช่วยให้เรามีพฤติกรรมที่จำเป็นในการคำนวณค่าธรรมเนียมสำหรับบริการ

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;
    }
} 

อีกกรณีการใช้งาน ...

บรรทัดล่างคือถ้าคุณมีพฤติกรรมที่ขึ้นอยู่กับค่า enum ทำไมไม่มีการใช้งานที่แตกต่างกันของอินเตอร์เฟซที่คล้ายกันหรือระดับผู้ปกครองที่ช่วยให้มั่นใจว่าค่าที่มีอยู่? ในกรณีของฉันฉันกำลังดูข้อความแสดงข้อผิดพลาดต่าง ๆ ตามรหัสสถานะ 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มีแนวโน้มว่ารหัสมีกลิ่น

กำไร.

ไม่ว่าการใช้ enum จะเป็นกลิ่นรหัสหรือไม่นั้นขึ้นอยู่กับบริบท ฉันคิดว่าคุณจะได้รับความคิดบางอย่างสำหรับการตอบคำถามของคุณถ้าคุณพิจารณาปัญหาการแสดงออก ดังนั้นคุณมีคอลเลกชันประเภทต่าง ๆ และคอลเลกชันของการดำเนินการเหล่านั้นและคุณจำเป็นต้องจัดระเบียบรหัส มีสองตัวเลือกง่าย ๆ :

• จัดระเบียบรหัสตามการดำเนินการ ในกรณีนี้คุณสามารถใช้การแจงนับเพื่อแท็กประเภทที่แตกต่างกันและมีคำสั่งสลับในแต่ละขั้นตอนที่ใช้ข้อมูลที่ติดแท็ก
• จัดระเบียบรหัสตามชนิดข้อมูล ในกรณีนี้คุณสามารถแทนที่การแจงนับโดยอินเทอร์เฟซและใช้คลาสสำหรับแต่ละองค์ประกอบของการแจงนับ จากนั้นคุณใช้การดำเนินการแต่ละอย่างเป็นวิธีการในแต่ละชั้นเรียน

ทางออกไหนดีกว่ากัน?

หาก Karl Bielefeldt ชี้ให้เห็นว่าประเภทของคุณได้รับการแก้ไขและคุณคาดหวังว่าระบบจะเติบโตเป็นหลักโดยการเพิ่มการดำเนินการใหม่ในประเภทเหล่านี้จากนั้นใช้ enum และการเปลี่ยนคำสั่งเป็นทางออกที่ดีกว่า: ทุกครั้งที่คุณต้องการปฏิบัติการใหม่ เพียงใช้ขั้นตอนใหม่โดยใช้คลาสคุณจะต้องเพิ่มวิธีในแต่ละชั้นเรียน

ในทางกลับกันหากคุณคาดว่าจะมีชุดการทำงานที่ค่อนข้างเสถียร แต่คุณคิดว่าคุณจะต้องเพิ่มประเภทข้อมูลมากขึ้นเมื่อเวลาผ่านไปการใช้โซลูชันเชิงวัตถุจะสะดวกกว่า: เมื่อต้องใช้ชนิดข้อมูลใหม่คุณเพียงแค่ เพิ่มคลาสใหม่ที่ใช้อินเทอร์เฟซเดียวกันอยู่เรื่อย ๆ ในขณะที่ถ้าคุณใช้ enum อยู่คุณจะต้องอัพเดตคำสั่ง switch ทั้งหมดในโพรซีเดอร์ทั้งหมดโดยใช้ enum

หากคุณไม่สามารถจำแนกปัญหาของคุณด้วยตัวเลือกใดตัวเลือกหนึ่งจากสองตัวเลือกด้านบนคุณสามารถดูวิธีแก้ปัญหาที่ซับซ้อนมากขึ้น (ดูตัวอย่างหน้า Wikipedia ที่กล่าวถึงข้างต้นอีกครั้ง สำหรับการอภิปรายสั้น ๆ และการอ้างอิงเพื่อการอ่านเพิ่มเติม)

ดังนั้นคุณควรพยายามเข้าใจว่าแอปพลิเคชั่นของคุณพัฒนาไปในทิศทางใดแล้วเลือกวิธีที่เหมาะสม

เนื่องจากหนังสือที่คุณอ้างถึงเกี่ยวข้องกับกระบวนทัศน์เชิงวัตถุจึงไม่น่าแปลกใจที่หนังสือเหล่านี้มีอคติต่อการใช้ enums อย่างไรก็ตามการแก้ปัญหาการวางแนววัตถุไม่ใช่ตัวเลือกที่ดีที่สุดเสมอไป

Bottomline: enums ไม่จำเป็นต้องเป็นกลิ่นรหัส