Comments on: OBSEV:: Fluent Interface and c# 3.0 Extension Methods : The flexibility of dynamic typing with the powerfull AutoCompletion http://sadekdrobi.com/2007/01/07/obsev-fluentinterface-and-c-30-extension-methods-the-flexibility-of-dynamic-typing-with-the-powerfull-autocompletion/ Sadek Drobi Mon, 02 Nov 2009 05:56:20 +0100 http://wordpress.org/?v=2.8.2 hourly 1 By: jhonny http://sadekdrobi.com/2007/01/07/obsev-fluentinterface-and-c-30-extension-methods-the-flexibility-of-dynamic-typing-with-the-powerfull-autocompletion/comment-page-1/#comment-8761 jhonny Mon, 16 Feb 2009 17:34:47 +0000 http://sadekdrobi.com/?p=22#comment-8761 "reflection can be used inside the extension methods to discover properties that belong to the concrete class, and not only the interface." You can avoid this using a combination of the builder pattern with generics and generic extension methods with generic constraints. As an added benefit you'll have compile time type safety. I've blogged about it here: <a href="http://withasmiletomeltathousandhearts.wordpress.com/2009/02/16/fluent-interfaces-constraints-at-compile-time/" rel="nofollow">http://withasmiletomeltathousandhearts.wordpress.com/2009/02/16/fluent-interfaces-constraints-at-compile-time/</a> “reflection can be used inside the extension methods to discover properties that belong to the concrete class, and not only the interface.”
You can avoid this using a combination of the builder pattern with generics and generic extension methods with generic constraints.
As an added benefit you’ll have compile time type safety.
I’ve blogged about it here:
http://withasmiletomeltathousandhearts.wordpress.com/2009/02/16/fluent-interfaces-constraints-at-compile-time/

]]> By: Troy DeMonbreun http://sadekdrobi.com/2007/01/07/obsev-fluentinterface-and-c-30-extension-methods-the-flexibility-of-dynamic-typing-with-the-powerfull-autocompletion/comment-page-1/#comment-706 Troy DeMonbreun Mon, 24 Sep 2007 19:10:19 +0000 http://sadekdrobi.com/?p=22#comment-706 I wrote a article showing some "quick example" code illustrating how to build a (non-extended) Fluent Interface in C#: http://blog.troyd.net/PermaLink,guid,5cdd4862-857a-488d-a577-c6d21b548f19.aspx Thanks, Troy I wrote a article showing some “quick example” code illustrating how to build a (non-extended) Fluent Interface in C#:

http://blog.troyd.net/PermaLink,guid,5cdd4862-857a-488d-a577-c6d21b548f19.aspx

Thanks,
Troy

]]> By: Console.Write(this.Opinion) : Interfaces fluentes http://sadekdrobi.com/2007/01/07/obsev-fluentinterface-and-c-30-extension-methods-the-flexibility-of-dynamic-typing-with-the-powerfull-autocompletion/comment-page-1/#comment-31 Console.Write(this.Opinion) : Interfaces fluentes Thu, 08 Mar 2007 12:51:09 +0000 http://sadekdrobi.com/?p=22#comment-31 [...] Interfaces fluentes Escrevendo a minha da próxima revista Mundo.Net, sobre ferramentas de Mock, tive contato com as interfaces fluentes. O Rhino Mocks permite que você estabeleça as expectativas do mock em uma interface fluente. Veja como fica o código:     Expect.Call(MailerMock.SendMessage("mail@host.com")).IgnoreArguments().Return(5);    //a mesma chamada em um layout mais fácil de entender    Expect.Call(MailerMock.SendMessage("mail@host.com"))            .IgnoreArguments()            .Return(5); Ao invés de criar vários objetos e incluir cada objeto em uma propriedade do objeto principal, você simplesmente vai chamando os métodos um após o outro. Fica muito mais fácil de escrever o código, com menos linhas, e muito mais fácil de ler. É quase como uma frase separada por vírgulas. Com o código acima, por exemplo, você espera uma chamada no método SendMessage do objeto MailerMock, não quer validar os argumentos recebidos e quer forçar o retorno da chamada seja igual a 5. Achei bem interessante e resolvi implementar o exemplo que o Martin Fowler mostra no seu post sobre o assunto. Ele mostra o exemplo de uma criação de uma ordem de compra em uma linha de código. A coisa é mais simples do que parece a primeira vista. Comecei implementando as classes Customer, Order e OrderLine. Cada um tem suas propriedades, como nome, endereço de entrega, etc. O customer tem um método NewOrder que retorna um objeto Order. Até ai o código é “normal”, então tenho que criar o método With, que recebe os dados para criar uma OrderLine. O pulo do gato é retornar o próprio o objeto Order no método. O método ShipTo segue o mesmo princípio, recebe o endereço, grava na variável e retorna o this.     public class Customer    {        private string _name;        public string Name        {            get { return _name; }        }        public Customer(string name)        {            _name = name;        }        public Order NewOrder()        {            return new Order(this);        }    }    public class Order    {        private Customer _customer;        private List<OrderLine> _orderLines;        private string _shipToAddress;        public Customer Customer        {            get { return _customer; }        }        public List<OrderLine> OrderLines        {            get { return _orderLines; }        }        public string ShipToAddress        {            get { return _shipToAddress; }        }        public Order(Customer customer)        {            _orderLines = new List<OrderLine>();            _customer = customer;        }        public Order With(int itemId, float itemPrice)        {            _orderLines.Add(new OrderLine(itemId, itemPrice));            return this;        }        public Order ShipTo(string address)        {            _shipToAddress = address;            return this;        }    }    public class OrderLine    {        private int _itemId;        private float _itemPrice;        public int ItemId        {            get { return _itemId; }        }        public float ItemPrice        {            get { return _itemPrice; }        }        public OrderLine(int itemId, float itemPrice)        {            _itemId = itemId;            _itemPrice = itemPrice;        }    } A criação da ordem tanto pode ser no método tradicional como utilizando a interface fluente, como mostra o código abaixo.     //Modo tradicional    Customer cust = new Customer("Other Customer");    Order order = cust.NewOrder();    order.OrderLines.Add(new OrderLine(1, 5.0F));    order.OrderLines.Add(new OrderLine(2, 9.4F));    order.ShipTo("My address");    //Modo fluente    Customer cust = new Customer("My Customer");   Order order = cust.NewOrder()                  .With(1, 10.0F)                 .With(2, 12.3F)                 .ShipTo("My address"); Bom, não foi tão difícil em um exemplo simples, a coisa pode ficar bem mais complicada quando você quer forçar uma ordem para as chamadas ou limitar a quantidade de vezes que um método pode ser chamado. Algumas aplicações interessantes de interfaces fluentes: Rhino mocks – Mock object framework Readable regular expressions – um wrapper muito maneiro da API de regex do .Net Framework Fluent control container – Uma forma alternativa de instanciar controles ASP.Net Posts sobre aplicação prática de interfaces fluentes: A simple example of a fluent interface - Jon Galloway The Specification Pattern – Jeff Perrin Fluent Interface and c# 3.0 Extension Methods - Sadek Drobi   [...] [...] Interfaces fluentes Escrevendo a minha da próxima revista Mundo.Net, sobre ferramentas de Mock, tive contato com as interfaces fluentes. O Rhino Mocks permite que você estabeleça as expectativas do mock em uma interface fluente. Veja como fica o código:     Expect.Call(MailerMock.SendMessage(”mail@host.com”)).IgnoreArguments().Return(5);    //a mesma chamada em um layout mais fácil de entender    Expect.Call(MailerMock.SendMessage(”mail@host.com”))            .IgnoreArguments()            .Return(5); Ao invés de criar vários objetos e incluir cada objeto em uma propriedade do objeto principal, você simplesmente vai chamando os métodos um após o outro. Fica muito mais fácil de escrever o código, com menos linhas, e muito mais fácil de ler. É quase como uma frase separada por vírgulas. Com o código acima, por exemplo, você espera uma chamada no método SendMessage do objeto MailerMock, não quer validar os argumentos recebidos e quer forçar o retorno da chamada seja igual a 5. Achei bem interessante e resolvi implementar o exemplo que o Martin Fowler mostra no seu post sobre o assunto. Ele mostra o exemplo de uma criação de uma ordem de compra em uma linha de código. A coisa é mais simples do que parece a primeira vista. Comecei implementando as classes Customer, Order e OrderLine. Cada um tem suas propriedades, como nome, endereço de entrega, etc. O customer tem um método NewOrder que retorna um objeto Order. Até ai o código é “normal”, então tenho que criar o método With, que recebe os dados para criar uma OrderLine. O pulo do gato é retornar o próprio o objeto Order no método. O método ShipTo segue o mesmo princípio, recebe o endereço, grava na variável e retorna o this.     public class Customer    {        private string _name;        public string Name        {            get { return _name; }        }        public Customer(string name)        {            _name = name;        }        public Order NewOrder()        {            return new Order(this);        }    }    public class Order    {        private Customer _customer;        private List<OrderLine> _orderLines;        private string _shipToAddress;        public Customer Customer        {            get { return _customer; }        }        public List<OrderLine> OrderLines        {            get { return _orderLines; }        }        public string ShipToAddress        {            get { return _shipToAddress; }        }        public Order(Customer customer)        {            _orderLines = new List<OrderLine>();            _customer = customer;        }        public Order With(int itemId, float itemPrice)        {            _orderLines.Add(new OrderLine(itemId, itemPrice));            return this;        }        public Order ShipTo(string address)        {            _shipToAddress = address;            return this;        }    }    public class OrderLine    {        private int _itemId;        private float _itemPrice;        public int ItemId        {            get { return _itemId; }        }        public float ItemPrice        {            get { return _itemPrice; }        }        public OrderLine(int itemId, float itemPrice)        {            _itemId = itemId;            _itemPrice = itemPrice;        }    } A criação da ordem tanto pode ser no método tradicional como utilizando a interface fluente, como mostra o código abaixo.     //Modo tradicional    Customer cust = new Customer(”Other Customer”);    Order order = cust.NewOrder();    order.OrderLines.Add(new OrderLine(1, 5.0F));    order.OrderLines.Add(new OrderLine(2, 9.4F));    order.ShipTo(”My address”);    //Modo fluente    Customer cust = new Customer(”My Customer”);   Order order = cust.NewOrder()                  .With(1, 10.0F)                 .With(2, 12.3F)                 .ShipTo(”My address”); Bom, não foi tão difícil em um exemplo simples, a coisa pode ficar bem mais complicada quando você quer forçar uma ordem para as chamadas ou limitar a quantidade de vezes que um método pode ser chamado. Algumas aplicações interessantes de interfaces fluentes: Rhino mocks – Mock object framework Readable regular expressions – um wrapper muito maneiro da API de regex do .Net Framework Fluent control container – Uma forma alternativa de instanciar controles ASP.Net Posts sobre aplicação prática de interfaces fluentes: A simple example of a fluent interface – Jon Galloway The Specification Pattern – Jeff Perrin Fluent Interface and c# 3.0 Extension Methods – Sadek Drobi   [...]

]]>