Zdaję sobie sprawę, że istnieje wiele dyskusji na temat singletonów i dlaczego są one złe. Nie o to chodzi w tym pytaniu. Rozumiem wady singletonów.Chcę projektować alternatywę dla singletona
Mam scenariusz, w którym korzystanie z singleton jest łatwe i wydaje się mieć sens. Jednak chcę alternatywy, która pozwoli osiągnąć to, czego potrzebuję bez dużego nakładu pracy.
Nasza aplikacja została zaprojektowana jako klient, który zazwyczaj działa na laptopach w terenie i komunikuje się z serwerem zaplecza. Mamy pasek stanu na dole głównej aplikacji. Zawiera kilka obszarów tekstowych, które pokazują różne posągi i informacje, a także kilka ikon. Ikony zmieniają obraz, aby wskazać ich stan. Takich jak ikona GPS wskazująca, czy jest ona podłączona, czy nie, a także stan błędu.
Nasza główna klasa nosi nazwę MobileMain. Jest właścicielem obszaru paska stanu i odpowiada za jego utworzenie. Następnie mamy klasę StatusBarManager. StatusBarManager jest obecnie klasą statyczną, ale może być także pojedynczą. Oto początek zajęć.
public static class StatusBarManager
{
static ScreenStatusBar StatusBar;
/// <summary>
/// Creates the status bar that it manages and returns it.
/// </summary>
public static ScreenStatusBar CreateStatusBar()
{
StatusBar = new ScreenStatusBar();
return StatusBar;
}
MobileMain prosi StatusBarManager o StatusBar. Następnie wykorzystuje StatusBar. Żadne inne klasy nie widzą paska stanu, tylko StatusBarManager.
Aktualizacje paska stanu mogą pochodzić z praktycznie dowolnego miejsca w aplikacji. Istnieje około 20 klas, które mogą aktualizować obszary tekstu na pasku stanu i dodatkowe klasy, które aktualizują stany ikon.
Tylko jeden będzie StatusBar i jeden StatusBarManager.
Wszelkie sugestie dotyczące lepszej implementacji?
Niektóre myśli, że miałem:
Wykorzystaj StatusBarManager klasa instancji. W mojej klasie MobileMain przytrzymaj na statycznej publicznej instancji klasy StatusBarManager. Następnie, aby zaktualizować pasek statusu, można by nazwać MobileMain.StatusBarManager.SetInformationText lub inną metodą menedżera. StatusBarManager nie byłby singletonem, ale MobileMain tworzyłby tylko jego statyczną instancję. Problem polega na tym, że MobileMain ma teraz StatusBar i StatusBarManager, który zarządza właśnie StatusBar, który jest właścicielem. Nadal istnieje również globalnie dostępne statyczne wystąpienie do StatusBarManager, tylko inny właściciel.
Innym pomysłem było użycie czegoś takiego jak klasa EventEggregator. Nigdy jej nie użyłem, ale przeczytałem o nich. Domyślam się, że jest to klasa dostępna na całym świecie. W każdej klasie, która chce zaktualizować pasek stanu, będzie publikować zdarzenie StatusBarUpdate. StatusBarManager będzie jedyną klasą subskrybującą zdarzenie StatusBarUpdate i otrzymującą wszystkie powiadomienia. Czytałem jednak, że może to skończyć się przeciekami z tym podejściem, jeśli nie jesteś ostrożny z rezygnacją z subskrypcji zdarzeń podczas czyszczenia obiektów. Czy warto to podejście podejrzeć?
Ten wpis zawiera wiele pytań. Wybierz jeden na raz, aby uzyskać odpowiedź. – mydogisbox
Czy myślałeś o użyciu MEF lub Unity? Tam można zarejestrować pojedyncze wystąpienie dowolnego elementu za pomocą kontenera, aby można było go odzyskać gdzie indziej. – stijn
Dobra lektura związana z nazewnictwem StatusBarManager; http://www.codinghorror.com/blog/2006/03/i-shall-call-it-somethingmanager.html – Patrick