Dlaczego należy unikać dziedziczenia?

Pamiętam naukę VB4 i przeciąganie przycisku do formularza, dwukrotne kliknięcie tego przycisku i pisanie kodu w module obsługi zdarzeń, którym właśnie zostałem magicznie pobłogosławiony. Pochodząc z QBASIC byłem zachwycony „V” w „VB”, projektant wizualny był dosłownie najlepszą rzeczą od krojonego chleba.

Oczywiście możesz zrobić to wszystko programowo, ale magia „V” była tak pociągająca, że ​​po prostu przeciągnąłeś ten przycisk. Zachęcono nas do skorzystania z tej trasy.

Ale kilka lat temu zacząłem uczyć się o języku C # i frameworku .net i byłem zafascynowany tym, że wszystko, co wiedziałem, właśnie wyszło z okna. W VB6 dzieje się dużo magii, która jest całkowicie odsłonięta w .net: weźmy InitializeComponentsna przykład konstruktory i metodę. W tym ostatnim znajdziesz wszystkie wystąpienia sterowania, które przeciągnąłeś z przybornika, wszystkie zarejestrowane zdarzenia i właściwości ustawione w projektancie.

I w porządku ... tak myślę. Po prostu czuję, że nie mam „tego”, co się dzieje, ten kod, który mogę modyfikować tylko za pośrednictwem projektanta, denerwuje mnie. Za każdym razem, gdy kopiujesz przycisk „Ok” z jednej formy do drugiej (czasami wraz z jego bratem „Anuluj”), w rzeczywistości kopiujesz kod, a to grzech, prawda? OSUSZAJ, nie powtarzaj się, mówi papież .

Odkładając na bok religie i szkoły myślenia, z całej obiektywności, czy nie powinniśmy czerpać formy z form podstawowych, a przycisk „Ok” (i wszyscy jego przyjaciele) żyli w formie podstawowej? Coś takiego, FormBasez czego wywodzi się DialogFormBase; wszystkie klasy tworzone w mgnieniu oka ... przez wpisanie kodu. Przyciski są tworzone w zależności od sposobu utworzenia klasy (tj. Argument enum konstruktora określa, które przyciski mają zostać utworzone), elementy sterujące są rozmieszczone w układzie paneli podzielonych i paneli układu przepływu, wstrzykiwane do postaci jakoContentktóry pasuje do głównego panelu zawartości. Czy nie to robi ASP.net ze stronami wzorcowymi i symbolami zastępczymi treści? Uzyskałem formularz, gdy potrzebuję nowej „strony wzorcowej”, ale ta nowa „strona wzorcowa” nadal pochodzi z podstawowej klasy formularza, więc grafika jest spójna w całej aplikacji.

Dla mnie jest to o wiele więcej ponownego wykorzystania kodu niż cokolwiek innego, co kiedykolwiek zrobiłem z projektantem w WinForms, i nie było to nawet trudne, a kod nie jest zaśmiecony 200-liniową metodą, nad którą nie mam kontroli, mogę umieszczaj komentarze tam, gdzie lubię, nie zostaną one nadpisane przez projektanta. Myślę, że to tylko kwestia wzorców i architektury, co doprowadziło mnie do tego linku: Najlepszy projekt dla formularzy Windows, które będą miały wspólną funkcjonalność , gdzie zdałem sobie sprawę, że byłem na miejscu, z wyjątkiem odpowiedzi tam, sugeruje dokładnie to, co jestem robi, ale to doradzanie przeciwko formy dziedziczenia ponieważ rozważań projektantów. Tego nie rozumiem .z uwagi na względy struktury kodu, szczególnie w odniesieniu do dziedziczenia formy i kontroli, których nie widzę innego powodu, niż dobrze, że psuje projektanta .

Nie wszyscy możemy być po prostu leniwi, więc jakiej części mi brakuje?

Sprzeciwiam się tobie z innym paradygmatem: preferuj kompozycję zamiast dziedziczenia.

Nawet gdy zaczniesz pisać kod GUI ręcznie i użyjesz dziedziczenia do dzielenia się zachowaniem i obrazami między formularzami, napotkasz ten sam problem, co normalny projekt OOP. Powiedzmy, że masz DialogForm, który ma przyciski OK / Anuluj i GridForm, który ma siatkę. Wszystkie okna dialogowe pochodzą z DialogForm i wszystkie formularze za pomocą Grid z GridForm. A potem okazuje się, że chcesz mieć formę z obu. Jak byś to rozwiązał? Jeśli korzystasz z dziedziczenia formularzy, nie ma możliwości jego rozwiązania. Z drugiej strony, jeśli używasz UserControls, możesz po prostu umieścić GridControl w formularzu i gotowe. Nadal możesz używać projektanta z UserControls, więc nie musisz tracić czasu na pisanie żmudnego kodu GUI.

Wiele z tego wiąże się z wyborem stosu technologii.

WinForms i WPF mogą być platformami .NET UI, ale różnią się znacznie pod względem sposobu osiągnięcia celu końcowego. Niektóre paradygmaty poruszają się między technologiami w porządku, ale inne nie i nie powinieneś próbować narzucać paradygmatu tylko dlatego, że czujesz, że ma on istnieć w każdym frameworku. Istnieje powód, dla którego MVVM jest nastawiony na WPF / SL, a MVC to osobna koncepcja w ASP.NET od WebForms i tak dalej. Niektóre technologie działają lepiej w przypadku niektórych paradygmatów.

Należy pamiętać, że generowany kod powinien być ogólnie usuwany z obaw związanych z OSUSZANIEM. Chociaż ma zastosowanie w niektórych przypadkach, należy go zignorować. Koncepcje DRY powinny z pewnością pozostać przedmiotem zainteresowania poza warstwą prezentacji, ale w warstwie prezentacji kod generowany jest najczęściej produktem ubocznym środowiska, w którym pracujesz. Nie oznacza to, że nie możesz stosować zasad DRY w swoim podejściu, ale pozostać ostrożny. Czy możesz utworzyć formularz podstawowy i dziedziczyć po nim w nieskończoność? Tak. Czy możesz przeciągać i upuszczać komponenty na nowym formularzu za każdym razem w razie potrzeby? Tak. Skoncentruj się na celu końcowym, unikając potencjalnych wad, ułatwiając refaktoryzację w dół łańcucha dostaw i skalowalność, pracując w ramach wybranego stosu technologii.

Państwo może używać dziedziczenie dostarczenie prawidłowo ująć swoje pola i wypełnić odpowiednio. Jeśli chciałbyś użyć dziedziczenia, moją sugestią byłoby mieć formę podstawową i odpowiedni model dla tej formy, a dla każdej pochodnej wyprowadzić zarówno formę, jak i model.

O wiele lepszą alternatywą byłoby grupowanie powiązanych elementów sterujących w jeden lub więcej elementów sterujących UserControl. Potrzebujesz tylko odrobiny logiki, aby umieścić w nim odpowiednie dane.

Całkowicie zgadzam się z Masonem Wheelerem, chociaż może za trzy lata nawet on zmienił zdanie.

Próbuję poszukać alternatyw dla migracji z plików wykonywalnych Delphi do sieci.

Do tej pory decydowałem się na UNIGUI, ponieważ nadal mogę korzystać z dziedziczenia formularzy. Chciałbym, żeby Delphi miał Mixiny takie jak Dart, ponieważ pozwoliłoby mi to mieć mniej przodków. Ale czuję, że ludzie piszą o wiele więcej kodu w MVC niż w Visual Form Inheritance, ponieważ większość nawigacji, wywołuje reguły sprawdzania poprawności w module danych (applupdates), kryteria filtrowania sql, przeszukuje zestaw danych klienta, wszystko jest napisane w 5 może 6 Tworzą przodków.

Nawet „Z MVC łatwiej będzie ci zostawić Delphi w funkcji” dla mnie nie działa jako argument, ponieważ ludzie zaprosili OOP, wszystko to klasy, właściwości, metody. Potrzebuję więc tylko tłumacza. Naprawdę nie mógł znaleźć żadnej korzyści, może dla stron internetowych, które są znacznie mniej skomplikowane, ale zmieniają się w bazie Daily.