Pytanie Czy możesz kiedykolwiek mieć zbyt wiele "chronionych wirtualnych" metod?


Oto pytanie dla osób z doświadczeniem w większych projektach i projektowaniu interfejsów API / framework.

Pracuję nad strukturą, która będzie używana przez wiele innych projektów w przyszłości, dlatego chcę, aby była ona dobra i rozszerzalna, ale jednocześnie musi być prosta i łatwa do zrozumienia.

Wiem, że wiele osób narzeka, że ​​platforma .NET zawiera za dużo zamkniętych klas i prywatnych członków. Czy powinienem unikać tej krytyki i otwierać wszystkie moje zajęcia z dużą ilością chronionych wirtualnych członków?

Czy to dobry pomysł, aby stworzyć jak najwięcej moich metod i właściwości chronione wirtualne jak to możliwe? W jakich sytuacjach można by uniknąć chronione wirtualne i uczynić członków prywatnymi.


15
2017-11-26 00:14


pochodzenie




Odpowiedzi:


Twoja klasa zawiera członków danych; metody, które wykonują podstawowe operacje wewnętrzne na tych elementach danych, w których funkcja nie powinna się zmieniać, powinny zawsze być prywatne. Dlatego metody, które wykonują podstawowe operacje z członkami danych, takie jak inicjowanie i przydzielanie, powinny być prywatne. W przeciwnym razie ryzykujesz, że klasy pochodne "drugiego rzędu" uzyskają niekompletny zestaw zachowań; pierwsi członkowie pochodnych mogą potencjalnie przedefiniować zachowanie klasy.

To wszystko mówi, myślę, że powinieneś bardzo ostrożnie określać metody jako "chronione wirtualne". Zachowałbym wielką ostrożność przy definiowaniu metod jako "chronionych wirtualnych", ponieważ nie tylko deklaruje to możliwość nadpisywanie funkcjonalności, ale w pewnym sensie definiowanie oczekiwanie nadpisanej funkcjonalności. To brzmi dla mnie jak nieokreślony zestaw zachowań, które można przesłonić; Wolałbym mieć wyraźnie zdefiniowany zestaw zachowań, które można zastąpić. Jeśli chcesz mieć bardzo duży zestaw zachowań zastępczych, wolę zajrzeć do programowania zorientowanego na aspekt, co pozwala na takie rzeczy w bardzo uporządkowany sposób.


9
2017-11-26 00:27





Po oznaczeniu metody za pomocą słowa "wirtualny" pozwalasz użytkownikom zmieniać sposób wykonywania elementów logicznych. Do wielu celów właśnie tego chcesz. Wierzę, że już to wiesz.

Jednak typy powinny być zaprojektowane dla tego rodzaju rozszerzenia. Musisz aktywnie wybierać metody, w których ma to sens, aby pozwolić użytkownikowi zmienić zachowanie. Jeśli po prostu uderzysz wirtualnie w całym miejscu, ryzykujesz zrujnowanie integralności tego typu, to naprawdę nie pomoże to użytkownikowi zrozumieć tego typu i możesz wprowadzić wiele błędów, w tym problemy związane z bezpieczeństwem.

Preferuję podejście konserwatywne. Zaznaczam wszystkie moje klasy z sealed chyba że specjalnie chcę włączyć dziedziczenie iw tych (niewielu) przypadkach tylko wprowadzam wymagane metody wirtualne.

Łatwo jest usunąć sealed tag, jeśli klasa musi zmienić, aby umożliwić dziedziczenie w przyszłości. Jeśli jednak chcesz zmienić klasę, która jest już używana jako klasa podstawowa dla innego typu, ryzykujesz przerwanie podklasy po zmianie klasy bazowej.


6
2017-11-26 09:53





Mój punkt widzenia to:

  • Jeśli możesz użytkownika events, jej preferowane protected metody.
  • Staraj się unikać protected metody jak to możliwe, jeśli nie jest to możliwe, musisz go użyć ;-).

2
2017-11-26 00:24





Wybór protected koniec private jest świadomą decyzją projektową. Stwierdzasz, że twoja klasa wyraźnie wspiera używanie tej funkcji, wraz z całym narzutem (wysiłek projektowy i wdrożeniowy), który mu towarzyszy. Używałbym tylko protected w sytuacjach, w których wiem, że jest to konieczne, głównie dlatego, że robię to sam. (Będziesz także znajdował komentarze od deweloperów BCL na tych samych zasadach, co powiedziałem.)

The virtual/nie-virtual Różnica w wydajności nie ma znaczenia na żadnej maszynie, która jest wystarczająco potężna, aby uruchomić środowisko .NET Framework.


1
2017-11-26 10:25





Nie, nie możesz mieć "za dużo". Jednak pomysł, że powinniśmy zrobić wszystko, co chronione zamiast prywatnie, lub uniknąć "zapieczętowanego" za wszelką cenę, jest po prostu głupi. Chciałbym, aby "metody pomocnicze" i wewnętrzne struktury danych były prywatne.


0
2017-11-26 00:18





Czy to dobry pomysł, aby stworzyć jak najwięcej moich metod i właściwości protected virtual jak to możliwe?

Nie tak dobry pomysł.

Chronione wirtualne metody zapewniają punkty rozszerzalności w strukturze podczas dodawania sprzężenia.

Istnieją bardziej obiecujące techniki zapewniające rozszerzalność: Kompozycja i Delegacja.


0
2017-08-09 18:55