Warum Präfix C# - interface-Namen mit einem "I"

Was ist die Logik hinter dieser Konvention?

Sehe ich keinen Vorteil. Das zusätzliche Präfix nur verpestet die API.

Mein denken ist inline mit Konrad ' s Antwort diesem Zusammenhang Frage; der gewählte Antwort von denen ist meist das, was ich Frage für hier.

Ich sehe zwei Stimmen zu schließen---aber ich bin nicht überzeugt, es ist wirklich genau das doppelte von dem verlangen nach alternativen. Wenn jemand mich überzeugen, werde ich die Abstimmung zu schließen. (Hinterlassen Sie bitte einen Kommentar.)
Nicht dupliziert, und tatsächlich eine gute Frage.
Nicht ein Duplikat ist, doch Jon Limjap scheint anders zu denken. Was kann ich tun?
Es war nicht nur Jon Limjap. 3 Leute haben sich für ihn zu Stimmen, er war nur in der 3rd-person, dies zu tun.
Vielen Dank für die Klarstellung. Ist es möglich, darüber abzustimmen, unclose es? Wäre hilfreich, wenn ein link, der das vermeintliche Duplikat wurde zur Verfügung gestellt durch die Wähler.
Ja, die Benutzer können abstimmen, zu öffnen. Es dauert 3 Benutzer Stimmen zu erneut eine Frage. Derzeit ein Benutzer hat gewählt, so zu tun, also braucht es zwei mehr.
Sie haben auch eine bestimmte rep Niveau zu tun, Niveau sollte in die FAQ (3k rep)

InformationsquelleAutor i3ensays | 2009-01-13

c#interface naming-conventions

53

Seine das komplette Gegenteil, die Namenskonvention eindeutig identifiziert eine Schnittstelle.

Zum Beispiel, wenn Sie haben:
```
public class Dog : IPet, IMammal
{
    ....
```
Nur vom Lesen, kann ich sicher davon ausgehen, dass IPet und IMammal sind wahrscheinlich die Schnittstellen.

Den .NET CLR erlaubt einzelne Klasse die Vererbung. Also, wenn ich eine Basis Klasse..kann ich nur erbt eine Klasse von ihm. Ermöglicht das ändern der IPet-Schnittstelle, um eine Basis Klasse..unser Beispiel wird nun
```
public class Dog : Pet, IMammal
{
    ....
```
Ich bin Erben von der Pet-Klasse und der Umsetzung der IMammal-Schnittstelle.

Wenn wir es Taten, was Sie vorschlagen, und entfernt die Buchstaben "I" haben wir dies:
```
public class Dog : Pet, Mammal
{
    ....
```
Welches ist das Klasse ich bin mit Vererbung aus? Das ist die Schnittstelle, ich die Umsetzung? Es wird verwirrend, richtig? (Zur info..Sie soll die Basisklasse immer zuerst, so könnte man argumentieren, dass Punkt...aber wenn Sie sich streiten, entfernen Sie den Buchstaben I aus, indem interface-Namen, ich bezweifle, dass Sie zu Folgen, dass die Praxis so gut)

Wie Sie sehen können, dass die Namenskonvention leicht erzählt mir viel über mein Objekt, ohne dass ich das weiter untersuchen. Ich kann leicht sehen, was ich Erben vs, was ich die Umsetzung.
- Es macht Sinn. Also, in C# , Java "erweitert und implementiert" werden zusammen gemischt?
- Ich Folge der "Basisklasse immer zuerst die" Konvention, die Sie erwähnen. Dennoch, ich kann nicht Zustimmen mit Ihrer Forderung "Namenskonvention leicht erzählt mir viel über mein Objekt". Case in point, die Unterscheidung zwischen interface, abstrakte/konkrete Klasse, enum, struts, etc. nicht sinnvoll für mich, auf API-Ebene.
- Warum gehen wir nicht Präfix abstrakte/konkrete Typen mit "A"/"C", Aufzählungen mit "E", Strukturen mit "S", etc.?
- Ich benutze eine Programmierung "Umwelt", dass ist SO schrecklich, dass Methoden, Attribute und Objekte, muss vorangestellt werden "erfüllt, attr und obj" repectively. objEmployee.metUpdate( objOther.attrId ). Dies ist sehr gut lesbar und sehr klar, aber ich hasse es!!!
- Ich kann nicht sagen, ob Sie sind sarkastisch oder schwachsinnig. Ich glaube nicht, dass jeder vernünftige Programmierer würde Stimmen Sie für diejenigen verwendet.
- es klingt nicht wie es ist seine Wahl
- Dies ist die beste Antwort, aber die eigentlichen Gründe sind (nach Krzysztof Cwalina), dass "ich" verwendet wird, für historical reasons und (laut Brad Abrams), dass es eine clear recognition of the influence of COM (and Java) on the .NET Framework und die Entscheidung, es zu tragen, nach vorne war, weil so viele "early adopters" des .NET Framework were already familiar with COM. (Siehe diese Antwort für die ausführlichere Zitate. stackoverflow.com/questions/222457/...)
- Ich persönlich möchte, dass alle Schnittstellen sind mit dem Präfix "I". Es erlaubt mir, um sofort zu erkennen, eine Schnittstelle schnell.
- Es ist ziemlich ironisch, dass java eigentlich alles richtig gemacht haben. Nicht mehr sind die Schnittstellen mit dem Präfix "I", aber es ist eigentlich als eine SCHLECHTE Praxis. Siehe "Effective Java" von Joshua Bloch.
- "Base-class-first" ist nicht nur eine Konvention. Es ist erforderlich, durch den compiler: Base class 'xyz' must come before any interfaces. Dies sollte nicht so verstanden werden, dass ich dagegen bin mit "I" als Präfix. Unter anderem, es ist schön, eine visuelle Anzeige, wie die interface-y mein code ist oder nicht.
- visual "Indikatoren" sind eine Sache, die text-Editoren / IDEs machen das ganz gut (z.B. schriftart, Farbgebung, icons, etc.)
- Was dies nicht die Adresse ist die grundsätzliche Frage, warum tun Sie müssen identifizieren, eine Art als eine Schnittstelle, mehr als Sie brauchen, um zu identifizieren, ob es eine Klasse oder ein struct... oder ob Sie Abstrakt ist oder nicht... oder ob es enthält Beispiel-Mitglieder oder nur statische... ich denke, wir tun, aber ich bin mir nicht sicher, was die beste Antwort ist, warum ....
InformationsquelleAutor Bart Czernicki
31

Außerdem mag ich es, denn ich kann es Lesen als "ich-verb-Verhalten" wie in "ICanSave" oder "IDoDoubleEntry" etc...
- Die meisten sinnvolle Antwort, die ich gelesen habe noch.
- IEnumerable - klingt wie ein Höhlenmensch zu reden. Ugg.
- Vielleicht ist der Präfix sollte 'Mir'.
- ja, es könnte argumentiert werden, dass das "Bin" impliziert ist.. "IAmEnumerable" wäre wohl klarer sein, albiet mehr.
- Haha, definitiv upvote für IDoDoubleEntry.
- Ich finde immer mein interface die Namen klingen ein bisschen wie lolcats. "ICanHasCheeseburger"
- Macht das nicht eigentlich gegen C#'s Namenskonventionen? ICanSave sollte ISaveble.
- Ich denke, es könnte sein, in eine sehr kleine Art und Weise, wie ein verb phrase ist nicht, natürlich, ein Adjektiv, aber die Bedeutung ist identisch. ISaveble oder I[Am]Saveble bedeutet dasselbe wie ICanSave. In der Tat, meine Art des Denkens über Schnittstellen, es ist näher an der realen Bedeutung. Schnittstellen sind Möglichkeiten, um zu deklarieren, um dem compiler, einen Typ (Klasse oder struct), implementiert eine bestimmte Gruppe von Verhaltensweisen, d.h., es zwingt den compiler zu verlangen, die der Typ implementiert das Verhalten in der Schnittstelle definiert. also, für mich, eine verb-phrase, mit der Erklärung, dass der Typ nicht etwas ist besser geeignet.
- Ich dachte nur, weil .NET Namen Ihrer Schnittstellen wie IClonable, IDisposable, und IComparable und nicht ICanClone, ICanDispose oder ICanCompare.
- Ja, Sie sind richtig. Die "standard" Namenskonventionen sagen, dass die interface-Namen sollten Substantive, Nominalphrasen oder (als eine sekundäre option), ein Adjektiv. Es erwähnt nicht die Verben oder verb-Phrasen. Ich denke, dass die verb-Satz-Konstruktion deutlicher drückt das Konzept der "Umsetzung einer Reihe von Verhalten".
InformationsquelleAutor Charles Bretana
24

Ich denke, dass die IInterface Namenskonvention ist albern. Es ist ein Beispiel die Ungarische notation, und ich schließe mich der Schule des Denkens, verachtet die Ungarische notation. Wenn Sie ein interface mit nur einer Implementierung, die den gleichen Namen hat, die Möglichkeit in Betracht ziehen, dass dies ein code smell.

Jedoch, ich noch verwenden es, weil in diesem Fall IInterface ist von Microsoft empfohlen, und "- standard ist besser als besser".
- Ich war nie ein fan von ungarischen, aber ich stieß auf diesen alten Joel Artikel vor kurzem, die erklärt, seine Herkunft und wie es wurde vielfach missverstanden - zumindest kann ich sehen, der Grund, warum Sie es jetzt! joelonsoftware.com/articles/Wrong.html
InformationsquelleAutor Sean Reilly
14

Warum ist das nicht eine Funktion der syntaktischen Hervorhebung, anstatt die Ungarische notation? Warum nicht die IDE nur Kursiv darstellen Bezeichner für interfaces, wenn es so wichtig zu unterscheiden zwischen Klassen und interfaces. Ich hasse setzen "" oder "m", bevor die Felder "C" vor den Klassen, etc. Schlimmer noch, es fördert die Programmierer schreiben wirklich schlechte APIs wie:
```
public class List : IList
```
statt einer vernünftigen:
```
public class LinkedList : List
public class ArrayList : List
public class HashList : List
```
Selbst .NET-Allgemeine Klasse Autoren fiel in diese Falle. Der name einer Klasse sollte NIEMALS der name der Schnittstelle, die nur mit dem "ich" entfernt. Der name der Klasse sollte immer dem Benutzer mitteilen, wie die Klasse unterscheidet sich von anderen Implementierungen des interface(s). Ich vote für dropping das dumme "ich" allein aus diesem Grund.

Auch, wenn ich intellisense verwenden, möchte ich der Gruppe Dinge, die durch den funktionalen Bereich, und nicht, ob es eine Klasse oder ein interface. Ich denke nie, "ich brauche ein interface, keine Klasse." Ich denke immer, "ich brauche etwas, dass X".
- Ich bin froh, dass ich bin nicht der einzige, der sieht, dass es auf diese Weise. Es scheint sicher, dass ich bin in der Minderheit. 4 Jahre später bin ich immer noch erstaunt, wie viele Leser schwören "Ihr macht es einfach zu identifizieren ein interface" und völlig vermissen den Punkt.
- Dies ist ein wirklich guter Punkt bei der Konzeption einer Schnittstelle mit Dehnbarkeit im Verstand, ist aber ein anderer Anwendungsfall der Abstraktion der Schnittstellen (C# und Java) ist rein für den nutzen der Entkopplung zu ermöglichen Spott von Abhängigkeiten, wo keine andere konkrete Implementierung der Schnittstelle wurde explizit "entworfen für'. So MyReallySpecificBusinessComponent und IMyReallySpecificBusinessComponent wäre Ok. Aber definitiv nicht List.
- Bedeutet das, dass Java es richtig?
InformationsquelleAutor Dan
11

Eigentlich finde ich es sinnvoll, zu vermeiden, benennen Auseinandersetzungen, könnte ich zum Beispiel erstellen Sie eine konkrete Klasse genannt Fred, die IFred
- Benennung Auseinandersetzungen werden vermieden, indem mithilfe sinnvolle/nützliche Namen. E. g. Fred extends Person implements Leben, Atmung und anderen Funktionen. Ohne mehr Kontext kann ich nicht sicher sagen, aber wenn Fred ist ein domain/model-Objekt, dass eine Schnittstelle für die ist es wahrscheinlich überflüssig ist.
InformationsquelleAutor Tim Jarvis
5

Ich immer dachte, es war lustig, die Verwendung von Verben für Verhaltens-Schnittstellen. Dies ist eine Abkehr von der Klasse naming convention von Hauptwörtern, sondern es ermöglicht auch die Klasse, um "sprechen" zu seinem Verhalten.
```
class Dog: IBark
```
Dies funktioniert nicht gut für strukturelle Schnittstellen wie WCF Schnittstellen, aber wir brauchen Sie nicht, um Spaß zu haben die ganze Zeit.

Ihre Frage zu beantworten, denken Sie an die I als "implementiert" So...
```
class DogDataService : Dog, IDataService
```
diese service-Klasse erbt von Dog und implementiert IDataService

Bin ich noch nicht wirklich, deine Frage zu beantworten, aber die I ist nützlich, weil Sie Namenskonflikte zwischen namespace, Klasse und Schnittstelle.
```
namespace DataService
interface DataService
class DataService: DataService
```
so dass wir am Ende mit
```
namespace DataServices
interface IDataService
class DataService : IDataService
```
Ich denke, in der Realität, es ist ein Vernunft-Konvention.
- +1 - Regel sprechen, ich denke, Namenskonventionen deuten auf eine Schwäche in der Entwicklung der Sprache (und das ist wohl hier der Fall), aber es ist nichtsdestotrotz wichtig, in der Lage sein, vermeiden Sie Kollisionen, wenn Sie verwenden möchten, dependency injection und mock-Kollaborateur Objekte. Es gibt wirklich keine alternative zu einer Namenskonvention, wenn Sie erstellen Schnittstellen für die domain-Objekte.
- /shrug ich benutze es für WCF-Dienste zu. Ich habe IServeData und ICanMakePayments für meine zwei Dienste.
- Ich glaube, Sie könnten die Anwendung der "jedes Objekt muss über eine Schnittstelle," anti-pattern. Sie sollten wahrscheinlich nicht schaffen Schnittstellen für domain-Objekte; Sie sind oft eine erwartete Teil der öffentlichen API.
InformationsquelleAutor MarkDav.is
4

Wenn man die zwei "best-practice-Aphorismen"

Klarheit ist König

und

Lärm ist schlecht

gibt es einen Konflikt zwischen diesen. Die Frage ist: Wann beginnt Klarheit geworden für ein Lärm?

Für mich ist es eher laut (aber ebenso klar) zu schreiben Person person = new PersonImpl() als IPerson person = new Person().
- Oder besser noch, Person p = new TallPerson(); aber in meinem Fall, die Person ist nicht wahrscheinlich, um eine Schnittstelle. Stattdessen ist es eine base geben, die TallPerson erstreckt, oder einen abstrakten Typ. In jedem Fall ist die "Schnittstelle" der Mensch ist impliziert durch seine öffentliche API. Ich verachte FooImpl() so viel wie "ifoo") vom.
InformationsquelleAutor FatAlbert
3

Es ist entweder das, oder fügen Sie "Impl", um die Implementierung der Schnittstelle (argh). Ich habe nicht ein problem mit dem "ich", es ist die einfachste und direkteste Namensgebung für eine Schnittstelle.
- Ich bin nicht einverstanden mit der "Impl" Vorschlag - es wäre Verschwendete Lärm genauso wie der "I" - Präfix. Eine Implementierung sollte benannt werden, mit deren Umsetzung im Auge. Zum Beispiel, eine Schnittstelle "Datenbank" umgesetzt werden könnten, mit "RelationalDatabase" und "InMemoryDatabase".
- Es ist eine Konvention, Sie sind nicht verpflichtet, zu Folgen, wenn es Ihnen nicht gefällt.
- Nicht darum, mich zu mögen. Ich bin fragend seinen Wert. Ich mag zu halten, um Konventionen nicht ausschließlich dem Willen der folgende Satz ist. Ich möchte verstehen, rational. Hoffentlich kann mir jemand artikulieren, der rational über die "er lässt Sie wissen, seine Schnittstelle" (was die IDE w/ pretty icons).
InformationsquelleAutor Otávio Décio
3

Den "ich" - convention zu sein scheint, eine alte Konvention, dass wäre nicht relevant heute. Aktuelle code-editor bietet viele Einblicke über die Art, die Sie verwenden, so zu streiten, dass Es einfacher ist, zu identifizieren, die Schnittstelle ist wie zu Fragen, für ein Namensraum-Präfix durch ein "N", weil Sie wollen sicher sein, dass Sie nicht zu verwechseln mit einer konkreten Klasse (Präfix mit einem "C"?).

Eines übereinkommens bedeutet nicht, dass Es eine gute Konvention. Manchmal ist Es nur, weil die Menschen bekommen, um es zu benutzen...

Nehmen Sie zum Beispiel die C# - Dokumentation-generator: Es kümmert sich nicht um ihn... wenn dein interface ist nicht das Präfix mit einem "ich" noch sehen Sie Ihre Schnittstelle in der interface-Teil Ihrer Dokumentation. Glaubst du wirklich, dass ein Präfix "I" für alle Ihre Schnittstellen im interface-Abschnitt der Dokumentation ist ein relevanter Informationen und helfen Ihnen, besser zu identifizieren, Schnittstellen?

InformationsquelleAutor Alexandre Mutel
2

Macht es leicht erkennbar als eine Schnittstelle.
- Ich sehe keinen direkten Wert in der Unterscheidung zwischen Schnittstellen und Implementierungen. Weitere Ausarbeitung helfen könnten.
- Zu mir, zu vermieten, Umsetzung bedeutet eine Klasse, die sollten nach Maßgabe der logische Entität/ Objekt-Semantik, in der Erwägung, dass-Schnittstelle bedeutet, dass das Verhalten oder den Vertrag, die sollte organisiert nach logischen Gruppen von verbundenen Verhaltensweisen.
InformationsquelleAutor scottm
2

Die Notwendigkeit, zu unterscheiden zwischen einem interface und einer Klasse tatsächlich gibt ein Designfehler. In eine gut gestaltete Anwendung, es wird immer klar sein. Eine Unterklasse sollte immer eine Spezialisierung und Klassen können nur spezialisiert auf ein Thema, nie mehr.

Einer Klasse sollte aus einem einzigen Grund für die Existenz. Es sollte niemals erforderlich, um sekundäre Funktionen in einer Basisklasse. E. g.:
```
public class XmlConfigurationFile : ConfigurationFile, IDisposable
{
}

public class YamlConfigurationFile : ConfigurationFile, IDisposable
{
}
```
Die erste ist eine Konfigurationsdatei, die sich in Xml -, das zweite ist spezialisiert auf Yaml. Auch diese sind Einweg, aber das spielt keine Rolle, so viel. Sie nicht erstellen Sie diese beiden Klassen, da der eine andere Entsorgung Prozesse.

Kontrastieren diese mit:
```
public class XmlConfigurationFile : IDisposable, ConfigurationFile
{
}
```
Dies wird Ihnen sagen, dass der wichtigste Zweck einer XmlConfigurationFile hat, ist, dass es Einweg. Sie können es verwenden, als eine Möglichkeit dar Konfigurationsdateien ist schön, aber ist zweitrangig.

Das problem beginnt, wenn Sie Klassen erstellen, die mehrere Gründe für seine Existenz:
```
public class MyConfigurationFile : XmlConfigurationFile, YamlConfigurationFile
{
}
```
Selbst wenn XmlConfigurationFile und YamlConfigurationFile hätte Schnittstellen, die es noch gibt schlechtes design. Wie können Sie Ihre Konfigurations-Datei werden Xml und Yaml zur gleichen Zeit?

Wenn Sie Lesen, durch die Beispiele gegeben (hier und anderswo), die Menschen immer kämpfen, um ein gutes Beispiel finden, wenn das I-Präfix Angelegenheiten. Eine der Antworten ist hier:
```
public class Dog : Pet, Mammal
{
}
```
Dies ist, wie diese Klasse Aussehen wird, eine Anwendung über Haustiere. Ein Hund ist Hauptzweck ist als spezialisierter Haustier, das Haustier-bezogene Dinge, nicht, dass es ein säugetier.
```
public class Dog : Mammal, Pet
{
}
```
Dies ist, wie die gleiche Klasse in einer Anwendung, die über Tier-Klassifizierungen. Es ist schön zu wissen, ein Hund ist ein Haustier, aber es ist Hauptzweck ist als spezialisierter säugetier, das säugetier-Verwandte Dinge.

Ich denke die Klassen sollten Ihnen sagen, die richtige Geschichte über die Architektur und die Domäne Ihrer Anwendung. Die eine Schnittstelle sein, die mit dem Präfix " I " ist eine technische Anforderung und hilft Ihnen nicht zu sagen, Ihre Anwendung Geschichte besser.

Sobald Sie zu schreiben beginnen, kleine, dedizierte, einzelne-Zweck-Klassen, die Notwendigkeit zu wissen, ob es implementiert oder erweitert wird automatisch verschwinden.

InformationsquelleAutor Jeroen
1

Namenskonventionen bieten den Vorteil, erzählen Sie etwas über das Objekt, bevor Sie es verwenden. Namenskonventionen wurden Häufig verwendet, für viele Jahre, gehen den ganzen Weg zurück zu fortran beharren darauf, dass integer-Werte beschränkt (wenn ich mich richtig erinnere), um Variablennamen wie "i" und "j".

Hungariation notation nahm Namenskonventionen auf eine ganz neue hässliche Stufe tha beschrieben die variable Art, ob oder nicht es war ein Zeiger, etc. Viele von uns, die ausgesetzt wurden, die zu viel code ist mit der ungarischen notation entwickelt, nervöse Zuckungen und verbalen stottert.

Präfix interface-Namen mit ich ist ein relativ low-impact -, Harmlose Art und Weise der Ermittlung dieses Objekt.
- Wie funktioniert die Ermittlung eines Typs wird eine Schnittstelle nutzen die API? (Ich verstehe den Unterschied zwischen Schnittstellen und Klassen).
InformationsquelleAutor Kluge
1

TL;DR - Extraktion interface IFoo aus class Foo ist üblich in SOLIDEN Entkopplung, insbesondere für Unit-Tests Zwecke

Mir die dual-Konvention der Klasse Foo Implementierung der Schnittstelle IFoo (vor allem, wenn beide in der gleichen assembly) vermittelt eine bestimmte Absicht, dass:
- - Kopplung eine Abhängigkeit zu einer Foo sollte immer indirekt sein, durch die entsprechenden IFoo - interface (und wahrscheinlich injiziert über einen IoC container)
- Der ursprünglichen Konstruktion der IFoo ist eine proprietäre, nicht-wiederverwendbare Schnittstelle, die speziell zu ermöglichen Klassen abhängig Foo zu verspotten, sich diese Abhängigkeit bei unit Tests.
- Darüber hinaus ein Leser braucht nicht zu folgern, zusätzliche Intelligenz in die Gestaltung der IFoo Schnittstelle
- Umgekehrt, wenn mehrere konkrete Umsetzung der Klassen von IFoo sind erforderlich, zu einem späteren Zeitpunkt, dass eine entsprechende interface-segregation-design müssen nachgerüstet werden, die in der Hierarchie.
Begründung

Um der Lage sein, zu Verspotten oder Stub, eine Klasse, eine allgemein akzeptierte best practice in Unit-Tests ist zu entkoppeln von Abhängigkeiten zwischen Schichten nur über Schnittstellen. Diese Schnittstelle Entkopplung wird auch getan werden, um Klassen, die sonst hatte nie eine design-Anforderung für polymorphicism (D. H. nur eine solche Umsetzung bestanden hätte, gäbe es nicht die Notwendigkeit für unit-Tests).

Als Folge der Umgestaltung und wiederverwertung von diesen Schnittstellen (z.B. die Interface Segregation Prinzip der SOLID) ist nicht Häufig angewendet, um zu solchen 'mockable' Schnittstellen - es ist oft eine 1:1 Korrelation zwischen den öffentlichen Methoden, Eigenschaften und Ereignisse einer 'mockable' Klasse (Foo) und seine entkoppelte Schnittstelle IFoo (ähnlich dem COM-ära automatische Schnittstellen in VB).

Tools wie VS und Resharper machen kann extrahieren solche öffentlichen Symbole aus einer Klasse in eine separate Schnittstelle trivial, wie ein nachträglicher Einfall.

Weiter, wenn wir Bedenken, dass Mocking-frameworks wie Moq, erlauben definition von Implementierungen der Schnittstelle on-the-fly, wir müssen nicht überflüssige Mühe, die Benennung der konkreten test-Doppel-Umsetzung Klasse.

InformationsquelleAutor StuartLC
0

Es ist einfach eine Namenskonvention, so dass jeder würde wissen, ob es ein interface oder sonst etwas, es ist nicht zwingend, noch durch den compiler, noch durch die IDE aber Alle Schnittstellen, die ich sah in meinem ganzen Leben beginnt mit dem Brief, den ich

InformationsquelleAutor Hannoun Yassir
0

Ich scheint die traditionellen Konventionen aus der ungarischen Notation.
Interface-Richtlinien Zur Benennung sagt "Präfix interface-Namen, die mit den Buchstaben I, um anzugeben, dass der Typ eine Schnittstelle."
Framework Design Guidelines auch sagt: "MACH Präfix interface-Namen, die mit den Buchstaben I, um anzugeben, dass der Typ eine Schnittstelle."

Es ist nur ein coding-Konvention, So ist es schwer zu bestimmen, gut oder schlecht.
Wichtige Dinge, ist die Konsistenz.

InformationsquelleAutor Namo
0

Erstens glaube ich voranstellen ich dann die Beschreibung falsch ist, weil es bedeutet, dass Implementierungen können eine kürzere Namen. IList (intf) -> Liste. Dies ist ein anti-pattern, wie wir alle wissen, wir sollten mit intf und wahrscheinlich nur konkrete Typen beim erstellen. Don ' T flame me dies ist eine Verallgemeinerung, aber die Prämisse ist intf impl nur selten. Die Umsetzung name sollte beschreiben, wie es die Umsetzung des intf oder was es tut. Denke intf List, LinkedList implementiert die Liste mit einer verlinkten Liste. Wer kümmert sich, wenn es länger als wir sollten mit Liste die meisten der Zeit. Wenn wir eine Klasse die viele intf wir sollten wohl nicht alle intf als die Schatten, die der eigentliche Zweck der Klasse. IN dem Fall, dass etwas entfernt werden, ohne die intf Sinn macht. ZB ppl nennen mich beim Namen, nicht die Person, Geschwister, Entwickler etc mit meinem Namen ist das beste, die meisten beschreibenden Namen. Ich nehme an, wenn eine Klasse impl eine einfache intf dann rufen Sie Default Intf das es auf ious dies ist die default-Implementierung des Intf.
Namen von Klassen sollten in das Ende sein, von Menschen lesbar und fast ein kurzer Satz beschreibt deren Zweck. Präfix-codes etc sind nicht toll, wie wir kommunizieren mit Worten, nicht codes. - Computer-t-interessieren, welche Klassen genannt werden, warum also bleibt, ist, dass wir die Dinge nennen, also die Namen helfen uns und unseren Kollegen.

InformationsquelleAutor mP.
-1

Wahrscheinlich sein, damit es leicht erkennbar in intellisense, da alle Schnittstellen zu Klumpen zusammen. Ähnlich wie ich Präfix alle meine UI-Steuerelemente mit btn, tb, lb. Wenn intellisense-kicks ist alles verklumpt zusammen in eine einfache Gruppe.
- Ich glaube die IDE kann "Klumpen" ohne Verwendung von Namenskonventionen.
InformationsquelleAutor Kwan Cheng
-1

Mit all der Argumente über die Namenskonventionen und geben die korrekten Namen für Variablen und Methoden, die tatsächlich beschreiben, was Sie tun...warum nicht einfach die Namen Ihrer interfaces (z.B. PetInterface, PlayerInterface, etc.) und tun, Weg mit dem Präfix "I" alle zusammen. Also, was Sie haben zu geben, eine zusätzliche 9 Buchstaben, zumindest das "ich" wird entfernt, und wir wissen, es ist nicht eine Klasse, weil es sagt "Schnittstelle".
- Dies ist eine schreckliche Idee. Warum nicht Namen Ihrer Klassen "DogClass"? Wenn jemand Tat dies in meinem code-Basis hat, wäre ich sehr verärgert. Es ist ein standard; verwenden Sie es.
InformationsquelleAutor Darren

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.