Warum stellen wir keine Aufzählungen, abstrakten Klassen und Strukturen voran?

Die C # -Community hat das Präfix "I" so allgegenwärtig verwendet, um eine Schnittstelle zu kennzeichnen, dass selbst die unerfahrensten Programmierer wissen, dass sie es verwenden.

Warum stellen wir dann keine Aufzählungen, abstrakten Klassen oder Strukturen voran (möglicherweise mit "E", "A" bzw. "S")?

Wenn wir beispielsweise alle abstrakten Klassen mit einem "A" markieren würden, würde dies wertvolle Informationen über diesen Typ liefern, die zwar abgeleitet werden könnten, aber nicht sofort offensichtlich sind.

Bitte beachten Sie, dass ich mich nicht für diese Änderung einsetze, sondern nur zu verstehen versuche, warum wir die Dinge nicht so machen.

Dieser Thread antwortet, warum wir das Präfix "I" verwenden, antwortet jedoch nicht, warum wir keine anderen Präfixe verwenden.

Der Zweck der Namenskonvention für Schnittstellen besteht darin, eine schnelle Entscheidung zu treffen, wie die von Ihrer Klasse implementierte Schnittstelle aufgerufen werden soll. Wenn Sie eine haben Frobnicator, aber eine Schnittstelle zum Entkoppeln deklarieren müssen oder aus welchem ​​Grund auch immer, dann IFrobnicatorerfordert die Entscheidung, sie aufzurufen , keine bewussten Überlegungen, und das ist gut so.

Das gleiche Problem gilt nicht für die anderen Konstrukte, die Sie benennen. Aufzählungen und Strukturen sind nützlich, aber es ist nicht erforderlich, zusätzlich zum Namen selbst einen zweiten , kurzen, transparenten, offensichtlich verwandten Namen zu finden . Daher besteht kein Druck, ein 'E' auf den Namen einer Aufzählung oder Struktur zu setzen.

(Abstrakte Klassen ähneln Schnittstellen, da Sie eine zweite, konkrete Klasse bereitstellen müssen, um etwas zu erledigen. Daher haben sie möglicherweise die Konvention erhalten, mit 'A' zu beginnen, aber aus irgendeinem Grund haben sie dies nicht getan. Wenn Ich darf spekulieren, ich denke, dass 'Ich' als besonders enger Buchstabe etwas damit zu tun haben könnte.)

Ich denke, es wird nicht viel verwendet, weil:

• Meistens spielt es keine Rolle, ob es sich um eine Aufzählung, eine abstrakte Klasse oder eine Struktur handelt
• Wenn es wichtig ist, kann ich es wahrscheinlich an der Verwendung erkennen und es ansonsten ziemlich schnell herausfinden
• Wenn ich es als Enum, abstrakte Klasse oder Struktur ändere, muss ich es auch umbenennen
• Für Leute, die die Konvention nicht kennen, ist es reiner Lärm.
• Die Leute könnten die gesamte Idee einfach ablehnen, weil ihnen beigebracht wurde, die ungarische Notation nicht zu verwenden. Es gab und gibt Menschen, die sagen, Sie sollten die Hungarion-Notation nicht verwenden, ohne zwischen Apps Hungarian und Systems Hungarian zu unterscheiden. Eine nette Diskussion findet sich in dieser SO-Frage . Nicht nur die erste Antwort ist interessant, sondern es gibt auch großartige Antworten und Kommentare. Aus derselben Frage stammt dieser Artikel von Joel Spolsky (scrollen Sie zum Absatz "Ich bin Ungarn").

Kurzum: Im Allgemeinen summiert sich der Mehrwert nicht zu den Kosten.

Aus diesem letzten Punkt und einer Interpretation könnten Sie schließen. Systems Hungarian (Präfix-Typ) ist schlecht und sollte nicht verwendet werden. Apps Ungarisch (Präfix Art) hat es verwendet.

Wenn Sie Ihre Frage zurücknehmen, denke ich, dass Ihre vorgeschlagene Notation eine Form von Apps Ungarisch ist. Wenn Sie der Meinung sind, dass sich der Mehrwert zu den Kosten summiert und Sie ihn konsequent in Ihre Codebasis implementieren, ist dies in Ordnung. Da Sie dies jedoch pro Projekt berücksichtigen müssen, sollte dies keine allgemeine Regel sein.

Ich denke, die Leute haben bemerkt, dass es öfter für Schnittstellen wichtig war, und deshalb ist es eine allgemeine Regel für Schnittstellen geworden.

Nur ein (hoffentlich zutreffender) Gedanke:

Es gibt einen offensichtlichen Trend zur "Codierung an Schnittstellen" anstelle konkreter Klassen. "Heutzutage" scheint es fast vorteilhafter zu sein, eine Namenskonvention für die Klassen zu haben, wie sie mit einem 'C' zu beginnen, als den Buchstaben 'I' für die Schnittstelle zu haben.

Ich habe gerade ein Java-Projekt beendet, in dem alle Schnittstellen tatsächlich als Modell bezeichnet wurden. Ja, die Konvention für den Schnittstellennamen bestand darin, den Namen mit 'Modell' zu beenden ... und dann eine Art 'DataTransferObject / DTO' die Schnittstelle als implementieren zu lassen ::

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
}

während in C #

public interface ISomething{}

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

Ich verdrahte mein Gehirn neu, um diesen Schmerz aufrechtzuerhalten, aber ich kann sehen, wie es hilfreich sein kann, sich Gedanken über die Programmierung der Schnittstelle zu machen.