UML-Bild (Erkennung ob static o. nicht)

[ruuckiii]

Hallo Leute,

folgendes Anliegen:

Mein Dozent hat uns ein UML-Bild als Einstieg geschickt, womit wir schon mal die Methoden und co. implementieren sollen. Er gesagt, "alles was unterstrichen ist, muss mit static gemacht werden". Allerdings ist in dem UML-Bild irgendwie alles unterstrichen mit "rot und blau"...

Kann mir jemand bitte erklären - ob ich jetzt von der roten o. blauen Farbe "static" erkenne (siehe Bild-Upload)

Vielen Dank im Voraus!

LG

 

[mihe7]

Die letzten drei Methoden sind static.

 

[Robertop]

Diese roten gezackten Striche sind doch bestimmt erkannte Rechtschreibfehler. Was das blaue heißt weiß ich gerade nicht. Aber man erkennt ja, dass die unteren drei die einzigen Zeilen sind, die eine schwarze Unterstreichung haben.

 

[Jw456]

Das ist wohl mit Word geschrieben.

Rot Rechtschreibung
Blau Grammatik

 

[Blender3D]

Kann mir jemand bitte erklären - ob ich jetzt von der roten o. blauen Farbe "static" erkenne (siehe Bild-Upload)

Das solltest du ohne Unterstrich erkennen können.
Eine static Methode kann nicht auf die Daten des Objekts zugreifen.

 

[mrBrown]

Das solltest du ohne Unterstrich erkennen können.
Eine static Methode kann nicht auf die Daten des Objekts zugreifen.

Abgesehen von der sehr schwammigen Umschreibung stimmt das natürlich nicht, rein an den Methodendeklaration in einem UML-Diagram kann man nicht erkennen, worauf eine Methode zugreift, die Implementierung der Methode gibts ja da auch noch nicht.

 

[Blender3D]

Abgesehen von der sehr schwammigen Umschreibung stimmt das natürlich nicht, rein an den Methodendeklaration in einem UML-Diagram kann man nicht erkennen, worauf eine Methode zugreift, die Implementierung der Methode gibts ja da auch noch nicht.

Grundsätzlich richtige Aussage.
Jedoch wenn jemand bei folgenden Signaturen auf das Objekt zugreift, dann handelt es sich wohl um schlechten Programmierstil.

boolean vergleiche( Kreis k1, Kreis k2 ){}
boolean bestimmeKollision( Kreis k1, Kreis k2 ){}

Warum ?
zu 1) es sollen die zu übergebenden Kreise verglichen werden. --> ein Zugriff auf das Objekt ist nicht nötig
zu 2) es soll getestet werden ob die übergebenen Kreise kollidieren. --> ein Zugriff auf das Objekt ist nicht nötig
--> diese Methoden sollten unbedingt static sein. Bei einem Cotainer der 1000 Kreise beinhaltet, würden die Methoden unnötigerweise 1000 x vorhanden sein.

 

[temi]

Grundsätzlich richtige Aussage.
Jedoch wenn jemand bei folgenden Signaturen auf das Objekt zugreift, dann handelt es sich wohl um schlechten Programmierstil.

boolean vergleiche( Kreis k1, Kreis k2 ){}
boolean bestimmeKollision( Kreis k1, Kreis k2 ){}

Warum ?
zu 1) es sollen die zu übergebenden Kreise verglichen werden. --> ein Zugriff auf das Objekt ist nicht nötig
zu 2) es soll getestet werden ob die übergebenen Kreise kollidieren. --> ein Zugriff auf das Objekt ist nicht nötig
--> diese Methoden sollten unbedingt static sein. Bei einem Cotainer der 1000 Kreise beinhaltet, würden die Methoden unnötigerweise 1000 x vorhanden sein.

Muss nicht sein, z. B. Prüfe ob der eigene Kreis mit den beiden übergebenen Kreisen kollidiert. Warum auch immer diese Anforderung erforderlich sein sollte.

ei einem Cotainer der 1000 Kreise beinhaltet, würden die Methoden unnötigerweise 1000 x vorhanden sein.

Ich glaube das kann man so nicht stehen lassen. Ich bin jetzt kein Spezialist, was den Compiler angeht, aber das wird schon optimiert werden.

 

[Blender3D]

Muss nicht sein, z. B. Prüfe ob der eigene Kreis mit den beiden übergebenen Kreisen kollidiert. Warum auch immer diese Anforderung erforderlich sein sollte.

Du könntest auch sagen, dass beim Aufruf der Funktion eine Klassenvariable geändert wird.
Aber das wäre wie von mir oben bemerkt sehr schlechter Programmierstil. Das selbe gilt für deine Auslegung der Semantik der oben genannten Methode.

 

[mrBrown]

Warum ?
zu 1) es sollen die zu übergebenden Kreise verglichen werden. --> ein Zugriff auf das Objekt ist nicht nötig
zu 2) es soll getestet werden ob die übergebenen Kreise kollidieren. --> ein Zugriff auf das Objekt ist nicht nötig

Du vermutest einfach nur aufgrund der Signatur, dass es so sein könnte – das ist aber keinesfalls zwingen vorausgesetzt.

--> diese Methoden sollten unbedingt static sein. Bei einem Cotainer der 1000 Kreise beinhaltet, würden die Methoden unnötigerweise 1000 x vorhanden sein.

Ähm Nein, Methoden gibt es immer nur einmal, die existieren nicht "pro Objekt". Ob static oder nicht macht in dem Fall keinen Unterschied in Bezug auf Laufzeit und Speicherbedarf.

 

[temi]

Du könntest auch sagen, dass beim Aufruf der Funktion eine Klassenvariable geändert wird.
Aber das wäre wie von mir oben bemerkt sehr schlechter Programmierstil. Das selbe gilt für deine Auslegung der Semantik der oben genannten Methode

Wieso? Wenn das eine normale nicht statische Methode ist, spricht da nix dagegen.

 

[Blender3D]

Du vermutest einfach nur aufgrund der Signatur, dass es so sein könnte – das ist aber keinesfalls zwingen vorausgesetzt.

Ich habe nicht von zwingend gesprochen, sondern welche Art Methode eine solche Signatur erwartet.
Aber stelle dir selbst die Frage, wie du eine solche Signatur umsetzen würdest.

 

[Blender3D]

Wieso? Wenn das eine normale nicht statische Methode ist, spricht da nix dagegen.

Dafür spricht: Wenn ich 2 Kreise vergleichen möchte, muss ich kein Objekt erzeugen.
Aber noch weniger dafür.

 

[kneitzel]

--> diese Methoden sollten unbedingt static sein. Bei einem Cotainer der 1000 Kreise beinhaltet, würden die Methoden unnötigerweise 1000 x vorhanden sein.

Die Aussage verstehe ich nicht. Eine Methode, die nicht statisch ist, ist doch nicht mehrfach vorhanden im Speicher. Wie kommst Du zu so einer Aussage?

Und das, was da abgebildet ist, ist schlechter Programmierstil. So eine Methode macht man eben nicht statisch sondern es wird eine nicht statische Methode erstellt und die Methode wird auf dem ersten Parameter aufgerufen und der zweite Parameter ist dann der einzige Parameter. Und das ganze wäre dann ein Comparable<Kreis>.

 

[temi]

Dafür spricht: Wenn ich 2 Kreise vergleichen möchte, muss ich kein Objekt erzeugen.
Aber noch weniger dafür.

Ich habe auch davon gesprochen:

z. B. Prüfe ob der eigene Kreis mit den beiden übergebenen Kreisen kollidiert.

Da du auf meine Anmerkung geantwortet hast, bin ich davon ausgegangen, dass du dich auch darauf bezogen hast.

Aus der Methodensignatur lässt sich eben nicht ableiten, was die genaue Aufgabe der Methode ist.

 

[Blender3D]

Da du auf meine Anmerkung geantwortet hast, bin ich davon ausgegangen, dass du dich auch darauf bezogen hast.

Wenn so etwas skurriles dann eher so.

public boolean isCollision( Kreis [] k ){..}

Das hat den Vorteil, dass ich mit beliebig vielen Kreisen auf Kollision mit mindestens 1 Kreis teste.
Ist aber kein guter Stil, da ich nach einem positiven Aufruf nicht weiß welche Kreise von der Kollision betroffen sind.
Das könnte man dann so lösen

public Kreis[] dedectCollisionsWith( Kreis [] k ){..}[/CODE
Die betroffenen Kreis werden zurückgegeben.
Besser wäre eine Klassenmethode
[CODE=java]public boolean isCollision( Kreis k ){}

Die ist vielfältig einsetzbar z.B.

public static boolean isCollision( Kreis k1, Kreis k2 ){
    return k1.isCollision(k2);
}

oder falls man so etwas wirklich braucht

public static boolean isCollisionInArray(  Kreis k, Kreis[] kreise){
    for( int i= 0; i kreise.lenght; i++ ){
        if( k.isCollision(kreise[i]) )
            return true;       
    }
    return false;
}

..

 

[mihe7]

Es geht doch letztlich um das Principle of least astonishment:

Bei kreis1.vergleiche(kreis2, kreis3) wäre mein Erstaunen gleichermaßen hoch, ganz gleich, ob kreis1 nun kreis2 und kreis3 miteinander vergleicht oder sich selbst auch noch dazunimmt. Im ersten Fall würde es mich wundern, weil kreis1 hierfür nicht benötigt wird, im zweiten Fall, weil ich dann einen Methodennamen der Art vergleicheMit erwarten würde.

Kreis.vergleiche(kreis1, kreis2) ist zwar auch nicht das gelbe vom Ei, was jedoch die Funktion betrifft, so habe ich hier die klare Vorstellung, dass kreis1 und kreis2 miteinander verglichen werden.

Das geringste Erstaunen würde natürlich kreis1.vergleicheMit(kreis2) (Comparable-Interface) auslösen.

 

[temi]

Letztlich geht es darum, dass man es aus der Methodensignatur nicht eindeutig ermitteln kann, ob die Methode statisch ist oder nicht.

Natürlich hat @Blender3D damit Recht, dass vieles in den o. g. Beispiel auf eine statische Methode hindeutet, aber es muss halt nicht so sein, aus welchen kruden Gründen auch immer.

 

[mihe7]

Es geht im Thread m. E. um zwei verschiedene Dinge und ich würde mich so weit aus dem Fenster lehnen, dass bzgl. dieser beiden Punkte auch überwiegend Einigkeit herrscht:

1. Man kann anhand einer Methodensignatur nicht ermitteln, ob es sich um eine Klassen- oder Objektmethode handelt. Das ist völlig klar, kann aber eine wichtige Info für Anfänger sein, daher ist der Hinweis darauf auch völlig richtig.
2. Umgekehrt wäre es im konkreten Beispiel und unter Berücksichtigung dessen, dass man saubere Bezeichner möchte, durchaus eine Überraschung, wenn die vergleiche-Methode nicht statisch wäre. Die Signatur suggeriert, dass die Methode zwei gegebene Kreise miteinander vergleicht, wofür man keinen dritten Kreis benötigt, der den Vergleich durchführen müsste. Natürlich kann es "krude Gründe" geben, dass es sich tatsächlich anders verhält. Dann wäre aber höchstwahrscheinlich ein anderer Bezeichner besser gewesen, der diese Assoziation erst gar nicht entstehen lässt.