🚀 go-pugleaf

Adam Karpierz wrote:
> "a1" <a1@no.spam> wrote in message news:e66dmr$q62$1@inews.gazeta.pl...
> 
> 
>>Tragedia bo...? osobiscie nie widze zadnych przeciwskazan,
> 
> 
> 1. Wieksza bledogennosc - i to bledogennosc trudna niekiedy
>      do wykrycia.
Błedogennosc? Bo musze mniej kodu napisac?

> 2. Nie widac "na rzecz czego"...
>      W celu upewniania koneiczne siegniecie do definicji klasy
Mowimy o dobrze skonstruowany fluent interface, wtedy tak naprawde 
zyskujemy na czytelnosci, oczywiscie mozna napisac to w taki sposob ze 
nie bedzie wiadomo o co chodzi, ale to tyczy sie dowolnego kodu.

> 3. Mozliwe ukryte neichciane tworzenie (i usuwanie) obiektow
>     tymczasowych (np w przypadku C++).
>     Moze to powodowac paskudne efekty uboczne
W c++ to wogole wszystko moze powodowac paskudne efekty uboczne.

> Nie widze wiekszej wygody od kasycznego zapisu.
> 
> o.setX(x);
> o.setY(y);
> o.setZ(z);

A tu:

	Order o1 = new Order();
        	customer.addOrder(o1);
         OrderLine line1 = new OrderLine(6, Product.find("TAL"));
         o1.addLine(line1);
         OrderLine line2 = new OrderLine(5, Product.find("HPK"));
         o1.addLine(line2);
         OrderLine line3 = new OrderLine(3, Product.find("LGV"));
         o1.addLine(line3);
         line2.setSkippable(true);
         o1.setRush(true);

vs.

         customer.newOrder()
                 .with(6, "TAL")
                 .with(5, "HPK").skippable()
                 .with(3, "LGV")
                 .priorityRush();

Bo jednak wersja duga wydaje mi sie jakby czytelniejsza. Zreszta cala ta 
idea 'metod chaining' pochodzi jednak ze znanej z roznych jezykow 
koncepcji cascade expression.

-- 
a1 (Bartek Janusz) arcone1 gmail com