🚀 go-pugleaf

W dniu 2010-03-26 22:47, Maciej Sobczak pisze:
> On 26 Mar, 17:34, keef<a...@a.com>  wrote:
>
>>>>> Runnable nie powstał tylko po to, stosuje się go w wielu wielu wielu
>>>>> miejscach
>
>>>> Po co takie sztuczki ?
>
>>> znakomity przykład użycia masz właśnie w klasie Thread.
>
>> Bomba! Czy jeszcze jakiś inny pomysł na użycie poza Thread?
>
> Np. javax.swing.SwingUtilities.invokeLater(...)
>
> Nie czepiaj się Runnable. To wyłącznie efekt konstrukcji języka, który
> nie oferuje innych mechanizmów.
> Runnable sam w sobie nie ma nic wspólnego z wątkami, więc jego użycie
> w definicji klasy nie sugeruje wielowątkowości. To jest jedynie
> znacznik: "uwaga, instancje tej klasy można wywołać", gdzie
> "wywołanie" to właśnie run(). Kontekstów na użycie czegoś takiego jest
> wiele.

Podobnie jak Serializable - również jest interfejsem znacznikowym.

Poza tym przeczytaj dokładnie o co chodzi - wyciąłeś ten tekst więc 
pozwól, że go wstawię:

<ciach>
(...)opakować metodę w obiekt, żeby można ją było przekazać jako parametr.
</ciach>

Nie czepiam się interfejsu Runnable. Pytam się, dlaczego ktoś używa tego 
samego rozwiązania we własnym kodzie? Ponieważ uważam, że jakkolwiek 
pasuje do wątków, to inne jego zastosowania są wątpliwe (w sensie - da 
się to zrobić lepiej - być może będzie wolniejsze/używać więcej pamięci 
- ale rozwiązanie będzie bardziej przejrzyste).

Czy nie lepiej jest użyć wzorca projektowego 'Komenda', który robi 
bardzo podobną rzecz, ale bez wiązania jej z wątkami? Równie dobrym 
wyjściem jest Callable<T>. Oba nie wymagają rzutowania, w 
przeciwieństwie od Runnable ;-)

>
> Inne języki radzą sobie z tym problemem inaczej. Np. w C++ masz
> przeciążalny operator wywołania funkcji - bardzo zgrabna konstrukcja,
> bo składniowo unifikuje się z normalnymi funkcjami. I podobnie - można
> to użyć do wątków, ale nie trzeba.
> W Pythonie jest podobnie, ale w kontekście dynamicznym.
> W Adzie można by było użyć generyków z dowolnym przemapowaniem
> operacji w momencie jego konkretyzowania - czyli nie dość, że nie
> trzeba używać interfejsu, to nawet nazwa operacji nie musi być
> ustalona. Itd.
> Ogólnie - istnienie Runnable wynika z konstrukcji Javy, więc on sam
> niczemu nie jest winien.
> Po prostu język taki jak Java musi mieć interfejs taki jak Runnable.
>
Zgadza się. I teraz dyskutujemy jak go używać :-)

Pomimo tego, że możliwe jest, jak ktoś zaproponował, dziedziczenie po 
Thread, lub pisanie explicite "public interface MyFancyBussinesLogic 
extends Runnable", pytanie brzmi "po co tak robić?". Czy rzeczywiście 
klienci interfejsu MyFancyBussinesLogic muszą wiedzieć o wątkowości? A 
nawet jeśli, to dlaczego rozszerzać interfejs? Czy nie lepiej ukryć 
wątków wewnątrz implementacji?

Jeśli weźmiesz mój przykład z "private static class ThreadedAaa". 
Pominąłem tam oczywiście metody, które powodują, iż obiekty działają w 
osobnym wątku - skupiłem się na pokazaniu, iż "MyFancyBussinesLogic" nie 
musi "extends Runnable" i również można używać wątków :-)

>> Czy
>> widzisz jeszcze inne zastosowanie interfejsu Runnable, którego nie
>> sposób rozwiązać przy użyciu polimorfizmu?
>
> Interfejs Runnable (jak i każdy inny) opiera się na użyciu
> polimorfizmu, więc pytanie jest dziwne.
>

Nie. Sam napisałeś - znacznik. Więc Runnable, Serializable opierają się 
na polimorfizmie bardzo słabo...

Dość powiedzieć - dziedziczenie klasy, która jest 'Serializable' jest 
trudne. Musisz pamiętać, aby wszystkie klasy były odpowiednie - nie 
zawierały (agregowały) obiektów, które nie są Serializable.

Podobnie 'Runnable' - łącząc interfejs Runnable z Twoją logiką 
(interface MyFancyBussinesLogic extends Runnable) łączysz wątkowość _na 
zawsze_ z Twoją logiką - z każdą implementacją. I z każdą klasą potomną 
musisz pamiętać, że kod działa w wątku. Warto? Z drugiej strony możesz 
zdefiniować interfejs (MyFancyBussinesLogic) i dostarczyć jego 
implementację, która działa w wielu wątkach 
(ThreadedMyFancyBussinesLogic) i nie narzuca klasom dziedziczącym 
konieczności pamiętania o bezpieczeństwie wątkowym, zwalnianiu puli 
wątków, etc.

A dlaczego uważasz, że implementacja jednowątkowa jest zła tak bardzo, 
że z gruntu wykluczasz, iż będzie działać (extends Thread zmusza Cię do 
zapewnienia możliwości uruchomienia w osobnym wątku)? :P

Mam nadzieję, że przedstawiłem swój punkt widzenia :-)

Pozdrawiam.
keef