🚀 go-pugleaf

W dniu 2013-12-26 04:04, A.L. pisze:
> On Tue, 24 Dec 2013 01:54:00 +0100, Bogus?aw Szczepanowski
> <noone@invalid.net> wrote:
>
>> Dnia 17-12-2013 o 23:42:56 A.L. <alewando@aol.com> napisał(a):
>>
>>> Za klase class ZrobCosTam
>>>
>>> po prostu wyrzucam studenta za drzwi. A hukiem
>>
>> Gratuluję nieznajomości wzorca Command.
>
> Wzorzec Command ma komponenty/klasy
>
> Command
> Invoker
> ConcreteCommand
> Receiver
> Action
>
> Nie ma klasy ZrobCosTam.  Albowiem KLASA to OBIEKT a nie CZYNNOSC.
> Klasa to abstrakcja KONCEPTU albo RZECZY ISTNIEJACEJ FIZYCZNIE,a  nei
> CZYNNOSCI.

Generalnie tak. Ale nie widzę przeszkód żeby mieć klasę opisującą 
czynność. Zresztą właśnie Command jest czynnością.

>
> CZYNNOSC to czesc zachowanai (protokolu) klasy.
>
> Proponuje Koledze wziac jakis prosty podrecznik do UML czy do Object
> Oriented Design  i przekonac sie czym jest KLASA i OBIEKT w
> programowaniu obiektowym
>
> A.L.
>

Ale to nie wyjaśnia dlaczego konkretna klasa implementująca Command nie 
mogła by się nazywać ZrobCosTam.

W aplikacji związanej z grafiką miałem wszystkie Command w paczce 
xx.commands, a ich nazwy to Move, Rotate, SetScale, itd.


Inny przykład na klasę ZrobCosTam : w Androidzie mam takie klasy które 
przyjmują na wejściu obiekt z parametrami/danymi, odpalają wątek z puli 
i próbują przetwarzać te dane w oparciu o webservice. I mają właśnie 
takie nazwy: SaveSomething, GetSomething, etc. żeby wykonać akcję tworzę 
nową instancję takiej klasy.

Powiesz że mógł bym to robić w jednym obiekcie, wołając jego funkcje 
saveSomething() etc. Mógłbym, ale i tak pod spodem musiał bym tworzyć 
obiekty trzymające aktualny stan, progress operacji. Więc naprawdę nie 
widzę sensu wprowadzać jeszcze jednego pośrednika.

-- 
Arivald