Statyczny provider. Pomysły na refactoring, wprowadzenie odpowiedniego wzorca

0

"[...] Statyczny konstruktor utworzę w edytorze. "
Analizuję i potencjalnie przeprowadzam refactoring takiego kilkutysięcznika i w nim znjaduje się taka (nie do końca) magiczna metoda, która tworzy instancje klasy za pomocą refleksji z parametrami podawanymi przez konstruktor.
Jest tam taki duży na 60 case-ów switch zależny od inta, który zwraca Type.
wszystkie te klasy dzidziczą po jakiejś bazowej i kazdej konstruktor przyjmuje ten sam, wielki jak Afryka obiekt udający DTO itd.

Mając w głowie jakieś marzenia o zwiększeniu pokrycia testami kodu oraz wprowadzeniu IoC, robię taki myślowy teardown.

private static Type GetConcreteExecutorType(int ClasstId)
        {
            switch (ClasstId)
            {
                case 1:
                    return typeof(ExecutableClass1);
                case 2:
                    return typeof(ExecutableClass2);
                case 3:
                    return typeof(ExecutableClass3);
                    ......

i tak do case: 63 ^~^ (dalej siedzi Activator.CreateInstance)

szukam współczesnego rozwiązania, które pozawoliłoby ten moment w kodzie wydzielić o osobnej klasy i oddzieliła interfejs od implementacji, bo jest to pod spodem mozliwe.
Na początku myślałem o fabryce abstrakcyjnej, no ale musiałbym mieć fabrykę per klasa. to byłby niezły overengeneering.
Kolejną opcją, jaka mi przyszła do głowy, to klasa Providera, która trochę działałaby podobnie, nie chciałbym działać na typach, tylko faktycznie pozyskać konkretną instancję klasy.

public class  ExecutableTypeProvider : IExecutableProvider
    {

        private readonly Interface _interfaceForSaving ;
        private readonly Interface _readerInterface;
        private readonly Interface _extServiceInterface;

        public ExecutableTypeProvider(Interface interfaceForSaving, Interface readerInterface, Interface extServiceInterface)
        {
            _interfaceForSaving = interfaceForSaving;
            _readerInterface = readerInterface;
            _extServiceInterface = extServiceInterface;
        }

        public IExecutable GetExecutableObject(int fxtTestId)
        {
            switch (fxtTestId)
            {
                case 1:
                    return new Executor1(_extServiceInterface);
                case 2:
                    return new Executor2(_readerInterface, _interfaceForSaving);
                case 3:
                    return new Executor3(_interfaceForSaving);

no i z założenia IExecutable posiada tylko jedną metodę Execute(ExecuteParameters params)

Myślałem też nad oznaczeniu kazdej takiej klasy atrybutem i rozwiązanie ich za pomocą contenera DI, skąd potrzebny Executor dostawałbym po Atrybucie przy pomocy refleksji (na blogu Seemana było kiedyś takie rozwiązanie), ale nigdzie nie widziałe mtego w praktyce.

Macie jakieś inne pomysły na taki case? :)
im bliżej rozwiązań typu SOLID tym byłoby fajniej. Fragmenty kodu powyższego są zmyślone, ale dokładnie oddają ideę sytuacji.

0

No ale ten Twój Provider to przecież jest zwykłe Factory. Tą fabrykę, jak i wszystkie jej zależności możesz zarejestrować w kontenerze IoC, a potem wstrzykiwać do klas, w których potrzeba wywołać GetExecutableObject. O ile nadal istnieje konieczność tworzenia obiektu na podstawie jakiegoś inta, bo jak nie, to prościej wstrzyknąć docelowe klasy.

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