4. Wie gleich ist equals bei eigenen Klassenobjekten?

Wie gleich ist equals bei eigenen Klassenobjekten?

  • ?

    Hallo,

    folgender Beispiel code:

    var einkaufer1 = new Einkaufer();
einkaufer1.Name = "Bla1";
var einkaufer2 = new Einkaufer();
einkaufer2.Name = "Bla2";

var myHashSet = new HashSet<Einkaufer>();

myHashSet.Add(einkaufer1);
myHashSet.Add(einkaufer2);

    Frage: Werden beide Objekte (einkaufer1 , einkaufer2) hinzugefügt in das HashSet, weil beide Objekte unterschiedlich sind bzw. die property Name.

    0
  • F

    Sie werden hinzugefügt weil es Unterschiedliche Objekte vom Typ "Einkäufer" sind.
    Ich versteh grad nicht worauf du hinaus willst?

    0
  • E

    nur so als erwaehnung - MS meint das es besser ist nicht viel des "var" zu verwenden
    wenn du das objekt kennst - nimm es auch

    am sonsten muss ich meinem vorredner zustimmen - du erstellst zwei objekte - also sind die nicht das selbe objekt

    0
  • F

    nur so als erwaehnung - MS meint das es besser ist nicht viel des "var" zu verwenden

    Das klingt interessant, hast du einen Link wo man sich das durchlesen kann? Also pro und Contras?Auf jedenfall hast du Recht, wenn man das Objekt kennt, sollte man auch das richtige nehmen,seh ich auch so.

    0
  • ?

    Mr Evil schrieb:

    nur so als erwaehnung - MS meint das es besser ist nicht viel des "var" zu verwenden
    wenn du das objekt kennst - nimm es auch

    Wieso das denn?
    Wenn ich solchen Code habe

    var einkaufer1 = new Einkaufer();
var einkaufer2 = new Einkaufer();
var myHashSet = new HashSet<Einkaufer>();

    wieso soll ich dann pro Zeile zweimal den Typnamen schreiben? Redundanz ftw? var macht hier perfekten Sinn.

    0
  • F

    neh schrieb:

    Mr Evil schrieb:

    nur so als erwaehnung - MS meint das es besser ist nicht viel des "var" zu verwenden
    wenn du das objekt kennst - nimm es auch

    Wieso das denn?
    Wenn ich solchen Code habe

    var einkaufer1 = new Einkaufer();
var einkaufer2 = new Einkaufer();
var myHashSet = new HashSet<Einkaufer>();

    wieso soll ich dann pro Zeile zweimal den Typnamen schreiben? Redundanz ftw? var macht hier perfekten Sinn.

    Man könnte darüber jetzt wieder eine Grundsatzdiskussion starten, das es besser zu lesen sei, und dies und das, was weiß ich, hast du feste Fakten WARUM es besser ist?!

    0
  • ?

    Ich kenne den Typen, der Compiler kennt ihn, also muss ich den Code nicht mit redundanten Typinformationen zumüllen.

    var result = myObject.GetMeSomething();

    Hier kann man sich streiten, ob man hier lieber nicht auf var verzichtet, weil der Typ nicht direkt ersichtlich ist. Ich würde hier wohl auch in den meisten Fällen den Typen explizit angeben.

    Aber bei solchen Sachen

    var instance = new MyClass();

    ist es doch total unsinnig, statt var den Typen nochmals hinzuschreiben. Man sieht ja gleich, was gemeint ist.

    0
  • W

    neh schrieb:

    Ich kenne den Typen, der Compiler kennt ihn, also muss ich den Code nicht mit redundanten Typinformationen zumüllen.

    Es sei denn das Objekt ist polymorph.

    0
  • E

    hier steht einiges dazu - vor allem die sachen die man bei var beachten muss - was geht und was nicht:
    http://msdn.microsoft.com/de-de/library/bb384061.aspx

    MSDN schrieb:

    Die folgenden Beschränkungen gelten für implizit typisierte Variablendeklarationen:
    - var kann nur verwendet werden, wenn eine lokale Variable in der gleichen Anweisung deklariert und initialisiert wird. Die Variable kann nicht mit NULL oder einer Methodengruppe bzw. einer anonymen Funktion initialisiert werden.
    - var kann nicht für Felder im Klassengültigkeitsbereich verwendet werden.
    - Variablen, die mit var deklariert werden, können nicht im Initialisierungsausdruck verwendet werden. Anders ausgedrückt, ist der Ausdruck int i = (i = 20); gültig, während der Ausdruck var i = (i = 20); einen Kompilierungsfehler verursacht.
    - Mehrere implizit typisierte Variablen können nicht in der gleichen Anweisung initialisiert werden.
    - Wenn sich ein Typ mit der Bezeichnung var im Bereich befindet, wird das var-Schlüsselwort zu diesem Typnamen aufgelöst und nicht als Teil einer implizit typisierten lokalen Variablendeklaration aufgefasst.

    generll heisst es:

    Der Einsatz von var kompliziert jedoch potenziell Ihren Code, sodass andere Entwickler ihn nur schwer nachvollziehen können. Aus diesem Grund wird in der C#-Dokumentation var im Allgemeinen nur verwendet, wenn es erforderlich ist.

    ich schreibe mein code immer das auch andere es super verstehen - und mit einer richtigen IDE braucht man nie wirklich viel tippen
    wenn wenn du

    var bla = new MeineKlasse();
    schreibst, musst du "MeineKlasse()" explizit tippen
    wenn du aber
    MeineKlasse bla = new MeineKlasse();
    machen moechtest brauchst du es auch nur einmal eingeben am anfang, direkt nach dem new kann man es mit enter automatisch einsetzen lassen
    die redudanz des tippens ist also kein argument

    ich selber finde "var" eher stoerend als sinnvoll - daher verwend ich das auch nie (hab derzeit auch keine linq anweisung am laufen wo ich var verwenden musste)
    einige sagen ja auch das es dann einfacher wenn man typen aendert, zb den rueckgabewert von:
    var data = GetData("bla");
    ..

    da halte ich aber gegen und sage - wenn man ein typen aendert - sollte man beim refactor vorgang auch diese methode ueberpruefen ob da noch etwas zu tun ist

    wenn da zb nur data.Name verwendet wird - und das neue objekt hat zufaellig auch ein Name property - schluckts der compiler, aber zur laufzeit hat man eventuell dann ein problem, da die funktion haette geaendert werden muessen

    ich find also das var eher schneller fehler verursachen kann - sei es durch die handhabe oder wie im beispiel
    wenn man ein var hat - muss man immer erst irgendwie nachsehen was das fuer ein objekt ist - je nachdem wo es her kommt - var verkompliziert das ganze nur

    btw - wird etwas offtopic denk ich #gg

    //dazuedit - die ms empfehlung find ich grad nicht - ich habs hier aus nem buch

    0
Anmelden zum Antworten