java - que - ¿Cuál es la diferencia entre una interfaz fluida y el patrón de Builder?

javafx que es

Question

Esta pregunta ya tiene una respuesta aquí:

• ¿Cuándo usarías el patrón de construcción? [cerrado] 15 respuestas

Soy muy nuevo en el diseño de patrones y tengo problemas con la diferencia entre las interfaces fluidas y el patrón de Builder.

Entiendo el concepto de interfaces fluidas. Pero el patrón del constructor es un poco confuso. No puedo entender el uso de un Director en el patrón de Constructor.

¿Puedo usar el patrón de Constructor y la Interfaz fluida juntos? Si es así, ¿cómo debería hacerlo con un Director y un constructor de concreto?

Mi pregunta no es sobre las ventajas del patrón de constructor. Pero el objetivo de esta pregunta es conocer la relación entre el patrón del constructor y la interfaz fluida.

Edite con el diagrama de secuencia UML para Builder desde GoF:

Answer 1

La idea detrás de una interfaz Fluent es que uno puede aplicar múltiples propiedades a un objeto conectándolas con puntos, sin tener que volver a especificar el objeto cada vez. La idea detrás del patrón del generador es que los objetos mudables no compartidos son a menudo más fáciles de trabajar que los inmutables no compartidos, pero es mucho más fácil razonar sobre los objetos inmutables compartidos que sobre los objetos mutables compartidos. Por lo tanto, el código puede usar un objeto mutable fácil de trabajar con para producir un "modelo" de una instancia deseada, y luego usar eso para hacer un objeto inmutable fácil de compartir que contiene los mismos datos.

Las dos ideas pueden funcionar bien juntas, pero son algo ortogonales. Tenga en cuenta que hay al menos tres formas en que puede funcionar una interfaz fluida: haciendo que cada miembro de una instancia devuelva una nueva instancia con el cambio apropiado aplicado, haciendo que cada miembro modifique la instancia en la que se invoca y la devuelva, o teniendo cada miembro devuelve una instancia de un objeto de parche ligero que contiene un enlace a la cosa que se está modificando o al parche anterior. El último estilo requiere que se tomen algunas medidas para aplicar todos los parches, pero si el objeto que se está modificando es grande y se necesitan muchos cambios, puede minimizar la cantidad de copia que se requiere.

Answer 2

Las interfaces fluidas son fachadas semánticas . Los pones encima del código existente para reducir el ruido sintáctico y para expresar más claramente lo que hace el código en un lenguaje ubicuo. Es un patrón utilizado al construir un lenguaje interno específico del dominio. Se trata de la legibilidad.

Un director / constructor orquesta la construcción de algo. Es decir, si está construyendo una máquina para hornear Pizza, el Director se aseguraría de que el constructor adecuado ejecute los pasos del pedido a la pizza en el orden correcto con los datos correctos. Se trata de validación y delegación.

Ciertamente puede poner una Interfaz fluida encima de un patrón Director / Constructor para hacer que lea más - bien - fluidamente y para enfatizar los conceptos de dominio (en comparación con el proceso técnico de creación y delegación). Eso probablemente sería un generador de expresiones entonces.

Me gustaría hacer hincapié en que las interfaces fluidas no son solo cadenas de métodos . Es un error común. Método El encadenamiento es un enfoque para implementar una interfaz fluida, pero no es lo mismo, porque carece de las cualidades semánticas, por ejemplo, esta no es una interfaz fluida:

SomeObject.setFoo(1).setBar(2).setBaz(3);

Lo anterior no expresa nada sobre SomeObject. No es una fachada en la parte superior de algún modelo semántico. Es solo algunos métodos encadenados. Un ejemplo de una interfaz fluida sería un generador de consultas SQL, por ejemplo

SQLBuilder.select(''foo'').from(''bar'').where(''foo = ?'', 42).prepare();

Bajo el capó de esa API se encuentra el código para crear una declaración SQL. Puede incluir varios objetos y las llamadas que se muestran pueden muy bien crear un objeto Select, llamar a un setter sobre él, crear un objeto Condition y aplicarlo al objeto Select y finalmente devolver un objeto Statement. Pero todo eso está escondido de nosotros. Esto también resalta otro aspecto de las interfaces fluidas: pueden violar SOLID y Law of Demeter . Pero dado que es una fachada sobre el código que, afortunadamente, sigue estos principios de diseño, no importa demasiado, ya que localiza las violaciones en la interfaz fluida.