Numaralandırmalar ne zaman bir kod kokusu DEĞİLDİR?

İkilem

Nesneye yönelik uygulamalar hakkında birçok iyi uygulama kitabı okudum ve okuduğum hemen hemen her kitabın, numaraların kod kokusu olduğunu söyledikleri bir parçası vardı. Sanırım sayılar geçerli olduğunda açıkladıkları kısmı kaçırmışlar.

Gibi, enums bir kod kokusu DEĞİL ve aslında geçerli bir yapı DEĞİL yönergeleri ve / veya kullanım durumları arıyorum .

Kaynaklar:

"UYARI Genel bir kural olarak, numaralandırmalar kod kokularıdır ve polimorfik sınıflara yeniden konulmalıdır. [8]" Seemann, Mark, .Net, 2011, s. 342

[8] Martin Fowler ve ark., Yeniden Düzenleme: Mevcut Kod Tasarımının Geliştirilmesi (New York: Addison-Wesley, 1999), 82.

bağlam

İkilemin nedeni bir ticaret API'sı. Bu yöntemle bana bir Tick verileri akışı veriyorlar:

void TickPrice(TickType tickType, double value)

nerede enum TickType { BuyPrice, BuyQuantity, LastPrice, LastQuantity, ... }

Değişiklikleri kırmak bu API için yaşam biçimi olduğundan, bu API etrafında bir sarmalayıcı yapmayı denedim. Benim sarıcı üzerinde her son alınan kene türünün değerini takip etmek istedim ve bunu Ticktypes bir Sözlük kullanarak yaptım:

Dictionary<TickType,double> LastValues

Bana göre bu, anahtar olarak kullanıldıklarında bir enumun doğru kullanımı gibi görünüyordu. Ama ikinci düşüncelerim var, çünkü bu koleksiyona dayalı bir karar verdiğim bir yerim var ve anahtar ifadesini nasıl ortadan kaldırabileceğimi düşünemiyorum, bir fabrika kullanabilirim ama o fabrika hala bir ifadeyi bir yerde değiştir. Bana sadece bir şeyleri hareket ettiriyor gibiydim ama yine de kokuyor.

DON'T'ları bulmak kolay, ama DO'lar, o kadar kolay değil ve insanlar uzmanlıklarını, artılarını ve eksilerini paylaşabilirlerse memnun olurum.

Düşüne taşına verilen kararlar

Bazı kararlar ve eylemler bunlara dayanmaktadır TickTypeve enum / switch ifadelerini ortadan kaldırmanın bir yolunu düşünemiyorum. Aklıma gelen en temiz çözüm bir fabrika kullanmak ve bir uygulamaya dayanmaktır TickType. O zaman bile hala bir arabirimin uygulanmasını döndüren bir anahtar deyimim olacak.

Aşağıda, yanlış bir numaralandırma kullanıyor olabileceğimden şüphe duyduğum örnek sınıflardan biri var:

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

Numaralandırmalar, bir değişkenin alabileceği her olası değeri tam olarak numaralandırdığınızda kullanım durumlarına yöneliktir. Hiç. Haftanın günleri veya yılın ayları gibi kullanım durumlarını veya bir donanım kaydının yapılandırma değerlerini düşünün. Hem son derece kararlı hem de basit bir değerle temsil edilebilen şeyler.

Yolsuzlukla mücadele katmanı oluşturuyorsanız, sarmaladığınız tasarım nedeniyle bir yerde bir anahtar ifadesi kullanmaktan kaçınamayacağınızı unutmayın, ancak doğru yaparsanız bunu bir yerle sınırlandırabilirsiniz ve başka yerde polimorfizm kullanın.

İlk olarak, kod kokusu bir şeyin yanlış olduğu anlamına gelmez. Bir şeylerin yanlış olabileceği anlamına gelir. enumkokuyor çünkü sık sık istismar ediliyor, ancak bu onlardan kaçınmanız gerektiği anlamına gelmiyor. Kendinizi yazarken bulabilirsiniz enum, durun ve daha iyi çözümler olup olmadığını kontrol edin.

En sık meydana gelen özel durum, farklı sıralamanın farklı davranışları olan ancak aynı arabirime sahip farklı türlere karşılık gelmesidir. Örneğin, farklı arka uçlarla konuşmak, farklı sayfalar oluşturmak, vb. Bunlar çok daha doğal olarak polimorfik sınıflar kullanılarak uygulanır.

Sizin durumunuzda, TickType farklı davranışlara karşılık gelmiyor. Bunlar farklı olay türleri veya mevcut durumun farklı özellikleridir. Bence bu bir enum için ideal bir yer.

Veri numaralarını iletirken kod kokusu yok

IMHO, enumsbir alanın sınırlı (nadiren değişen) bir değer kümesinden bir değere sahip olabileceğini belirtmek için kullanarak veri iletirken iyidir.

Ben keyfi stringsya da iletmenin tercih edilebilir olduğunu düşünüyorum ints. Dizeler, yazım ve büyük harf kullanımı ile ilgili sorunlara neden olabilir. Ints aralık dışında değer iletmek için izin ve küçük anlambilim (var mesela aldığım 3ticaret hizmetinden, bu ne demek oluyor? LastPrice? LastQuantity? Başka bir şey?

Nesneleri aktarmak ve sınıf hiyerarşilerini kullanmak her zaman mümkün değildir; örneğin wcf , alıcı sonun hangi sınıfın gönderildiğini ayırt etmesine izin vermez.

Projemde, hizmet, sınıf hiyerarşisinden bir DataContractnesne aracılığıyla iletmeden hemen önce , türü belirtmek için unionbir içeren bir nesneye kopyalanırken , işlemlerin etkileri için bir sınıf hiyerarşisi kullanır enum. İstemci, DataContracthiyerarşisinde bir sınıfın nesnesini alır ve doğru türdeki bir nesneyi kullanarak enumdeğerini oluşturur switchve oluşturur.

Kişinin sınıf nesnelerini iletmek istememesinin bir başka nedeni, hizmetin iletilen bir nesne (örneğin LastPrice) için istemciden tamamen farklı bir davranış gerektirebilmesidir . Bu durumda, sınıfın ve yöntemlerinin gönderilmesi istenmeyen bir durumdur.

Anahtar ifadeleri kötü mü?

IMHO, bağlı olarak farklı kurucuları çağıran tek switch bir enumdurum kod kokusu değildir. Bir daktiloda yansıma tabanı gibi diğer yöntemlerden daha iyi veya daha kötü olmak zorunda değildir; bu gerçek duruma bağlıdır.

Her yerde anahtarlara sahip olmak enumbir kod kokusudur , oop genellikle daha iyi alternatifler sunar:

• Geçersiz kılınmış yöntemleri olan bir hiyerarşinin farklı sınıflarının nesnesini kullanın; yani polimorfizm.
• Hiyerarşideki sınıflar nadiren değiştiğinde ve (birçok) işlemin hiyerarşideki sınıflara gevşek bir şekilde bağlanması gerektiğinde ziyaretçi desenini kullanın.

daha karmaşık bir türle gittiyseniz:

    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

o zaman türlerinizi yansımadan yükleyebilir veya kendiniz inşa edebilirsiniz, ancak buraya gelen ilk şey, SOLID'in Açık Kapat Prensibine bağlı kalmanızdır.

TL; DR

Soruyu cevaplamak için, şimdi enumların bir düzeyde kod kokusu olmadığını düşündüğüm bir zamanım var . Verimli bir şekilde beyan etmelerinin belirli bir amacı var (bu değer için açıkça sınırlı, sınırlı sayıda olasılık var), ancak doğası gereği kapalı doğaları onları mimari olarak daha aşağı yapıyor.

Affedersiniz, tonlarca eski kodumu tekrar gözden geçiriyorum. / iç çek; ^ D

Ama neden?

Buradaki LosTechies için neden böyle iyi bir inceleme :

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

Bu, yukarıdaki kodla aynı sorunların tümüne sahiptir. Uygulama büyüdükçe, benzer şube açıklamalarına sahip olma şansı artacaktır. Ayrıca daha fazla premium hizmet sunarken Açık-Kapalı Prensibi'ni ihlal eden bu kodu sürekli olarak değiştirmeniz gerekecektir. Burada başka sorunlar da var. Hizmet ücretini hesaplama işlevinin, her hizmetin gerçek miktarlarını bilmesi gerekmez. Bu, kapsüllenmesi gereken bilgidir.

Hafif bir kenara: numaralandırmalar çok sınırlı bir veri yapısıdır. Gerçekten bir numaralandırma olan etiketli bir tamsayı kullanmıyorsanız, soyutlamayı doğru bir şekilde modellemek için bir sınıfa ihtiyacınız vardır. Jimmy'nin müthiş Numaralandırma sınıfını sınıfları da etiket olarak kullanmak için kullanabilirsiniz.

Bunu polimorfik davranış kullanmak için yeniden düzenleyelim. İhtiyacımız olan şey, bir hizmetin ücretini hesaplamak için gerekli davranışı içermemizi sağlayacak soyutlamadır.

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

...

Artık arayüzün somut uygulamalarını oluşturabilir ve bunları hesaba bağlayabiliriz.

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

Başka bir uygulama örneği ...

Sonuç olarak, enum değerlerine bağlı bir davranışınız varsa, neden bunun yerine değerin var olmasını sağlayan benzer bir arabirimin veya üst sınıfın farklı uygulamaları olmasın? Benim durumumda, REST durum kodlarına dayalı farklı hata mesajlarına bakıyorum. Onun yerine...

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

... belki de sınıflara durum kodlarını sarmalıyım.

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

Sonra her zaman yeni bir IAmStatusResult türüne ihtiyacım var, ben kod ...

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

... ve şimdi daha önceki kodun bir IAmStatusResultkapsamı olduğunu fark etmesini entity.ErrorKeyve daha kıvrımlı, ölümcül yerine referansını sağlayabilirim _getErrorCode(403).

Ve daha da önemlisi, her yeni bir dönüş değeri türü eklediğimde, işlemek için başka bir kodun eklenmesi gerekmez . Whaddya biliyor, kod kokuyor enumve switchmuhtemelen vardı.

Kar.

Bir enum kullanmanın bir kod kokusu olup olmadığı bağlama bağlıdır. İfade problemini düşünürseniz, sorunuzu cevaplamak için bazı fikirler edinebileceğinizi düşünüyorum . Yani, farklı türde bir koleksiyonunuz ve bunlar üzerinde bir operasyon koleksiyonunuz var ve kodunuzu düzenlemelisiniz. İki basit seçenek vardır:

• Kodu işlemlere göre düzenleyin. Bu durumda, farklı türleri etiketlemek için bir numaralandırma kullanabilir ve etiketli verileri kullanan her yordamda bir anahtar ifadesi kullanabilirsiniz.
• Kodu veri türlerine göre düzenleyin. Bu durumda, numaralandırmayı bir arabirim ile değiştirebilir ve numaralandırmanın her öğesi için bir sınıf kullanabilirsiniz. Daha sonra her işlemi her sınıfta bir yöntem olarak uygularsınız.

Hangi çözüm daha iyi?

Karl Bielefeldt'in belirttiği gibi, türleriniz sabittir ve sistemin esas olarak bu türlere yeni işlemler ekleyerek büyümesini beklerseniz, daha sonra bir enum kullanarak ve bir anahtar ifadesi kullanmak daha iyi bir çözümdür: her yeni işleme ihtiyacınız olduğunda sınıfları kullanarak her sınıfa bir yöntem eklemek zorunda kalacaksınız.

Öte yandan, oldukça kararlı bir işlem kümesine sahip olmayı bekliyorsanız, ancak zamanla daha fazla veri türü eklemeniz gerektiğini düşünüyorsanız, nesne odaklı bir çözüm kullanmak daha uygundur: yeni veri türlerinin uygulanması gerektiğinden, aynı arabirimi uygulayan yeni sınıflar eklemeye devam ederken enum kullanıyorsanız, enum'u kullanan tüm yordamlardaki tüm anahtar deyimlerini güncellemeniz gerekir.

Sorununuzu yukarıdaki iki seçenekten birinde sınıflandıramıyorsanız, daha karmaşık çözümlere bakabilirsiniz ( kısa bir tartışma ve daha fazla okuma için bazı referanslar için yukarıda belirtilen Wikipedia sayfasına bakın ).

Bu nedenle, uygulamanızın hangi yönde gelişebileceğini anlamaya çalışmalı ve ardından uygun bir çözüm seçmelisiniz.

Bahsettiğiniz kitaplar, nesne yönelimli paradigma ile uğraştığından, numaralandırmalara karşı önyargılı olmaları şaşırtıcı değildir. Ancak, bir nesne yönlendirme çözümü her zaman en iyi seçenek değildir.

Alt satır: numaralandırmalar mutlaka bir kod kokusu değildir.