Con frecuencia uso un patrón donde uso el método de encadenamiento para configurar un objeto, similar a un patrón Builder
o Prototype
, pero no creo nuevos objetos con cada llamada al método, sino que modifico el objeto original.
Ejemplo:
new Menu().withItem("Eggs").withItem("Hash Browns").withStyle("Diner");
Solo me pregunto si hay un nombre para este patrón y si se considera un antipatrón, porque aunque puede leer con más fluidez, puede conducir a largas cadenas de métodos.
menu.withStyle("")
sin contexto. Necesita dos API en tal caso.Respuestas:
Interfaz fluida
Siempre he escuchado que este método se llama una " interfaz fluida ", como lo acuñaron Eric Evans (de la fama de diseño impulsado por el dominio ) y Martin Fowler (de la fama del Manifiesto Ágil ).
Los principales inconvenientes son la legibilidad (que algunas personas aman y otras odian), y el hecho de que puede ser más difícil de depurar en algunos casos porque toda la cadena de acciones puede considerarse una sola declaración al pasar por ella.
Ciertamente no lo considero un antipatrón, aunque solo he usado la técnica unas pocas veces.
fuente
El método de encadenamiento como ese generalmente se llama una interfaz fluida cuando hay algún tipo de flujo o capacidad de detección en la cadena. Alternativamente, puede pensar en una API como jQuery que se basa en gran medida en el encadenamiento de métodos como no 'fluido' porque no hay el mismo énfasis en la capacidad de descubrimiento: es más por conveniencia.
Para su ejemplo (usando withx, withy) puede considerar esto como una variante del patrón Builder porque tiene una clase especializada que, dado algún estado (llamadas a métodos) sabe cómo devolver un objeto configurado correctamente.
Esto no es un antipatrón si se usa adecuadamente.
fuente
Definitivamente no es un antipatrón. jQuery es probablemente la implementación más utilizada de esto.
Sí puede, pero ¿cuál es la alternativa? Puede terminar con una oración casi en inglés, con la API que lo guía a lo que está disponible y es apropiado.
fuente
Se llama patrón de "choque de trenes".
(Es un antipatrón y está en contra de Clean Code)
El patrón de "choque de trenes" viola la Ley de Deméter .
fuente
a.getB().getC().doSomething()
. Ese ejemplo es malo porque "Su método puede invocar métodos en sus propios campos directamente (pero no en los campos de los campos)". Aquí, solo se está creando un objeto, y "puedes jugar con los juguetes que has hecho tú mismo".