2011-05-16 5 views
20

GetterおよびSetterが含まれていますはなぜメソッドの凝集(LCOM)の欠如は、ここで示したように、私は、 <p><a href="http://www.ndepend.com/Metrics.aspx" rel="noreferrer">http://www.ndepend.com/Metrics.aspx</a></p> <p></p>だから、我々はいくつかのことを言っている、メトリックLCOMで探しています

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 

私はこのようなクラスを見てみると、

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

ゲッターとセッターが「他のすべてのインスタンスフィールド」にアクセスしないため、スコアが0.94になります。

それは、次のように計算され、

accessAverage - methodCount/1 - methodCount 

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

私はこの指標を理解していないです、なぜそれがゲッターとセッターを含める必要がありますか? getterとsetterは、常に1つのインスタンスフィールドにアクセスします。

+1

私は、LCOMメトリックでは自動プロパティをフィールドと同じにするべきだと主張します。 – Gabe

+3

LCOMのようなメトリクスに関することは、実際にはクラスではない「評価」ということです。それは単なるダムPOCO(特定の非軽蔑的な意味を持つ「ダム」)、構造体(またはパスカル風のレコード)です。振る舞いはありません(メソッド間の状態関係によって典型的に表される振る舞い)。本当のクラス**ではありません。それは言語POVからではありますが、ドメインPOVからではありません(あなたが本当に気にしているものです)。私はPOJOSや構造体のLCOMメトリックの収集を避けるか、それらの結果を無視します。 LCOMは正しいです - それはクラスではありません。それに応じてその情報を使用してください。 –

+1

ゲッターとセッターは実際にクラスの結束度を低下させるので、オブジェクト指向プログラミングでは避けなければならないかもしれません:http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil。 html – yegor256

答えて

26

これは、あなたが盲目的に極端にそれを取る場合、すべてのソフトウェアメトリックに欠陥があることを示しています。

あなたは「不粘着」クラスを知っています。例えば:それはお互いにする必要はありませんデータの2枚が含まれているため

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

これは、明らかにincohesiveクラスです。

しかし、私たちにはこのクラスが不可能であることは明らかですが、インソッションを決定するソフトウェアプログラムはどのように入手できますか?上記のクラスは不粘着であるとはどのように伝えますか?

メトリックは確かにインコシスを検出しますが、誤検出もあります。

メトリックが重要であると判断した場合はどうなりますか?フィールドだけを含む "CustomerData"クラスと、プロパティとしてデータフィールドを公開する "Customer"クラスを作成することができます。

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

しかし、私はこのゲームをプレイしていた場合、私もincohesive例に適用することができます:

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

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

は本当に、私はそれが凝集が何であるかを理解することが最善だと思うし、それはなぜですソフトウェアツールが適切に測定することができないことも理解しています。

+1

非常に興味深い点があります。ありがとう。 – peter

+0

これについてもう少し考えてみても、ゲッターとセッターだけがそれぞれのフィールドにアクセスすることはないでしょうか?あるいは、メソッドのヒープがあるクラスでは、メトリックの価値が低下するはずですか? – peter

+1

私はゲッターとセッターを取り除いてはいけないと言っていると思いますか?もっと正確な結果を得られないでしょうか? – peter

関連する問題

 関連する問題