Mam w uogólnieniu coś takiego:
public class A extends Service {
...
class B extends BroadcastReceiver implements Runnable {
...
}
}
Mam też inną wersję:
public class A extends Service {
...
class B implements Runnable {
...
class C extends BroadcastReceiver {
...
}
}
}
Obie wersje wydają mi się nienajlepiej poukładane.
Teraz nie wiem czy lepiej rozbić to wszystko na 3 osobne klasy/pliki, czy nie. Jeśli miałbym rozbić, to musiałbym przekazać do BroadcastReceivera obiekt Service, abym w przypadku nadejścia komunikatu mógł wywołać odpowiednią metodę na tym serwisie. Podobnie z wydzieleniem implementacji Runnable, która potrzebuje wykorzystywać atrybuty Serwisu. Myślałem o MVC dla tego BroadcastReceivera (dokładniej wzorzec Obserwator: Serwis = obserwator, BroadcastReceiver = obserwowany), ale nie mogę jednocześnie rozszerzyć Observable i BroadcastReceiver.
Chcę to zrobić porządnie i SOLIDNIE, wg sprawdzonych technik, gdyż całość aplikacji jeszcze sporo urośnie.
W skrócie: czy lepiej mieć to "ubite" tak jak jest teraz, czy lepiej rozbić? A jeśli to drugie, to czy są jakieś przeciwwskazania do przesyłania obiektu Context/Service itp. do innych klas, aby te mogły (często) wpływać na działanie tychże usług.
Jeśli ktoś mógłby podzielić się swoimi doświadczeniami/spostrzeżeniami to byłbym wdzięczny 😃