W jakich okolicznościach (scenariuszach użytkowania) zdecydowałbyś się napisać rozszerzenie, a nie podklasyfikować obiekt?

<pełne ujawnienie: Nie jestem pracownikiem MS; Nie znam osobiście Mitsu Furoty; Znam autora wspomnianej tutaj biblioteki Componax o otwartym kodzie źródłowym, ale nie mam z nim żadnych kontaktów biznesowych; Nie tworzę ani nie planuję tworzyć żadnego komercyjnego produktu wykorzystującego rozszerzenia: w sumie: ten post pochodzi z czystej ciekawości intelektualnej związanej z moją próbą (ciągłego) uświadamiania sobie „najlepszych praktyk”>

Uważam, że idea metod rozszerzeń jest „fajna” i oczywiście można robić z nimi „dalekie” rzeczy, jak w wielu przykładach, które można znaleźć w blogach Mitsu Furota (MS)tekst linku.

Osobisty przyjaciel napisał bibliotekę Componax o otwartym kodzie źródłowymtekst linkui jest tam kilka niezwykłych udogodnień; ale jest w pełni władcą swojej małej firmy z całkowitą kontrolą nad wytycznymi kodowymi, a każda linia kodu „przechodzi przez jego ręce”.

Chociaż jest to spekulacja z mojej strony: myślę / zgaduję, że inne problemy mogą wejść w grę w sytuacji średnich i dużych zespołów zajmujących się tworzeniem oprogramowania.

Patrząc na wytyczne MS natekst linku, znalazles :

Ogólnie rzecz biorąc, prawdopodobnie będziesz dzwonić metodami rozszerzeń znacznie częściej niż implementując własne. ... Ogólnie rzecz biorąc, zalecamy stosowanie metod rozszerzeń oszczędnie i tylko wtedy, gdy trzeba. Jeśli to możliwe, kod klienta, który musi rozszerzyć istniejący typ, powinien to zrobić, tworząc nowy typ wyprowadzony z istniejącego typu. Aby uzyskać więcej informacji, zobacz Dziedziczenie (Podręcznik programowania C #). ... Gdy kompilator napotka wywołanie metody, najpierw szuka dopasowania w metodach instancji typu. Jeśli nie zostanie znalezione żadne dopasowanie, będzie wyszukiwać dowolne metody rozszerzeń, które są zdefiniowane dla typu, i powiązać z pierwszą znalezioną metodą rozszerzenia.

I u panitekst linku :

Metody rozszerzeń nie zawierają żadnych konkretnych luk w zabezpieczeniach. Nigdy nie można ich używać do personifikacji istniejących metod typu, ponieważ wszystkie kolizje nazw są rozwiązywane na korzyść instancji lub metody statycznej zdefiniowanej przez sam typ. Metody rozszerzeń nie mogą uzyskać dostępu do żadnych prywatnych danych w klasie rozszerzonej.

Czynniki, które wydają mi się oczywiste, obejmują:

Zakładam, że nie napiszesz rozszerzenia, jeśli nie spodziewasz się, że będzie ono używane bardzo ogólnie i bardzo często. Z drugiej strony: czy nie możesz powiedzieć tego samego o subklasyfikacji?

Wiedząc, że możemy je skompilować w oddzielną bibliotekę DLL i dodać skompilowaną bibliotekę DLL, i odwołać się do niej, a następnie użyć rozszerzeń: jest „fajna”, ale robi to „zrównoważenie” kosztu związanego z kompilatorem, który najpierw musi sprawdzić jeśli metody instancji są zdefiniowane w sposób opisany powyżej. Lub koszt, w przypadku „konfliktu nazw”, użycia metod wywołania statycznego, aby upewnić się, że rozszerzenie jest wywoływane, a nie definicji instancji?

Jak częste używanie rozszerzeń wpłynęłoby na wydajność lub wykorzystanie pamięci w czasie wykonywania: nie mam pojęcia.

Dlatego doceniłbym twoje myśli lub wiedząc, jak / kiedy robisz lub nie używasz Rozszerzeń w porównaniu do podkategorii.

dzięki, Bill