🚀 go-pugleaf

Witam

Maciej Sobczak napisał(a):
> Można to << >> przykleić nie do klasy Foo, ale do relacji pomiędzy Foo i
> Bar. Wtedy będzie widać, że jest to cecha relacji a nie cecha jednej klasy.

Poproszę o przykład może być na priv.

> A ja bym tego nie modelował w UML tylko raczej potraktował jako element
> języka.

To nie chodzi tyle o język, bo gdyby w innym było to możliwe to też
byłoby dobrze.
Np. ciekawe są klasy w których możesz w runtime lub w czasie
kompilacji
rozszeżać ilośc metod. I tego też się nie da zobrazować.

Krótko mówiąc. UML staje się nażędziem, które przy pewnym
poziomie abstrakcji
jest tylko kulą u nogi, bo nie da się narysować tego co jest
ciężkie. Z rzeczy proste
są proste.
 Oczywiście rozumiem i cały czas podkreślam, że np. projekty
biznesowe są
wystarczająco proste strukturalnie, aby stosować UML. Mam nawet
informacje z
wiarygodnego zródła, że w Javie można wiele napisać tyko rysując
i kożystając
z gotowych beanów, to jest programowanie przez rysowanie :-).

> Obecność czegoś takiego na diagramie kompletnie niczego nie
> wnosi, bo ostatecznie struct IF jest tylko narzędziem do wyrażania
> relacji pomiędzy tymi typami, które są właściwą domeną dla
> analityka/projektanta. Dlatego posłużyłbym się raczej pojęciem IF w
> stereotypach albo innych dekoracjach w relacjach pomiędzy tymi
> właściwymi typami, zakładając, że IF jest już częścią języka
> programowania (dotyczy to wszystkich konstrukcji typu MPL).
> Odpowiedni generator potrafiłby taką iluzję stworzyć.

Czyli dochodzi Ci potrzeba użycia dodatkowego utilka pokazującego na
zależność
pomiędzy typami.

> > Tak więc jeśli możesz wskazać na
> > jakieś opracowania
> > w których podjęte jest wyzwanie narysowania takich konstrukcji jak
> > "boost::" to chętnie
> > poczytam.
>
> Nie znam żadnych takich opracowań. :-)

Szkoda :-).

Pozdrawiam, Seweryn Habdank-Wojewódzki.