this verwenden oder nicht?

[Yanko]

Hallo zusammen,

Ich habe eine Frage zum Code-Stil. Und zwar sollte man this verwenden oder nicht? Oder auch nur manchmal?

Ich programmiere noch nicht allzulange in Java und hab bisher aus Gewohnheit immer this verwendet. Aber wenn ich mir den Sourcecode zu vorhanden Projekten anschaue sehe ich es ziehmlich selten. Gibt es irgendwelche Vorteile, ausgenommen den Schreibvorteil?

Danke schonmal,

Yanko

 

[SlaterB]

wenn du in der Forumsuche auf erweiterte Möglichkeiten gehst und nach 'this' im Titel suchst findest du das ein oder andere dazu,
einen alten Thread möchte ich verlinken:
http://www.java-forum.org/allgemeine-java-themen/138668-guter-programmierstil-immerverwenden.html

kann aber natürlich immer neu beredet werden

 

[Spin]

Hallo,

ich persönlich finde, dass man

this

an den Stellen verwenden sollte, wo dieses auch Sinn macht. Im Konstruktor beispielsweise, da die Argumente meist gleich heißen, wie die Properties der Klasse. Im Endeffekt sollte man das mit seinem Team absprechen und in Coding Guidelines festhalten, sodass alle Zusammen an einem Strang festhalten.

this

hilft einfach beim Lesen des Codes. Dem Compiler ist das wohl "Egal".

Da gibt es ganz andere Dinge, die du dir anschauen kannst
Best Practises Java

grüße spin

 

[OnDemand]

Es gehört eigentlich nur in den Konstruktor oder wenn man eine variable ändert die aber nicht den Wert in der Klassenvariable ändern soll, sondern in der aufgerufen Methode

 

[maki]

Da gibt es ganz andere Dinge, die du dir anschauen kannst
Best Practises Java

Von der ersten Regel in diesem Link sollte man tunlichst Abstand nehmen, ist nur nur falsch, sondern sehr falsch

 

[tröööt]

naja ... this kommt entweder in den konstruktor wenn die parameter und klassenmember den gleichen namen haben ... wenn man die aktuelle instanz an irgendwas übergeben will ... teilweise bei reflections ... und in getter/setter ...

an allen anderen stellen macht "this" auch meist keinen sinn

 

[Spin]

@maki

Lazy Loading ist auf jeden Fall nicht verkehrt.

public class LazyLogger {
    private final Logger logger;

    public LazyLogger(Logger logger) {
        if (logger == null) {
            throw new IllegalArgumentException("logger cannot be null");
        }
        this.logger = logger;
    }

    public static LazyLogger getLogger(String name) {
        Logger logger = Logger.getLogger(name);
        return new LazyLogger(logger);
    }

    ....

Ref: Logging in Java mit Hilfe von Lazy Loading

Nicht nur beim Logging oder auch bei Datenbank Connection usw wird es eingesetzt. Hibernate verwendet es auch an einigen Stellen.

public class Countries {
 
    private List countries;
     
    public List getCountries() {
         
        //initialize only when required
        if(null == countries) {
            countries = getArrayListFromDb()
        }
        return countries;
    }
}

Wenn die ArrayList einmalig gefüllt werden soll ... oder übersehe ich gerade ein schwerwiegendes Problem? ???:L

grüße spin

 

[SlaterB]

uiui, bei LazyLogger-Beispiel geht es gar nicht um Lazy Loading, jedenfalls nicht etwa bei der Initializierung des Loggers,
sondern um Logmeldungen nur dann wenn Logger auch eingeschaltet

zu Lazy Loading gibts wohl schon fertige Artikel
Lazy loading: The Good, The Bad, And The Evil Witch - Ayende @ Rahien
als besonders falsch sehe ich es nicht, nur nicht uneingeschränkt gut

 

[maki]

Das ist nix weiter als "premature optimization", macht den Code komplexer aber nciht unbedingt besser, und schafft viel Orte für Fehler, speziell Multithreadingfehler.

Warum sollte eine "DB zugriffsabstraktion" mit Lazy Init arbeiten?
Gebraucht wird das sowieso, mit Lazy Init verschiebt man nur den Zeitpunkt wann das passiert.

LazyLoading bei Hibernate bzw. ORM im allgemeinen macht Sinn, wird aber auch anders implementiert, ist ja auch was spezielles im Vergleich zu Lazy Init

Im allgemeinen kann man sagen:
Lazy Init ist nur in Ausnahmen gut.

als besonders falsch sehe ich es nicht, nur nicht uneingeschränkt gut

Die erste Regel in dem Link ist wirklich sehr sehr falsch, weil sie behauptet, Lazy Init wäre immer gut, aber genau das Gegenteil ist der Fall.

 

[SlaterB]

weil sie behauptet, Lazy Init wäre immer gut, aber genau das Gegenteil ist der Fall.

also 'immer schlecht'? warum das Extrem, damit machst du dich genauso einseitig wie der Artikel,
wobei du ja auch 'Lazy Init ist nur in Ausnahmen gut.' schreibst, genau

in der Collections-Klasse gibt es

    public static void shuffle(List<?> list) {
        if (r == null) {
            r = new Random();
        }
        shuffle(list, r);
    }
    private static Random r;

sollte Collections immer das Random initialisieren? schadet sicher nicht sehr, aber ist doch auch unnötig bei Mrd Programmen mit Collections-Verwendungen die an shuffle() nicht vorbeikommen,

dagegen ist

public static final List EMPTY_LIST = new EmptyList();

direkt deklariert, weil man darauf statisch zugreifen kann,
gäbe es nur die emptyList()-Methode wäre da vielleicht auch Lazy verwendet worden

ohne geht die Welt nicht unter, mit aber auch nicht

 

[maki]

also 'immer schlecht'?

Nö, gemeint war "manchmal gut", aber sicherlich nicht "immer schlecht"

gäbe es nur die emptyList()-Methode wäre da vielleicht auch Lazy verwendet worden

BEstimmt nicht.

Random "kostet" mehr als ein "normales" Objekt, da kann das Sinn ergeben.

Aber der Artikel liegt da imho ganz falsch:

Object creation in Java is one of the most expensive operation in terms of memory utilization and performance impact. It is thus advisable to create or initialize an object only when it is required in the code.

 

[Spin]

Da die Moderatoren selbst vom Thema abkommen, darf ich das vielleicht auch noch einmal tun

Und zwar wollte ich garnicht das Thema Lazy Loading ansprechen, sondern Lazy Init.
Some Examples.

Wenn ich richtig sehe, wurde auch dass eher angesprochen und nicht das Lazy Loading.
Ob dass nun an allen Stellen gut ist oder nicht lass ich die Profis entscheiden, ich persönlich habe mich ja Scala unterworfen und benutze dort das Keyword lazy für große Datenlisten.

Lazy Loading via lazy keyword

Zum Thema zurück:

Die Diskussion lieben leute und hier bei Stackoverflow durften sich auch wieder viele dazu äußern

Stack Overflow - When to use this keyword

grüße spin

 

[vanny]

ob man nun immer this verwendet, oder nur einsatzbedingt, finde ich garnicht so wichtig.
Viel wichtiger finde ich, dass es konsequent gemacht wird, sodass man weiß, wie man den code zu lesen hat.
Darum ist die einsatzbedingte Variante in meinen Augen die bessere. Es ist sehr schwehr, alle this auch wirkllich lückenlos einzusetzen.

Gruß Vanny

 

[SlaterB]

> Es ist sehr schwehr, alle this auch wirkllich lückenlos einzusetzen.

die IDE kann warnen, was es dann aber auch wieder zum Teil obsolet macht,
die IDE kann dann gleich Attribute gesondert darstellen und macht es ja auch

 

[Pentalon]

Von der ersten Regel in diesem Link sollte man tunlichst Abstand nehmen, ist nur nur falsch, sondern sehr falsch

Verstehe ich nicht :bahnhof:

Object creation in Java is one of the most expensive operation in terms of memory utilization and performance impact. It is thus advisable to create or initialize an object only when it is required in the code.

Diese Regel besagt doch nur, dass man keine Objekt erzeugen bzw. initialisieren soll, die man nicht braucht, weil es rechenintensiv ist. Vielleicht verstehe ich es aber auch falsch.

Pentalon

 

[maki]

Objekterzeugung ist nicht teuer in Java, wer was anderes behauptet, lebt noch in den 90er Jahren.

Wie gesagt, nicht nur falsch die 1. Regel, sondern sogar sehr falsch.

Den Rest hast du falsch verstanden

 

[SlaterB]

maki geht wie so oft den destruktiven Weg, einfach nur seine Meinung 'falsch' zu posten, fast ohne jede Erklärungen/ Links,
selbst bei Nachfragen

ein Problem, zumindest per Stichwort Multithreadingfehler angesprochen, ist der theoretische gleichzeitige Zugriff mehrerer Threads, welcher zu mehrfacher Initialisierung führt,
mehrere Objekte werden zurückgegeben/ verwendet, die gleich sein sollten,
Singleton ist da schnell im Spiel als ähnlicher Punkt (maki würde sagen 'einfach nur falsch'...),
je nach Kontext ist ja alles irgendwie ein kleines Singleton (die EINE Liste der UnterObjekte in Objekt X)

Double-checked locking and the Singleton pattern

 

[Tomate_Salat]

Ist es euch aufgefallen, dass weit über 50% der Beiträge dieses Themas OT sind ;-). Wenn ihr 2 (Slater oder maki) einen Moderator lieb fragt, splittet er das Thema bestimmt ab in ein separates .

Ich setze [c]this[/c] nur da ein wo es tatsächlich benötigt wird - und das ist eben wenn eine Variable überdeckt wird. Einfaches Beispiel:

private String name;
public void setName(final String name)
{
    this.name=name;
}

Als "markierung" würde ich es nicht nehmen. Memberfields werden von der IDE entsprechend hervorgehoben, sodass beim überfliegen der Scope der Variable klar ist.

 

[SlaterB]

es geht ja um 'eine Frage zum Code-Stil', da passen andere Fragen zum Code-Stil auch nicht ganz schlecht
würde Yanko mitposten/ sich beschweren, dann schon eher denkbar

 

[Tomate_Salat]

es geht ja um 'eine Frage zum Code-Stil'

eigentl. gehts um eine Frage zur Verwendung von [c]this[/c] ;-). Ich finde die Diskussion ja schon interessant, aber auf mich wirkt das schon wieder wie ein neues Thema. Müsst ihr wissen, wollte nur darauf hinweisen.opcorn:

 

[maki]

Wieso eigentlich soll die Diskussion hier offtopic sein?

Es wurde in diesem Thread ein Link mit angeblichen "Best Pratices" gepostet, da habe ich meine Meinung zu abgegeben, und andere auch.
Abgesehen davon haben wir schon ein paar Threads zum Thema this oder kein this, tut IMHO niemandem weh wenn wir die Diskussion hier etwas "ausweiten"

maki geht wie so oft den destruktiven Weg, einfach nur seine Meinung 'falsch' zu posten, fast ohne jede Erklärungen/ Links,
selbst bei Nachfragen

Wieso bin ich "destruktiv" SlaterB?
Weil nicht einfach nur so unpassende Links hier Poste?
LazyLoading ist nicht dasselbe wie LazyInit, der erste Google treffer ist nicht immer der beste.

Wenn Objekterzeugung in Java so teuer wär dass man sie immer und um jeden Preis vermeiden bzw. verschieben sollte, wäre dann nocht etwas grundlegendes falsch an Java, einer ObjektOrientierten Sprache?

IMHO der wichtigste Hinweis war eben "premature optimization", da soll man also wenn immer möglich auf LazyInit setzen um die Performance zu verbessern.. ohne zu wissen ob es überhaupt ein Performanceproblem gibt?
Dafür also den Code komplexer machen?
Hm...

Premature optimization is the root of all evil -- DonaldKnuth

Was sagt zB. ein Fowler dazu?
LazyInitialization

Remember that this is an optimization technique to help responsiveness in situations where a client doesn't need the lazy initialized value. As with any optimization you shouldn't use this technique unless you have a real performance problem to solve.

ein Problem, zumindest per Stichwort Multithreadingfehler angesprochen, ist der theoretische gleichzeitige Zugriff mehrerer Threads, welcher zu mehrfacher Initialisierung führt,
mehrere Objekte werden zurückgegeben/ verwendet, die gleich sein sollten,
Singleton ist da schnell im Spiel als ähnlicher Punkt (maki würde sagen 'einfach nur falsch'...),
je nach Kontext ist ja alles irgendwie ein kleines Singleton (die EINE Liste der UnterObjekte in Objekt X)

Double-checked locking and the Singleton pattern

Eine weitere (überflüssige) Singleton Diskussion wäre destruktiv
Fast so destruktiv, als würde man aus einem "'Lazy Init ist nur in Ausnahmen gut.'" ein "also 'immer schlecht'" zu machen, ist doch nur polarisierend ohne echten Nährwert..

 

[SlaterB]

maki geht wie so oft den destruktiven Weg, einfach nur seine Meinung 'falsch' zu posten, fast ohne jede Erklärungen/ Links,
selbst bei Nachfragen

Wieso bin ich "destruktiv" SlaterB?

den Satz direkt mit Begründung (eben im Gegensatz zu deinen bisherigen Postings) zu zitieren und die Frage zur Antwort neu zu stellen passt vielleicht in Jeopardy, aber sonst nicht grad sinnvoll
(das mit Jeopardy passt zu gut, kann ich nicht auslassen )

dass du jetzt ausführlicher antwortest ist eine Bestätigung von dir selber, vorher läßt du andere zappeln/ abprallen

Wenn Objekterzeugung in Java so teuer wär dass man sie immer und um jeden Preis vermeiden bzw. verschieben sollte, wäre dann nocht etwas grundlegendes falsch an Java, einer ObjektOrientierten Sprache?

alles ist immer teuer, jeder einzelne Tonziegel, jeder Kugelschreiber im Büro, jedes mg Zucker in der Quark-Fabrik,
alles wird millionenfach verwendet und dennoch Verschwendung wenn erkannt und leicht vermeidbar, abgestellt

der Hinweis, unnötige Objekterzeugung, vom leichten String über mittelschweren Random bis zur dicken DB-Connection, zu verhindern, ist grundsätzlich immer ein richtiger,
das ist in Java wie in jeder Programmiersprache und überall auf der Welt

selbstverständlich muss man Maß halten unter welchen Kosten und Mühen, alles zu optimieren ist falsch, richtig,
der Best Practice-Tipp in seiner Schärfe problematisch, grundsätzlich aber eine hilfreiche Möglichkeit

Fast so destruktiv, als würde man aus einem "'Lazy Init ist nur in Ausnahmen gut.'" ein "also 'immer schlecht'" zu machen, ist doch nur polarisierend ohne echten Nährwert..

du suchst dir dieses Zitat aus, aber wie soll man 'falsch', 'sehr falsch', 'genau das Gegenteil ist der Fall' interpretieren?
wenn du genau nachschaust wirst du auch sehen, dass ich nach nur zwei Minuten den anderen Satz auch gefunden hatte und direkt dazuschrieb

 

[Spin]

Hallo,

jetzt wirds sehr philosophisch und das ist das schöne an Entwickler. Jeder hat seinen eigenen Kopf und empfindet Programmiercode an manchen Stellen komplexer und performanter als ein anderer

Manch einer mag es wirklich viel Code zu schreiben und this an alles Stellen zu verwenden. Sobald man aber einen einzelnen erfahrenen Java-Programmierer fragt, dann wird schnell darauf hingewiesen das Keyword nur bei Übergabe zu verwenden.

Sobald man aber ein Team von Java Entwicklern fragt, die sich tausende Gedanken über Coding Conventions gemacht haben, dann kann es auch mal gut sein, dass this an allen Stellen oder garnicht verwendet werden sollte.

Das gleiche ist analog zu Best Practise. Ein einzelner entwicklet für sich einen guten Stil und meint an manchen Stellen im Code Patterns zu verwenden. Das Lazyloading ist meiner Meinung nach an manchen Stellen sehr sinnvoll an anderen Stellen widerum nicht. Wo es nun gut zu verwenden ist, meint jeder Entwickler immer am besten zu wissen

Stichwort ist hierbei: große, schwere objekte.

In PHP wird dazu das Proxy Pattern verwendet um Hintergrund beispielswiese ein fettes Bild Objekt oder DB Objekt zu laden. In Scala gibt es auch lazy loading proxy und in Java Lazy Loading

Das zu lazy init:

Remember that this is an optimization technique to help responsiveness in situations where a client doesn't need the lazy initialized value. As with any optimization you shouldn't use this technique unless you have a real performance problem to solve.

Persönlich programmiere ich immer gleich so, also würde man mit Performance Problemen später kämpfen müssen. In Java habe ich da leider nur mittelmässige Erfahrung was richtig high performance code angeht, aber in javascript sieht das anders aus. Die Browser interpretieren Javascript auf verschienste Weise und da kann man als Programmierer nur der HTML-Rendering-Engine WebKit vertrauen.

Jeder sollte also für sich entscheiden ob this oder irgendeine Best Practise gut oder nicht gut geeignet ist bzw. es in seinem Developer Team absprechen. Also Rote Linie kann man natürlich die Java Code Conventions benutzen, um gleich für den guten Berufseinstieg oder auch für die Zukunft besser geeignet zu sein.

PS: Einfach Scala verwenden für weniger Code Erweiterbarkeit und Paralelle Prozesse. Performance mhh ne - zwar ist der Code schön kurz, aber es werden viele viele Dinge im Hintergrund aufgerufen. (Memory Usage kann ziemlich immens sein ;( )


grüße spin

 

[fastjack]

Ein Anwtort, die ich hier bisher noch nicht gelesen habe: Egal was man selbst will, man sollte sich an die Conventions des jeweiligen Teams halten.