🚀 go-pugleaf

On Mar 25, 5:38 pm, keef <a...@a.com> wrote:
> Teraz pytanie:
> Jeśli wątek jest 'pracownikiem', który może zostać całkowicie ukryty -
> klasa używająca obiektu nawet nie musi wiedzieć, że za interfejsem chowa
> się wątek - to czy dobrze jest go 'łączyć' na stałe z klasą, w taki
> sposób, aby WSZYSCY widzieli, że tam jest osobny wątek?

Dobrze kombinujesz, to nie jest dobry pomysł, aby cokolwiek
dziedziczyć bez powodu.

> O co mi chodzi?
>
> Dlaczego pisać "extends Thread" lub nawet (w publicznej klasie)
> "implements Runnable", kiedy jest to szczegół implementacyjny, o którym
> klienci mogą nie wiedzieć?

Zauważ, że można zrobić "...extends Thread implements Cośtam..." i
dalej w świat "puścić" ten obiekt jako Cośtam. Nikt nie musi wiedzieć,
że to dziedziczy po Thread, będzie widać tylko metodę/metody z
Cośtam.

> Na poparcie moich wypocin, mogę przedstawić interfejs(y):
> 1. Executor (i ExecutorService), których zadaniem jest ukrywanie wątków

Ich zadaniem nie jest ukrycie wątków tylko odseparowanie spraw
związanaych z uruchamianiem wątków, zarządzeniem pulami wątków itp.
sprawami, a implementacją logiki, która będzie w tych wątkach
odpalana.

> 2. Interfejs Runnable, który powinien być używany ZAMIAST dziedziczenia
> po klasie Thread (próba rozdzielenia implementacji od specyfikacji)

Runnable nie powstał tylko po to, stosuje się go w wielu wielu wielu
miejscach, łącznie z tymi, które sam w swoim programie człowiek pisze
i od czasu gdy potrzebuje np. opakować metodę w obiekt, żeby można ją
było przekazać jako parametr.

> I teraz dochodzimy do zasadniczej kwestii. Jak wydzielić interfejs,
> który przedstawia postawiony problem w sposób niezależny od wątków? Da
> się? A jak się nie da, to pytanie brzmi dlaczego? Być może problem leży
> w koncepcji...

Nie zawsze można to zrobić, nie zawsze warto to robić, czasami dobrze
jest zostawić wolną rękę implementacjom - w końcu kto powiedział, że
jak implementujemy interfejs to nie możemy dodać coś od siebie i to
udokumentować. Nie zawsze jest tak, że różne implementacje tego samego
interfejsu są wzajemnie wymienne w naszym kodzie - i to dobrze. Weźmy
taki przykład: interfejs Map - możemy mieć obiekt HashMap, ale możemy
mieć też implementację zwracaną przez #Collections.synchronizedMap  -
każdy z nich możemy przedstawić jako Map, ale działają inaczej, a
interfejs Map nic na ten temat nie mówi. Z drugiej strony mamy
interfejs np. BlockingQueue, który jasno wspomina jak to wszystko
powinno działać biorąc pod uwagę wątki.