2011-05-16 21 views
20

alıcı ve ayarlayıcıları içerebilir muNeden Yöntemleri Uyum (Lcom) eksikliği burada gösterildiği gibi ben <p><a href="http://www.ndepend.com/Metrics.aspx" rel="noreferrer">http://www.ndepend.com/Metrics.aspx</a></p> <p></p> yüzden birkaç şey diyorsun, metrik Lcom bakıyorum

1) A class is utterly cohesive if all its methods use all its instance fields 
2) Both static and instance methods are counted, it includes also constructors, properties getters/setters, events add/remove methods 

Ben bunun gibi bir sınıfa bakarsanız,

public class Assessment 
{ 
    public int StartMetres { get; set; } 
    public int EndMetres { get; set; } 
    public decimal? NumericResponse { get; set; } 
    public string FreeResponse { get; set; } 
    public string Responsetype { get; set; } 
    public string ItemResponseDescription { get; set; } 
    public string StartText { get; set; } 
    public decimal? SummaryWeight { get; set; } 
} 

Her bir alıcı ve ayarlayıcı 'diğer tüm örnek alanlarına' erişmediğinden, 0,94 hatalı bir puan alır.

Böyle hesaplanır,

accessAverage - methodCount/1 - methodCount 

(2 - 17)/(1 - 17) = 0.94 (rounded) 

Bu metriği Anlamıyorum, neden alıcıları ve ayarlayıcıları içermelidir? Bir alıcı ve ayarlayıcı her zaman yalnızca tek bir örnek alanına erişir.

+1

LCOM metriğinin otomatik özelliklerin alanlar ile aynı olduğunu düşünmesi gerektiğini savunuyorum. – Gabe

+3

LCOM benzeri metriklerle ilgili olan şey şu ki, 'Değerlendirme' olayı, bu gerçekten bir sınıf değil. Bu sadece aptal bir POCO ('spesifik olmayan, anlamsız bir anlama sahip dumb), bir yapı (ya da Pascal-benzeri bir paritede kayıt.) Davranışları yoktur (davranışlar arasında tipik olarak devlet ilişkileri tarafından temsil edilen davranışlar vardır.) Ergo, doğru değil ** sınıf **. Bir POV dilinden olabilir, ancak bir POV alanından değil (gerçekten neye önem verdiğinizden). POJOS veya struct'larda LCOM metriklerini toplamaktan kaçınıyorum ya da onlar için sonuçları görmezden geliyorum. LCOM haklı - bu bir sınıf değil. Bu bilgiyi buna göre kullanın. –

+1

Belki de alıcılar ve ayarlayıcılar sınıfın bütünlüğünü düşürdüğü için ve nesne yönelimli programlamada kaçınılmalıdır: http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil. html – yegor256

cevap

26

Bu, körü körüne aşırı yüklerseniz, her yazılım metriğinin hatalı olduğunu gösterir.

Birini gördüğünüzde "incohesive" sınıfı olduğunu biliyorsunuz. Örneğin: birbirleriyle olması gerekmez iki veri parçaları içerdiği için

class HedgeHog_And_AfricanCountry 
{ 

    private HedgeHog _hedgeHog; 
    private Nation _africanNation; 

    public ulong NumberOfQuills { get { return _hedgeHog.NumberOfQuills; } } 
    public int CountOfAntsEatenToday { get { return _hedgeHog.AntsEatenToday.Count(); } } 

    public decimal GrossDomesticProduct { get { return _africanNation.GDP; } } 
    public ulong Population { get { return _africanNation.Population; } } 
} 

Bu, tabii ki, bir incohesive sınıftır.

Ancak, bu sınıfın yapışkan olmadığı bize açık olsa da, inkohezyonu belirlemek için bir yazılım programına nasıl sahip olabilirsiniz? Yukarıdaki sınıfın yapışkan olmadığını nasıl söylerdi, ama bu değil mi?

class Customer 
{ 
    public string FullName { get; set; } 
    public Address PostalAddress { get; set; } 
} 

onlar ile geldi metrik kesinlikle incohesion algılar, ama aynı zamanda yanlış pozitif ile geliyor.

Bu metriğin önemli olduğuna karar verirseniz ne olur? Yalnızca alanları içeren bir "CustomerData" sınıfı ve veri alanlarını özellikler olarak gösteren bir "Müşteri" sınıfı oluşturabilirsiniz. Ben bu oyunu oynuyorum eğer

// This has no methods or getters, so gets a good cohesion value. 
class CustomerData 
{ 
    public string FullName; 
    public Address PostalAddress; 
} 

// All of the getters and methods are on the same object 
class Customer 
{ 
    private CustomerData _customerData; 
    public string FullName { get { return _customerData.FullName; } } 
    // etc 
} 

Ama ben de incohesive örnek uygulayabilirsiniz:

class Hedgehog_And_AfricanCountry_Data 
{ 
    public Hedgehog _hedgehog; 
    public AfricanNation _africanNation; 
} 

class Hedgehog_And_AfricanCountry 
{ 
    private Hedgehog_And_AfricanCountry_Data _hedgehogAndAfricanCountryData; 
    // etc; 
} 

Gerçekten, bu uyum ne olduğunu anlamak için en iyisi ve neden bir var değerli bir amaç ama aynı zamanda bir yazılım aracının bunu doğru bir şekilde ölçemediğini anlıyoruz.

+1

Çok ilginç noktalar. Teşekkürler. – peter

+0

Sadece biraz daha fazla düşünmek, bir getter ve ayarlayıcı, her seferinde bir alana yalnızca erişmeyecek mi? Veya metriklerin, yeraltı yöntemlerinin olduğu sınıflara indirilmesi gereken değeri nedir? – peter

+1

Sanırım söylemeye çalıştığım şey, alıcıları ve ayarlayıcıları çıkarmamalı mıyız? Bu daha doğru sonuçlar vermez mi? – peter