UIML Class Diagram Property Attribute

[dedlfix]

Tach!

Nun, wenn ich mir Deinen Code zum TableConstructor anschaue sehe ich, daß Du den Sinn von OOP nicht wirklich verstanden hast. Solch eine Klassenflut ist nicht der Sinn von OOP!

OOP ist ein Programmierprinzip. Eine quantitative Aussage steckt da nicht drin. Vielleicht hast du einfach nicht das Single Responsibility Prinzip verstanden?

Vielmehr gehts in OOP darum, Sachverhalte und praktische Aufgaben möglichst einfach zu modellieren.

Komplexe Sachverhalte lassen sich üblicherweise nicht wesentlich vereinfachen. Es ist nun eine Frage der Organisation und Abwägung der Vor- und Nachteile. Man kann zwar eine große Klasse mit schlanker API erstellen, aber Aufteilung in viele kleine, dafür aber einfacher zu testende Klassen ist das, was sich in der Praxis mehr bewährt hat.

Wie auch immer, deine Antwort hat das Thema verfehlt. Die Frage war nicht, wie mal seine Klassen strukturiert, sondern wie man bestimmte konkrete Sachverhalte in UML abbildet.

dedlfix.