El wikipedia article sobre Law of Demeter dice:¿Las interfaces fluidas violan la Ley de Demeter?
La ley puede afirmar simplemente como "usar sólo un punto".
Sin embargo, un simple example de un fluent interface puede tener este aspecto:
static void Main(string[] args)
{
new ZRLabs.Yael.Pipeline("cat.jpg")
.Rotate(90)
.Watermark("Monkey")
.RoundCorners(100, Color.Bisque)
.Save("test.png");
}
Entonces, ¿esto va de la mano?
Bueno, la breve definición de la ley lo acorta demasiado. La "ley" real (en realidad, consejos sobre un buen diseño de API) básicamente dice: solo acceda a los objetos que creó usted mismo o que se le pasaron como argumento. No acceda a los objetos indirectamente a través de otros objetos. Los métodos de interfaces fluidas a menudo devuelven el objeto en sí, por lo que no violan la ley, si usa el objeto nuevamente. Otros métodos crean objetos para ti, por lo que tampoco hay infracción.
También tenga en cuenta que la "ley" es solo un consejo de mejores prácticas para las API "clásicas". Las interfaces fluidas son un enfoque completamente diferente al diseño de API y no se pueden evaluar con la Ley de Demeter.
Sí, aunque hay que aplicar un poco de pragmatismo a la situación. Siempre tomo la Ley de Demeter como una guía en lugar de una regla.
Ciertamente, es muy posible que desee evitar lo siguiente:
CurrentCustomer.Orders[0].Manufacturer.Address.Email(text);
quizá Reemplazar con:
CurrentCustomer.Orders[0].EmailManufacturer(text);
A medida que más de nosotros usamos ORM que generalmente presenta todo el dominio como un gráfico de objetos que podrían ser una idea para definir "alcance" aceptable para un objeto en particular. Tal vez deberíamos tomar la ley de Demeter para sugerir que no se debe mapear todo el gráfico como alcanzable.
creo que la Responsabilidad Individual principio podría entenderse en el sentido de "no tener un método en su Business Object para enviar correos electrónicos ". –
No necesariamente. "Utilizar solo un punto" es un resumen inexacto de la Ley de Demeter.
La Ley de Demeter desalienta el uso de múltiples puntos cuando cada punto representa el resultado de un objeto diferente, por ejemplo:
Sin embargo, al menos en mi opinión, la Ley de Demeter ¿no infringe si el objeto de retorno de cada punto sigue siendo el mismo tipo que la llamada original:
var List<SomeObj> list = new List<SomeObj>();
//initialize data here
return list.FindAll(i => i == someValue).Sort(i1, i2 => i2 > i1).ToArray();
En el ejemplo anterior, tanto FindAll () y Sort() devuelven el mismo tipo de objeto que la lista original. La Ley de Demeter no se viola: la lista solo hablaba con sus amigos inmediatos.
Dicho no todas las interfaces con fluidez violan la Ley de Demeter, siempre y cuando devuelvan el mismo tipo que la persona que llama.
El espíritu de la Ley de Demeter es que, dada una referencia de objeto o clase, debe evitar acceder a las propiedades de una clase que tiene más de una subpropiedad o método lejos, ya que eso vinculará las dos clases, lo que podría ser involuntario y puede causar problemas de mantenimiento.
Interfaces fluidas son una excepción aceptable a la ley ya que son significaron para estar al menos unidas estrechamente ya que todas las propiedades y métodos son los términos de un minilengua que se componen juntas para formar oraciones funcionales.
No hay problema con su ejemplo. Después de todo, estás girando, marcas de agua, etc ... siempre la misma imagen. Creo que estás hablando con un objeto Pipeline todo el tiempo, por lo que siempre y cuando tu código solo dependa de la clase de Pipeline, no estás violando LoD.
1) No lo viola en absoluto.
El código es equivalente a
var a = new ZRLabs.Yael.Pipeline("cat.jpg");
a = a.Rotate(90);
a = a.Watermark("Monkey");
a = a.RoundCorners(100, Color.Bisque);
a = a.Save("test.png");
2) As Good Ol' Phil Haack dice: The Law of Demeter Is Not A Dot Counting Exercise
Se podría argumentar que una interfaz fluida no viola la Ley de Demeter porque solo está accediendo al mismo objeto en una cadena de puntos. – MSN
Una segunda forma de ver esto es que una interfaz fluida es simplemente una forma alternativa y compacta de realizar operaciones secuenciadas de tal manera que la mutación de estado se abstraiga, ya que los resultados de cada paso intermedio están implícitos. –