Ist dieser Code guter Code?

[Snape]

>Und ja diese Notation ergibt in Java keinen Sinn. Es ist besser auf diese Notation zu verzichten, denn sie hat mehr Probleme als Nutzeffekte.

>Beispiel:
>char iBlub;
>Was ist es nun? Integer oder Char? ;o)

Ein fehlerhafter/schlechter Gebrauch eines Präfixes.

>Das es ein char ist wußte ich eigentlich auch obwohl da gar kein Präfix steht ..

Woher?
Wenn Du mitten im Code auf blub stößt, weisst Du dann sofort, worum es sich handelt? Vor allem, wenn es fremder Code ist?

>Spätestens mit den Generics hat die ungarische Notation keine Daseinsberechtigung.

Geschmackssache, würde ich sagen.
Übrigens gibt es Projektleiter eines großen deutschen Automobilkonzerns, die auf eine Bezeichnung mit m_ bei Instanzvariablen bestehen.
m_i für int (oder m_n für int/long/double), m_c für ein Objekt einer anderen Klasse, m_str für String usw. Das mag dem einen oder anderen vielleicht sauer aufstoßen, ist aber nicht unbedingt von der Hand zu weisen. Die Unterscheidung zwischen Instanzvariablen und in Methoden deklarierten Variablen wird dadurch einfacher.

 

[Cybernd]

http://www.galileocomputing.de/openbook/javainsel3/javainsel_260003.htm

cybi

 

[Snape]

Original geschrieben von Cybernd
http://www.galileocomputing.de/openbook/javainsel3/javainsel_260003.htm

cybi

Das sind ja nur Vorschläge.
Und wie ich schon sagte, manches ist eben Geschmacksache.
Allerdings sind für mich - ebenso wie für viele andere auch - kryptische Abkürzungen bei Variablennamen und der Underscore ( _ ) als Präfix absolutes no-no. Ich muss zugeben, dass ich selbst in meinem eigenen OpenSource-Projekt Variablen mit gleich zwei _ gesehen habe - allerdings nicht von mir, sondern einem hardcore C/C++ Coder, der den Umstieg wohl nicht sonderlich mag...

 

[Cybernd]

Du solltest die Passage oberhalb durchlesen die erklärt weshalb die ungarische Notation in Java keinen Sinn ergibt.

cybi

 

[boelkstoff]

Nunja jeder kann es machen wie er es will,
aber gerade bei Projekten die der allgemeinheit zugänglich sind und von anderen gelesen werden sollen,
sollte (wenn nicht sogar muss) man sich an die Gegebenheiten der jeweiligen Programmiersprache halten.
Sonst macht das ganze keinen Sinn.

 

[Christian Fein]

Sorry aber die Ausführung der beiden Methoden in den Konstruktor zu legen
ist eher schlechtes als gutes Design.

Der Construktor sollte nur Methoden ausführen die für die initialisierung
der Klasse notwendig sind.
Der Construktor ist nicht unbedingt dazu da den Codeablauf gross
mitzubestimmmen, dafür sind public Methoden da.

Zum OOP Design kann mann nichts sagen weil mit einer Klasse da nichts zu
bewerten gibt. Wäre das Projekt grösser dann würde es natürlich kein Sinn
machen eine Klasse zu schaffen die 2 verschiedene Aufgaben löst (berechnung
+ Ausgabe)

Ungarische Notatition ist unter Java wirklich quatsch. Die meisten Systemklassen
instancen nenne ich genauso wie die Klasse, oder teile der Klasse sprich:
File file;
StringBuffer buffer;
Iterator iterator;

Genauso nenne ich instanzen meiner Klasse, wenn ich nicht gerade mit vielen Instanzen
arbeiten muss genauso. Nur bei Klassen bei denen es sinn macht sie spezifisch zu nennen
wähle ich einen Klassenfremden namen der aber auch auf die klasse rückschliessen lässt.
So ist klar das chrysler eine Instanz von Car ist.

 

[Snape]

>Sorry aber die Ausführung der beiden Methoden in den Konstruktor zu legen
ist eher schlechtes als gutes Design.

>Der Construktor sollte nur Methoden ausführen die für die initialisierung
der Klasse notwendig sind.
>Der Construktor ist nicht unbedingt dazu da den Codeablauf gross
mitzubestimmmen, dafür sind public Methoden da.

Korrekt. In diesem Fall als Start ausgehend von main() allerdings durchaus gängig und üblich. Meinetwegen kann man die beiden Methoden auch noch in eine init() auslagern und nur das init() in den Konstruktor legen. Kommt aber letzlich aufs gleiche heraus - in diesem konkreten Beispiel.

>Ungarische Notatition ist unter Java wirklich quatsch. Die meisten Systemklassen
instancen nenne ich genauso wie die Klasse, oder teile der Klasse sprich:
File file;
StringBuffer buffer;
Iterator iterator;

Das ist klar und sollte auch nicht anders verstanden werden. Meine Vorschläge wurden lediglich mit der ungarischen Notation in Verbindung gebracht.

 

[TomHH]

Nachfrage zum Verständnis...

Original geschrieben von Christian Fein
Sorry aber die Ausführung der beiden Methoden in den Konstruktor zu legen ist eher schlechtes als gutes Design.

Der Construktor sollte nur Methoden ausführen die für die initialisierung
der Klasse notwendig sind.
Der Construktor ist nicht unbedingt dazu da den Codeablauf gross
mitzubestimmmen, dafür sind public Methoden da.

<TOM>Heißt dies denn nun, dass es doch besser ist, die Methoden über das erzeugte Objekt aufzurufen oder wie ist das zu verstehen? <TOM />

Tom;-)
&nbsp;

 

[Snape]

Re: Nachfrage zum Verständnis...

Original geschrieben von TomHH
<TOM>Heißt dies denn nun, dass es doch besser ist, die Methoden über das erzeugte Objekt aufzurufen oder wie ist das zu verstehen? <TOM />

Tom;-)
&nbsp;

Im Prinzip schon, aber hier in einer Klasse ist das Jacke wie Hose. Prinzipiell gefällt mir persönlich (unnötiger) statischer Kontext nicht.

 

[TomHH]

Re: Re: Nachfrage zum Verständnis...

Original geschrieben von Snape Im Prinzip schon, aber hier in einer Klasse ist das Jacke wie Hose. Prinzipiell gefällt mir persönlich (unnötiger) statischer Kontext nicht.

<TOM>Noch ne Frage zu diesem "statisch". Das Komplement wäre dann ja wohl dynamisch? Was ist denn der statische Anteil hier an der konkreten Vorgehensweise mit dem Methoden-Aufruf durch das Objekt bzw. eben nicht und per Konstruktor?<TOM />
&nbsp;