Kiedy używać protected?

Czytałem że metody do podnoszenia zdarzeń powinny być protected virtual.

Taki przykład kodu:

public class NiewiadomoZaCoOdpowiada
    {
        public event Action QueueCleared;

        public virtual void ClearQueue()
        {
            queue.Clear();
            queueCleared();
        }

        protected virtual void queueCleared()
        {
            QueueCleared?.Invoke();
        }


        private Queue<string> queue;
    }

Jakby ktoś chciał nadpisać czyszczenie kolejki, to wtedy musiałby mieć dostęp do kolejki. Czyli prawie wszystko protected. Tak się robi?

Public - to co wystawiasz na świat, by przez to korzystać z funkcjonalności, private - niezmienna wyodrębniona część funkcjonalności, protected - wewnętrzna część implementacji, którą można wykorzystywać w obrębie klas potomnych., ale dalej nie można modyfikować w obrębie klas potomnych. Protected virtual - w czasie wykonywania programu będzie używana metoda, która nadpisuje tą (override trzeba dać) - ma to sens, jeśli chcesz zmieniać część implementacji - czyli daje Ci możliwość modyfikacji metod protected - przydaje się :)

Od Ciebie - albo raczej od kogoś kto odpowiada za projekt - zależy co chcemy móc potem rozszerzać, zmieniać i nadpisywać. Generalnie lubię korzystać z public i private, a protected- w moim wypadku przydaje się, gdy mam do czynienia z frameworkiem, bo tam są klasy, po których dziedziczę. Sam wolę unikać dziedziczenia gdzie to tylko sensowne.

No mnie też właśnie średnio odpowiada.
Można przecież na zasadzie wrappera dostosowywać, tylko że więcej roboty czasem.

Może nie w kontekście C#, ale ładnie opisane - http://blog.nightlynexus.com/public-is-the-only-worthwhile-visibility-modifier. Nie do końca zgadzam się z opinią o private, ale rozumiem, jeżeli pisze się dobrze zmodularyzowany kod.

A są jakieś konsekwencje, jakby praktycznie zawsze zamiast private stosować protected?
Wtedy można prawie że edytować skomplikowany kod :D Można naprawiać bugi, poprzez dziedziczenie. Haha.

@Szalony Orzeł bugi można "naprawiać" też jak wszystko jest private używając Reflection. Modyfikatory dostępu nie zmieniają zupełnie nic jeśli chodzi o działanie kodu. Jedyną zaletą jest to że łatwiej zaprojektować jest klasę którą się łatwo używać i która zmniejsza szansę na zrobienie bugów przez użytkowników Twojej klasy.

To że public to "wystawianie na świat" to nie do końca prawda. Jeśli masz jakieś zadanie, jakąś odpowiedzialność która ma być realizowana przez klasę to z reguły każda część jej interfejsu ma być public. Jeśli korzystasz z jakiejś klasy wbudowanej, to metody z których korzystasz są właśnie public.

Jeśli klasa ma metodę która nie należy do jej interfejsu - jest to po prostu jakaś metoda związana z implementacją, i żaden klient klasy nie powinien zależeć od takiej implementacji - wtedy taką metodę robi się private. Ma to swoje zalety, bo metody private można do woli refactorować, zmieniać i usuwać, i żadnego kod korzystającego z tej klasy nie trzeba będzie zmienić.

Jeśli natomiast z Twojej klasy coś ma dziedziczyć (albo jest to klasa abstrakcyjna, i coś ją implementuje), i ta dziedzicząca klasa chce korzystać z metody rodzica, która nie jest częścią interfejsu, to wtedy ona jest protected (bo gdyby była private to ta dziedzicząca klasa nie wiedziałaby o istnieniu takiej metody).

Innymi słowy:

• public - Jak ją zmienisz, to wszystko co korzysta z klasy będzie musiało być zmienione
• protected - Jak ją zmienisz, to tylko klasy dziedziczące będę musiały być zmienione
• private - Jak ją zmienisz, to nie ma to specjalnych konsekwencji.

Szalony Orzeł napisał(a):

A są jakieś konsekwencje, jakby praktycznie zawsze zamiast private stosować protected?

Niektórzy optują za takim podejściem, bo łatwiej zrobić wszystko protected od razu zamiast najpierw private, a potem zmieniać. W ten sposób można zmienić sobie całą implementację klasy bazowej w klasie dziedziczącej... pytanie tylko, czy w takiej sytuacji hierarchia ma w ogóle sens?