Wzorzec projektowy na sprawdzanie typu

0

Witam
Piszę oprogramowanie do wykonywania prostych operacji graficznych na obrazach. Mój problem wygląda następująco. Mam sobie interfejs IEdgeFilter, który zawiera deklaracje metod - właściwości, która zwraca czy informacje o tym czy możemy coś edytować (wielkości masek filtra etc., jakieś tam właściwości) oraz metodę rysującą krawędzie z oryginalnego obrazu. Mamy klasy implementujące ów interfejs

public interface IEdgeFilter 
{
       bool IsEditable { get;}
       Image DetectEdges(Image sourceImage, bool grayScale);
}

public SobelFilter : IEdgeFilter
{
       //...
}

public RobertsFilter : IEdgeFilter 
{
       //...
}

Następnie użytkownik po wybraniu odpowiedniego filtru wywołuje metodę ShowNextForm, która sprawdza czy coś można edytować, jeżeli tak otworzy nam okno do tego.

public void ShowNextForm(IEdgeFilter edgeFilter)
{
      if (edgeFilter.IsEditable)
      {
             FormFilterProperties form = new FormFilterProperties(this,edgeFilter);
             form.ShowDialog();
      }
}
 

Problem leży w tym, że chciałbym, aby to okno było stosunkowo uniwersalne dla różnych typów filtrów. Np. dla jednego filtru możemy zmienić wielkość maski, dla drugiego coś innego, dla trzeciego maskę i jakąś wartość. Zatem różne filtry mogą mieć różne właściwości. Jedyne co mi przychodzi do głowy to po prostu sprawdzenie jakiego typu jest obiekt tak jak poniżej.

 
public FormFilterProperties(FormMain form, IEdgeFilter)
{
       if(IEdgeFilter is CannyFilter)
       {
           //...
       }
       else if (IEdgeFilter is PrewittFilter)
       {
           //...
        }
}

To rozwiązanie osobiście mi się nie podoba, nie podoba mi się ta ifologia, jak będę miał 20 filtrów stworzę 20 ifów, czy tam instrukcji switch-case. Jak to rozwiązać, aby było to rozwiązanie elastyczne ?

3

Problem, o którym mówisz, nazywa się fachowo zasadą podstawienia Liskov.
Jednym z rozwiązań będzie na przykład utworzenie w interfejsie metody zwracającej listę wymaganych przez dany filtr opcji konfiguracyjnych.

0

Ja podobny problem rozwiązałem inaczej. Nieelegancko, ale prosto. Obiekt zwraca mi gotowe okno (okno odpowiedniego typu jest tworzone w konstruktorze obiektu). Wiem, że to nie jest eleganckie, ale działa i jest proste w implementacji. Wtedy nie wiedziałem, jak to zrobić inaczej. Po prawdzie teraz też nie wiem. Lista opcji konfiguracyjnych oprócz wartości, musiałaby zwracać jeszcze chyba nazwę wartości i coś jakby typ kontrolki, która ma być użyta do zmiany takiej wartości. Ewentualnie jeszcze wartości minimalne i maksymalne.

1
Juhas napisał(a):

Ja podobny problem rozwiązałem inaczej. Nieelegancko, ale prosto. Obiekt zwraca mi gotowe okno (okno odpowiedniego typu jest tworzone w konstruktorze obiektu). Wiem, że to nie jest eleganckie, ale działa i jest proste w implementacji.

Problem w tym rozwiązaniu jest taki, że okno jest tworzone w momencie kiedy tworzony jest obiekt, a nie kiedy faktycznie użytkownik potrzebuje otworzyć takie okno. Dwa jeżeli wiele obiektów będzie wykorzystywać to samo okno tworzymy zbędnie wiele instancji tych samych okien.

1 użytkowników online, w tym zalogowanych: 0, gości: 1