UML, Design Patterns, ...

[woki]

Zitat:

Zitat von Christof

Das ist nicht korrekt, z.B. hat Delphi keine reflection classes und einiger Design Patterns sind damit realisiert. Man kann das natürlich nachgebildet werden, allerdings ist JAVA z.B. direkt Objektorientiert entwickelt wurde. Somit ist JAVA auf jeden Fall geeigneter als Delphi, über c++ oder c# (na ja c# sieht ja aus wie JAVA) läßt sich streiten.

Delphi hat doch RTTI, sonst würde doch nicht einmal der Objektinspektor funktionieren.
Wir sollten aber beim Thema bleiben. Die Frage war ja nicht: lässen sich UML und Design Pattern in irgendeiner Programmiersprache besser umsetzen als mit Delphi, worüber man diskutieren könnte, sondern geht das mit Delphi und ist es sinnvoll, und es geht mit Delphi ohne in der Praxis schmerzhafte Einschränkungen. Ein Physiker hat mal gesagt, ich muß nicht beweisen, daß diese Schwingugnsgleichung eine Lösung hat, ich sehe doch, daß es schwingt, und genauso mache ich es mal hier denn so ist es auch mit Delphi:

Alle wichtigen UML - Tools arbeiten nämlich sehr wohl in einem Round Trip Engineeting mit Code Generierung und Code Import mit Delphi zusammen, z.B. Rational, Together, Objectif,
und das nicht erst seit gestern, sondern taten das schon im Jahr 2000, und Modellmakter tat das da schon in der Version 5.5.

Zitat:

Zitat von Christof

Das mit der Zeit für UML ist, denke ich eine Philosophie Frage und eine einarbeitungs Phase. Wenn ich z.B. ein kleines Projekt mache und alles Objektorientiert durchziehe (Analyse, Design, usw.) und ein anderer erfahrener Programmierer macht kurz Design und legt los. Ist der erfahrener Programmierer auf jeden Fall schneller und der Code muss nicht schlechter sein z.B. Konzept des extreme Programming.

Aber extreme Programming ist doch kein Konzept, das an prozedurale Softwareentwicklungsphilosophien gekoppelt ist.

Natürlich muß man sich in Tools einarbeiten, aber man kann hochintegrierte UML-Tools wie Modellmaker nach einem Tag Schulung sonnvoll einsetzen, vorausgesetzt man ist gewöhnt objektorientiert zu denken. Natürlich nutzt man zu dem Zeitpunkt nur ein paar Prozent der Fähigkeiten des Tools, aber das schadet nicht.
Wenn ich in die Entwicklungsumgebung hochintegrierte UML-Tools pragmatisch und sinnvoll dosiert einsetze, und mit den Tools umgehen kann, wird es kaum ein Projekt geben, in dem ich nicht Vorteile erzielien kann, außer es ist eine Testform, die ich in 5 minuten baue, und dann gleich wieder in den Papeirkorb werfe, UML bei Delphi wird man weniger einsetzen, um eine Form zu entwerfen, somndern für die Logik dahinter.

Zitat:

Zitat von Christof

Allerdings arbeite ich im Team an einem grossen Projekt ist UML meiner Meinung nach unversichtbar.

Da kann ich zustimmen.

Zitat:

Zitat von Christof

Ich denke die Wahrheit liegt wie immer in der Mitte. Ein bisschen UML kann nie schaden, aber nicht übertreiben.

Etwas anderes habe ich doch nie gesagt.

Zitat:

Zitat von Christof

Ein kleines Problem ist, dass es noch kein Tool für UML gibt das direkt Delphi Code generiert (UML kann man natürlich erstellen). Allerdings hoffe ich, dass sich da etwas ändern wird. Borland hat ja schliesslich TogetherSoft gekauft und die integrieren dies ja auch in Delphi, ich hoffe so gelingt so wie in JAVA.

Und das stimmt eben wieder nicht, es gibt diese Tools seit vielen Jahren, werden seit anderthalb Jahren (Delphi 7) gleich mit der IDE von Borland direkt verkauft, wobei die .Net schiene die Togethertechnologie verwendet und die WinApi schiene die Modellmakertechnologie und beide verwenden Bold, und es ist gelungen, weil Delphi alle nötigen Voraussetzungen dafür hat.

Grüsse
Woki