Dlaczego nie prefiksujemy Wyliczeń, Klas abstrakcyjnych i Struktur?

Społeczność C # tak wszechobecnie używa przedrostka „I”, aby wskazać interfejs, z którego mogą korzystać nawet najbardziej niedoświadczeni programiści.

Dlaczego więc nie poprzedzamy wyliczeń, klas abstrakcyjnych ani struktur (być może odpowiednio „E”, „A” i „S”)?

Na przykład, gdybyśmy oznaczyli wszystkie klasy abstrakcyjne znakiem „A”, dostarczyłoby to cennych informacji o tym typie, które, choć można by je wywnioskować, nie jest natychmiast oczywiste.

Pamiętaj, że nie jestem zwolennikiem tej zmiany, staram się jedynie zrozumieć, dlaczego nie robimy tego w ten sposób.

Wątek ten wyjaśnia, dlaczego używamy przedrostka „I”, ale nie odpowiada, dlaczego nie używamy innych przedrostków.

Celem konwencji nazewnictwa dla interfejsów jest zapewnienie szybkiej, pozbawionej mózgu decyzji o tym, jak nazwać interfejs implementowany przez twoją klasę. Jeśli masz Frobnicator, ale musisz zadeklarować interfejs do oddzielenia lub jakiegokolwiek innego powodu, to decyzja o wywołaniu go IFrobnicatornie wymaga świadomej przemyślenia, i to jest dobre.

Ten sam problem nie dotyczy innych nazwanych konstrukcji. Wyliczenia i struktury są użyteczne, ale nie jest konieczne znalezienie drugiej , krótkiej, przejrzystej, oczywiście pokrewnej nazwy oprócz samej nazwy. Dlatego nie ma presji, aby uderzyć literą „E” w nazwę wyliczenia lub struktury.

(Klasy abstrakcyjne są nieco podobne do interfejsów, ponieważ musisz zapewnić drugą, konkretną klasę, aby cokolwiek zrobić, więc mogliby uzyskać konwencję rozpoczynania od „A”, ale z jakiegokolwiek powodu nie. Mogę spekulować, myślę, że „ja” jest szczególnie wąską literą, może mieć z tym coś wspólnego.)

Myślę, że nie jest często używany, ponieważ:

• przez większość czasu nie ma to większego znaczenia, jeśli jest to wyliczenie, klasa abstrakcyjna lub struktura
• jeśli to działa, prawdopodobnie widzę to po użyciu, a poza tym szybko się dowiaduję
• jeśli zmienię to na wyliczenie, klasę abstrakcyjną lub strukturę, muszę również zmienić nazwę
• dla ludzi, którzy nie znają konwencji, jest to czysty hałas.
• ludzie mogą po prostu odrzucić cały pomysł, ponieważ nauczono ich nie używać notacji węgierskiej. Byli i nadal są ludzie, którzy twierdzą, że nie należy używać notacji Hungarion, bez rozróżnienia między aplikacjami węgierskimi i węgierskimi. Miłą dyskusję można znaleźć w tym pytaniu SO . Interesująca jest nie tylko pierwsza odpowiedź, ale także świetne odpowiedzi i komentarze. Z tego samego pytania pochodzi ten artykuł Joela Spolsky'ego (przewiń do akapitu „Jestem Węgry”)

w skrócie: Zasadniczo wartość dodana nie sumuje się z kosztem.

Z tego ostatniego punktu i pewnej interpretacji, którą można wyciągnąć. System węgierski (typ prefiksu) jest zły i nie należy go używać. Używa go węgierski Apps (rodzaj prefiksu).

Wracając do pytania, myślę, że proponowana notacja jest formą węgierskiego Apps. Jeśli uważasz, że wartość dodana sumuje się z kosztami i konsekwentnie wdrażasz ją w bazie kodu, jest w porządku. Ale ponieważ musisz to rozważyć w odniesieniu do poszczególnych projektów, nie powinna to być ogólna zasada.

Sądzę, że ludzie zauważyli, że ma to większe znaczenie dla interfejsów i dlatego stało się ogólną zasadą dla interfejsów.

Tylko (miejmy nadzieję) zastosowanie:

Istnieje wyraźna tendencja do „kodowania interfejsów”, a nie konkretnych klas. „W dzisiejszych czasach” wydaje się, że bardziej korzystne jest stosowanie konwencji nazewnictwa dla klas, na przykład rozpoczynanie ich od „C”, zamiast posiadania litery „I” dla interfejsu.

Właśnie zakończyłem projekt Java, w którym wszystkie interfejsy były faktycznie nazywane Modelami. Tak, konwencja nazw interfejsów polegała na zakończeniu nazwy na „Model” ... a następnie na implementacji interfejsu przez DataTransferObject / DTO :

public interface SomethingModel{
}

public class Something implements SomethingModel{
    //lets not line up braces and make it hard to read
    //at least it saves one line
}

podczas gdy w C #

public interface ISomething{}

public class SomethingModel : ISomething
{
   //i can read this
}

Przeprojektowując mój mózg, żeby nie doznał bólu, ale widzę, jak może pomóc myśleć o warunkach programowania interfejsu.