Co jest użytecznością publicznych konstruktorów w klasach abstrakcyjnych w języku C#?

Question

Jeśli publiczny konstruktor w klasie abstrakcyjnej może być wywołany tylko przez ich klasy pochodne, powinien być funkcjonalnie równoważny chronionemu konstruktorowi. Dobrze?

Czy istnieje jakaś różnica w deklarowaniu publicznego konstruktora, zamiast chronionego, w klasie abstrakcyjnej? Do czego byś go użył? Dlaczego kompilator nie skarży się?

Dzięki

Answer 1

Absolutnie poprawne. Powinieneś faworyzować chroniony konstruktor.

EDYCJA: nie kompilator nie narzeka, ale narzędzia takie jak FxCop (& Analiza kodu) zrobić. Sądzę, że istnieją pewne dziwne sztuczki refleksyjne, które można zrobić z publicznymi konstruktorami na klasach abstrakcyjnych, ale z punktu widzenia, w którym tylko dostarczasz funkcjonalność klasy podstawowej innym programistom piszącym podklasy, trzymaj się chronionego konstruktora.

Answer 2

Tak, masz rację, praktycznie publiczny konstruktor nie ma zastosowania w klasie abscract, ponieważ nie możesz ich stworzyć.

Jednak kompilator nie będzie narzekał, ponieważ w ten sposób jest tyle bezużytecznych rzeczy, które możesz napisać w kontekście C#, ale nie będzie w stanie sprawdzić jego logicznego znaczenia, może tylko sprawdzić reguły parsowania, dla których jest ustawione .

I na pewno C# twórcy skupili się na tworzeniu gramatyki kompilacji (reguł), które są szkodliwe i naruszają język.

Answer 3

Masz rację. Publiczny konstruktor w klasie abstrakcyjnej jest funkcjonalnie równoważny z chronionym konstruktorem.

Wolę używać chronionego konstruktora w tym przypadku.

Chociaż prawdą jest, że kompilator nie będzie narzekał na to, że to zrobisz, kompilator będzie narzekał na próbę wygenerowania instancji klasy abstrakcyjnej. Visual Studio jest również wystarczająco inteligentny, aby nie dostarczać Intellisense, jeśli próbujesz utworzyć instancję klasy abstrakcyjnej.