Si que podemos omitir la clase Machine e incluir directamente sus propiedades dentro de Computer y así ahorrarnos dicha clase (Creo que es a eso a lo que te refieres).
El motivo por el que he decidido incluirla en vez de eliminarla es porque, si se sigue ampliando dicho ejemplo, las propiedades incluidas dentro de Machine son un conjunto y por lo tanto un objeto en sí (Están dentro de la máquina).
Si el día de mañana quiero añadir periféricos a la clase Computer igual crearía un List o algo así. Solamente era porque no me parece elegante soltar las propiedades directamente en computer cuando se compone de más objetos 🙂
Las ventajas de una fluent interface no son solamente que el código es más «legible» (que también) sinó sobre todo que como desarrollador que uso una fluent interface, su uso es mucho más sencillo, ya que la interfaz me ofrece sólo en cada momento aquellos métodos (o propiedades) relevantes para lo que estoy haciendo (en contraposición a una interfaz «tradicional» donde se me exponen todos los métodos y yo debo escoger cual quiero).
Si se usa junto con algo tipo «intellisense» (y que IDE no lleva algo parecido hoy en dia?) el resultado es brutal: vas descubriendo los métodos y propiedades «a medida que las necesitas»…
@Lentucky, creo que si… La verdad es que hace mucho que abandoné el VB.NET pero viene siendo lo mismo sólo que ahora se estila también en C#…
Hola @ATP, el tipo de la variable privada _machine es correcto: Debe ser IMachine. Esto es así porque la clase Machine está implementando dicha interfaz cuando cambio el ejemplo a Fluent Interface… sólo que no mostré esa parte en el ejemplo :/ Lo agrego entonces para que quede más claro 🙂 ¡Gracias por la observación! 😀
La verdad es que he visto utilizarla en varias APIS y demás y queda bastante elegante 😀 Yo empecé a usarlo hace poco para extender los controles de ASP.NET MVC.
Después de todas las personas que han preguntado sobre la semejanza del WITH de VB.NET con Fluent Interface, el Guille ha escrito un artículo sobre ello:
Si no estoy en un error, la gran diferencia entre el uso de una interfaz y el with de VB es que con el último NO estamos obligados a utilizar todos los miembros, métodos y propiedades de la interfaz.
Ahora, una pregunta: ¿no se compromete el rendimiento al tener que tener una interfaz por cada objeto, sólo para tener un código más «mantenible»?
@Lentucky
El uso de interfaces no compromete en absoluto el rendimiento… o sea que tranquilo en este punto! 🙂
La verdad es que como comenta Guille en el enlace que ha pasado Gisela, Fluent Interfaces es un tema mucho más complejo que el encadenamiento de métodos (aunque este sea lo primero que se vea). Puedes pensar que una interfaz fluida es una interfaz que «se va describiendo a si misma a medida que la vas usando». A ver si algún dia de estos saco algo de tiempo y comento algo más al respecto en mi blog!
¿Realmente haría falta la clase Computer?
¿No nos llegaría con «unir» el comportamiento de Computer-Machine y acceder al objeto actual this?
Hola Eugenio,
Si que podemos omitir la clase Machine e incluir directamente sus propiedades dentro de Computer y así ahorrarnos dicha clase (Creo que es a eso a lo que te refieres).
El motivo por el que he decidido incluirla en vez de eliminarla es porque, si se sigue ampliando dicho ejemplo, las propiedades incluidas dentro de Machine son un conjunto y por lo tanto un objeto en sí (Están dentro de la máquina). o algo así. Solamente era porque no me parece elegante soltar las propiedades directamente en computer cuando se compone de más objetos 🙂
Si el día de mañana quiero añadir periféricos a la clase Computer igual crearía un List
Gracias por tu comentario 😀
¡Saludos!
Cada día lo creo mas … ASP.NET MVC los lleva al lado oscuro !! 😛
Salu2
MMmmm…
Las ventajas de una fluent interface no son solamente que el código es más «legible» (que también) sinó sobre todo que como desarrollador que uso una fluent interface, su uso es mucho más sencillo, ya que la interfaz me ofrece sólo en cada momento aquellos métodos (o propiedades) relevantes para lo que estoy haciendo (en contraposición a una interfaz «tradicional» donde se me exponen todos los métodos y yo debo escoger cual quiero).
Si se usa junto con algo tipo «intellisense» (y que IDE no lleva algo parecido hoy en dia?) el resultado es brutal: vas descubriendo los métodos y propiedades «a medida que las necesitas»…
saludos! 😉
Gracias por la aportación Eduard 🙂 No caí en ello cuando lo escribí.
¡Saludos!
¿Se parece al WITH de VB, o es deja vu?
En la declaracion private readonly IMachine _machine; creao que el tipo de dato es Machine o esta sin definir la interface IMachine.
Saludos y gracias.
Hola a todos,
@Lentucky, creo que si… La verdad es que hace mucho que abandoné el VB.NET pero viene siendo lo mismo sólo que ahora se estila también en C#…
Hola @ATP, el tipo de la variable privada _machine es correcto: Debe ser IMachine. Esto es así porque la clase Machine está implementando dicha interfaz cuando cambio el ejemplo a Fluent Interface… sólo que no mostré esa parte en el ejemplo :/ Lo agrego entonces para que quede más claro 🙂 ¡Gracias por la observación! 😀
¡Saludos!
Me parece una moda curiosa esto de las fluent interfaces. Supongo que triunfará como la cocacola 😛
Gracias por tu comentario Jesús 🙂
La verdad es que he visto utilizarla en varias APIS y demás y queda bastante elegante 😀 Yo empecé a usarlo hace poco para extender los controles de ASP.NET MVC.
¡Saludos!
Hola de nuevo,
Después de todas las personas que han preguntado sobre la semejanza del WITH de VB.NET con Fluent Interface, el Guille ha escrito un artículo sobre ello:
http://www.elguillemola.com/index.php/2010/07/fluent-interface-no-es-solo-simular-el-with-de-vb/
Espero que resuelva las dudas 🙂
¡Saludos!
Si no estoy en un error, la gran diferencia entre el uso de una interfaz y el with de VB es que con el último NO estamos obligados a utilizar todos los miembros, métodos y propiedades de la interfaz.
Ahora, una pregunta: ¿no se compromete el rendimiento al tener que tener una interfaz por cada objeto, sólo para tener un código más «mantenible»?
¡Saludos!
A mi lo de Fluent Interfaces me parece genial
saludos
@Lentucky
El uso de interfaces no compromete en absoluto el rendimiento… o sea que tranquilo en este punto! 🙂
La verdad es que como comenta Guille en el enlace que ha pasado Gisela, Fluent Interfaces es un tema mucho más complejo que el encadenamiento de métodos (aunque este sea lo primero que se vea). Puedes pensar que una interfaz fluida es una interfaz que «se va describiendo a si misma a medida que la vas usando». A ver si algún dia de estos saco algo de tiempo y comento algo más al respecto en mi blog!
Un saludo!
Hola Edgardo,
A mi también me gusta mucho la idea 🙂
@Eduard Gracias por tu aportación…
¡Saludos!
Hola, soy un desarrollador nuevo en ASP.NET MVC
y este tema de las «fluent interfaces» me parece interesante, espero pronto hacer uso de ellas.
Saludos!!
Hola Shuster,
Me alegra que te haya parecido interesante, creo que es una forma bastante bonita de hacer las cosas 🙂
¡Gracias por tu comentario! ¡Saludos!