Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ich lerne in der Berufsschule Java und habe eine Frage zu UML-Diagrammen. Wir haben gelernt, dass wir Variablen, die folgendermassen notiert sind
Code:
+ name: String
trotz dem Plus-Zeichen nicht als public, sondern als private deklarieren und Getter und Setter benutzen müssen. Meine Frage ist nun, ob das wirklich so ist und wenn ja, wieso es so ist. Wäre es nicht einfacher, man würde im Diagramm ein Minus vor die Variable setzen und bei den Methoden noch die Getter und Setter auflisten?
Verstehe ich auch nicht, wenn + Public bedeutet, ist es public, ansonsten soll man es halt nicht mit + deklarieren, ansonsten verwirrt es nur. Frage doch mal, warum ihr das so machen sollt?
Nunja, ist vielleicht etwas philosophische Frage, aber davon ausgegangen, dass man immer und überall nur Getter und Setter anbietet - zumindest gegenüber Fremdklassen - kann man das sicherlich so lösen, um sich alle (unnötigen) Getter- und Setterdeklarationen zu sparen. Die Frage wär dann aber, was man macht, wenn die Sichtbarkeit dieser zwei Methoden unterschiedlich ist oder eine gänzlich fehlt (z.B. bei einer Collection nur mit Getter).
Da hast du recht, aber die Frage, die mich beschäftigt, ist folgende: Wieso soll ich im UML-Klassendiagramm eine Variable als public notieren, die aber im Programmcode als private deklariert wird? Das widerspricht doch bereits dem Sinn eines Klassendiagramms. Für mich ist es eine Falschinformation, und nichts anderes.
UMl ist zwar stark spezifiert wird aber immer schwamming angewendet, zumindest kene ich niemanden der das 1zu1 macht.
Denke wenn es sowohl public getter und setter gibt,ist das äquivalend dafür das die variable auch public sein könnte, spaart man sich halt die zwei getter hinzuschreiben. (wer hat schon lust 20 getter und setter zu schreiben bei größeren klassen?^^)
Ich habe da eine etwas andere Meinung als meine Vorposter. Auch wenn ein Klassendiagramm stark an Code erinert und auch wenn man als Java-Programmierer immer schon in Code denkt. Ein Klassendiagramm ist kein Code. Ich empfinde es nicht als Widerspruch, wenn eine Variable in UML als public notiert ist und sie in Java dann private mit gettern und settern gemacht wird. Denn das Diagramm stellt nur die Forderung auf, dass die Variable public zugreifbar sein muss. Wie das umgesetzt wird, ist Implementierungsdetail der jeweiligen Zielumgebung.
Ich habe da eine etwas andere Meinung als meine Vorposter. Auch wenn ein Klassendiagramm stark an Code erinert und auch wenn man als Java-Programmierer immer schon in Code denkt. Ein Klassendiagramm ist kein Code. Ich empfinde es nicht als Widerspruch, wenn eine Variable in UML als public notiert ist und sie in Java dann private mit gettern und settern gemacht wird. Denn das Diagramm stellt nur die Forderung auf, dass die Variable public zugreifbar sein muss. Wie das umgesetzt wird, ist Implementierungsdetail der jeweiligen Zielumgebung.
Zwar "nur" eine grafische Notation, an vielen Stellen auch schwammig definiert, aber manche Dinge sind ganz klar festgelegt (OCL zB., aber auch die Diagrammtypen und die Elemente darin).
Zu den festgelegten Dingen gehört nunmal, das ein [c]+[/c] in einem Klassendiagramm für "public" steht.
Wenn man meint da könnte man sonstwas hineininterpretieren dann ist das grundsätzlich richtig, man darf das dann nur nicht "UML Klassendiagramm" nennen
Danke erstmal für die zahlreichen Antworten. Ich bin auch der Meinung, das + sollte für public und nichts anderes verwendet werden, und die Diskussion hier hat mich darin nur bestärkt. Ich habe auch bei uns noch einige Java-Programmierer gefragt und die stimmen mir ebenfalls ohne Ausnahme zu.
Im Moment sind bei uns "leider" gerade Schulferien, aber danach werde ich unseren "Lehrer" mal drauf ansprechen. Er soll das Fach in Zukunft gefälligst korrekt unterrichten! ueh:
UML ist eine Sammlung verschiedener Modellierungstechniken, die einem gewissen Standart angelehnt sind.
In der Uni wurde bei Prüfungen von Softwaretechnik penibel drauf geachtet, dass wir uns an die UML-Standartisierung halten. Abweichungen von der UML-Norm wurden hart bestraft. private Variablen mit + zu Kennzeichnen ist schlichtweg falsch. Dafür wurden uns einige Punkte abgezogen in der Prüfung.
Dein Dozent sollte evtl. seine arbeitsweise überdenken. Sowas sollte man von anfang an richtig lernen.
Per Konvention macht man Variablen in Java nicht public.
Ist im UML Diagramm ein + davor würd ich Getter und Setter machen, ist ein - davor würde ich diese nicht machen.
Auf keinen Fall die Variable public...
Da stimme ich zu, habe auch nichts anderes behauptet. Ich sage nur, dass es ein Fehler ist, UML-Klassendiagramme eins zu eins in Code übertragen zu wollen. Das
Code:
+
(also public) heißt: "Es gibt die Anforderung, dass diese Variable von überall aus Zugreifbar sein muss." In Java wäre eine private Variable mit public getter/setter eine Valide Umsetzung dieser Anforderung. So sehe ich das zumindest, wenn das Klassendiagramm für die Dokumentation von Anforderungen verwendet wird.
Wenn es verwendet wird, um Code zu dokumentieren. Dann wäre es sicher besser
Code:
-
zu nehmen und die getter/setter in die Methodenliste aufzunehmen. Dann würde ich aber sofort die Frage nach dem Sinn dieser Dokumentation stellen. Weil sie eigentlich nur etwas anders darstellt, was ich auch direkt im Code nachvollziehen kann.
UML ist eine Sammlung verschiedener Modellierungstechniken, die einem gewissen Standart angelehnt sind.
In der Uni wurde bei Prüfungen von Softwaretechnik penibel drauf geachtet, dass wir uns an die UML-Standartisierung halten. Abweichungen von der UML-Norm wurden hart bestraft. private Variablen mit + zu Kennzeichnen ist schlichtweg falsch. Dafür wurden uns einige Punkte abgezogen in der Prüfung.
Also ich würde das auch als falsch markern. Allerdings ist das bei UML in der Praxis oft so, dass die Teams die UML Regeln neu definieren und wenn es eine Regel gäbe, in der mit public markierte Variablen private sind unt mit Getter und Setter ausgestattet werden, damit man die Diagramme nicht mit unwichtigem Zeug zumüllt, dann ist das eine teaminterne Regel hat in dem Kontext auch Gültigkeit. UML ist sicherlich ein Standard. Jedoch ist UML so ausgelegt worden, dass man es auch nur als Leitfaden nutzen und die Regeln neu definieren kann. Dann müssen die Änderungen den Leuten aber auch bekannt gemacht werden und gelten auch nur für den jeweiligen Kontext. Ich sehe das daher nicht zwangsläufig als falsch an. Wenn die Regeln so formuliert wurden und alle zugestimmt haben, dann ist das ok. Und es ist sicherlich auch keine Seltenheit, dass hier und da ein paar Regeln leicht verbogen werden.
Uns wurde beigebracht, dass allein durch Konventionen Getter und Setter in jedem Objekt enthalten sein sollten. Deswegen können diese bei einem UML Klassendiagramm als explizite Methodenangabe weggelassen werden.
Jede mit - gekennzeichnete Variable in einer Klasse (und das sollte sie nach OOP auch sein (Datenkapselung)) impliziert vorhandene Getter und Setter für dieses Klassenattribut.
Uns wurde beigebracht, dass allein durch Konventionen Getter und Setter in jedem Objekt enthalten sein sollten. Deswegen können diese bei einem UML Klassendiagramm als explizite Methodenangabe weggelassen werden.
Jede mit - gekennzeichnete Variable in einer Klasse (und das sollte sie nach OOP auch sein (Datenkapselung)) impliziert vorhandene Getter und Setter für dieses Klassenattribut.
Jede mit - gekennzeichnete Variable in einer Klasse (und das sollte sie nach OOP auch sein (Datenkapselung)) impliziert vorhandene Getter und Setter für dieses Klassenattribut.
Jede mit - gekennzeichnete Variable in einer Klasse (und das sollte sie nach OOP auch sein (Datenkapselung)) impliziert vorhandene Getter und Setter für dieses Klassenattribut.
