Wie kann ich Methoden-Attribute in UML darstellen?

[mutetella]

Worin liegt aber dann der Sinn, einen Namen an eine Methode und nicht an die Klasse zu binden? Oder anderst gefragt: Wenn ich einen Namen an eine Methode binden möchte, für welche Methode entscheide ich mich denn dann? Einfach nur "thematisch"? Denn wenn ein Name außerhalb einer Methode an diese gebunden werden muss, wo besteht dann der Zusammenhang?

Code: Alles auswählen

class Data():
    first = 'Pippi'
    last = 'Langstrumpf'

    def __init__(self, first, last):
        self.set_name(first, last)

    def set_name(self, first, last):
        self.first = first
        self.last = last

    def so_halt(self):
        pass

    set_name.first = 'Karlsson'
    set_name.last = 'vom Dach'

class View():
    def __init__(self):
        self.data = Data('Kalle', 'Blomquist')

    def create(self):
        print(Data.first, self.data.first, self.data.set_name.first)
        print(Data.last, self.data.last, self.data.set_name.last)

Ausgabe:

Code: Alles auswählen

In [62]: a = View()

In [63]: a.create()
('Pippi', 'Kalle', 'Karlsson')
('Langstrumpf', 'Blomquist', 'vom Dach')

In welchen Fällen braucht man wie hier Klassenattribute wie 'Data.first' oder 'Data.last'? Sieht für mich so aus, als würde in so einem Fall die Klasse "nur" als Datenspeicher verwendet.
Wann lässt sich sowas wie 'set_name.first' sinnvoll anwenden? Ließe sich genauso gut auch an die Methode 'so_halt' binden. Warum macht man sowas?

:K

Gruß
mutetella

[Pekh]

Wann lässt sich sowas wie 'set_name.first' sinnvoll anwenden? Ließe sich genauso gut auch an die Methode 'so_halt' binden. Warum macht man sowas?

Es gibt extreme Situationen, z.B. beim automatisierten Testen, wo sowas nützlich sein könnte. Schön ist es aber mit Sicherheit nicht. Ich wußte bislang nicht, daß es überhaupt geht, und ich habe es bislang auch nicht vermißt. Ein derartiges Gefrickel schafft oft mehr Probleme, als es löst.

[BlackJack]

@mutetella: Wenn Du nicht weisst an welche Methode Du ein Objekt binden willst, dann ist die Antwort höchstwahrscheinlich "an keines". Es macht halt genau dann Sinn, wenn Du Daten an eine bestimmte Methode binden willst. Wenn Du das nicht willst, weil Dir nichts einfällt was dort Sinn macht, dann musst Du ja auch nichts daran binden.

Ein sinnvolles Beispiel für Attribute auf Methoden was ja auch direkt von Python schon genutzt wird ist halt das `__doc__`-Attribut.

Andere wären (weitere) Metainformationen die von Bibliotheken verarbeitet werden können. PLY "missbraucht" zum Beispiel die Docstrings um Informationen an Funktionen/Methoden zu binden, die für die Erstellung eines Parsers benutzt werden. Das könnte man auch über zusätzliche Attribute regeln ohne die Docstrings dafür "missbrauchen" zu müssen. Um es im Quelltext etwas hübscher zu machen, könnte man sich einen Dekorator schreiben, der die Attribute setzt.

Ansonsten sind die Attribute auf Methoden/Funktionen ja nur einmal und "ständig" vorhanden, haben also ähnliche Eigenschaften wie zum Beispiel als ``static`` deklarierte Variablen in Funktionen in C. Benutzt man recht selten, aber auch dafür finden sich ja Anwendungsfälle.

Klassenattribute werden zum Beispiel für Konstanten oder "Default"-Daten eingesetzt, die thematisch zu der Klasse gehören.

[Darii]

In welchen Fällen braucht man wie hier Klassenattribute wie 'Data.first' oder 'Data.last'? Sieht für mich so aus, als würde in so einem Fall die Klasse "nur" als Datenspeicher verwendet.

Klassen sind auch nicht viel mehr als Datenspeicher.

[mutetella]

Neben UML gibts da z.B. OPM.

Verwendest Du selbst OPM? Wenn ja, nutzt Du dafür OPCAT oder bedienst Du Dich "nur" der Methode?

Gruß
mutetella

[Pekh]

Neben UML gibts da z.B. OPM.

Verwendest Du selbst OPM? Wenn ja, nutzt Du dafür OPCAT oder bedienst Du Dich "nur" der Methode?

Gruß
mutetella

Mittlerweile nutze ich auch OPCAT selbst. Ist mit rund 3500 EUR aber eher nichts für den Hobby-Bereich. Ich habe aber auch lange Zeit (für schnelle Skizzen und zum Festhalten von Ideen immer noch) einfach mit Zettel und Stift OPDs gezeichnet. Das geht auch ganz gut, man muß halt nur gut aufpassen, wenn man Änderungen vornimmt oder ein neues, detailiertes Diagramm eines Teilaspekts ('In-Zoom') anlegt. Insofern unterscheidet es sich punkto Anfälligkeit für Konsistenzprobleme nicht groß von UML. Die Notation finde ich allerdings um Längen angenehmer.

Auf Anfrage kannst du vom Entwickler übrigens eine Demoversion von OPCAT bekommen. Diese ist allerdings auf 150 Elemente (Objekte, Prozesse, Pfeile) beschränkt, was zu wenig ist, um mehr als winzigste Programme durchzuplanen. Aber zum Kennenlernen reicht es.