tag simple questions que presente ingles exercises estructura ejercicios ejemplos c# .net ndepend lcom

c# - ingles - tag questions presente simple



¿Por qué la falta de cohesión de métodos(LCOM, por sus siglas en inglés) incluye a los captadores y definidores? (1)

Esto demuestra que todas las métricas de software tienen fallas si las lleva ciegamente a su extremo.

Sabes una clase "incohesiva" cuando la ves. Por ejemplo:

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

Obviamente, esta es una clase incohesiva, porque contiene dos datos que no necesitan estar juntos.

Pero si bien es obvio para nosotros que esta clase es incohesiva, ¿cómo puede obtener un programa de software para determinar la incohesión? ¿Cómo diría que la clase anterior es incohesiva, pero esto no lo es?

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

La métrica que crearon sin duda detecta la incohesión, pero también presenta falsos positivos.

¿Y si decidieras que esta métrica era importante? Podría crear una clase "CustomerData" que contenga solo campos, y una clase "Customer" que exponga los campos de datos como propiedades.

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

Pero si estoy jugando este juego, también puedo aplicarlo al ejemplo incohesivo:

class Hedgehog_And_AfricanCountry_Data { public Hedgehog _hedgehog; public AfricanNation _africanNation; } class Hedgehog_And_AfricanCountry { private Hedgehog_And_AfricanCountry_Data _hedgehogAndAfricanCountryData; // etc; }

Realmente, creo que es mejor entender qué es la cohesión y por qué es un objetivo que vale la pena, pero también entender que una herramienta de software no puede medirla adecuadamente.

Estoy mirando la métrica LCOM como se muestra aquí,

http://www.ndepend.com/Metrics.aspx

Así que estamos diciendo algunas cosas,

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

Si miro una clase como esta,

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

Obtiene una mala puntuación de 0,94 porque cada captador y definidor no accede a ''todos los demás campos de instancia''.

Se calcula de esta manera,

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

No estoy entendiendo esta métrica, ¿por qué debería incluir captadores y definidores? Un captador y definidor siempre accederá a un solo campo de instancia.