Delphi und Software-Design

[mquadrat]

Hallo zusammen,

Ich arbeite mit verschiedenen Sprachen (Delphi, C#, Java, PHP) und bin daher auch in mehreren Communities unterwegs. Dabei ist mir aufgefallen, dass im Delphi-Umfeld erstaunlich wenig über Software-Design diskutiert wird. PHP Foren sind voll von Fragen zu MVC und HMVC. In der .NET Welt wird eifrig über MVVM und die diversen IoC-Container diskutiert. Die Themen wimmeln nur so von Best-Practices und Pattern-Bezeichnungen (zum Teil übertrieben). Ein Framework wird vom nächsten gejagt.

Da stellt sich für mich die Frage warum es in Delphi-Foren meist um das Programmieren eines Pong-Clones und Kollisionserkennung geht (ACHTUNG: Überspitzt und leicht sarkastisch ;) ).

Sind die Delphi-Entwickler alle so gut, dass diese Disukssionen unnötig sind oder ist für Delphi-Entwickler gutes Design nicht so wichtig?

[himitsu]

Das liegt vielleicht daran, daß es in Delphi schon ein integriertes GUI-Framework gibt (die VCL) und man sich deswegen keine Gedanken macht, daß man eventuell auch ein anderes Framework verwenden könnte?

Gut, abgesehn von denen, welche kein GUI-Framewörk verwenden und sich direkt an die WinAPI wenden (NonVCL, wobei man es wohl auch NonGUIFramework nennen könnte).

[mquadrat]

Naja aber bei .NET hat man mit WPF auch ein GUI-Framework und setzt noch was obendrauf. Wer bei WPF noch was in die Code-Behind Klassen schreibt, wird in Communities fast schon erschossen.

[vagtler]

@himitsu: Und deswegen kan man grundlegende Gedanken der Software-Architektur wie Best Practices und Entwurfsmuster ignorieren?

Das schlägt in die gleiche Kerbe, die ich leider immer wieder bei Vorstellungsgesprächen miterleben muss: haben immerhin die Hälfte der Bewerber mit Delphi-Kenntnissen schon mal etwas von Unit-Tests gehört, so wird die Auswahl der Aspiranten, die etwas mit Begriffen wie IoC oder MVC anfangen können, merklich geringer.

Bei den Bewerbern im .NET-Umfeld sieht es hier doch um einiges besser aus - auch und sogar wenn diese erheblich weniger Berufserfahrung mitbringen.

[mquadrat]

Man braucht ja nur mal die Vortragsthemen von der PDC mit denen von CodeRage (hieß, doch so oder?) zu vergleichen.

[vagtler]

Jetzt gehst Du aber unter die Gürtellinie... :mrgreen:

[rweinzierl]

Hallo

Meine persönliche Meinung

Gutes design ist in jeder Sprache wichtig aber wer Hobbymäßig unterwegs ist kommt in Delphi sehr weit ohne auf irgendetwas Rücksicht zu nehmen.

Er kann sich auf sein Problem konzentrieren und Programmieren was er will, selbst wenn er einfach nur seine Formulare zusammenklickt und alles irgendwie darin speichert kann ein nützliches Programme entwickeln. (und Delphi unterstüzt ihn sogar!)

Wer das in anderen Sprachen (z.B. C, C++) probiert wird scheitern.

Für schnelles Prototyping, ist Delphi genial, auch hier braucht man noch nicht unbedingt ein perfektes Objektmodel.

Wer professionell Arbeiten will, der muss genauso stukturiert wie in allen anderen Sprachen arbeiten, aber ein professioneller Programmierer frägt eher selten in einem Forum nach ob sein Programmierstil so passt.

mfg

Reinhold

[shmia]

Das liegt IMHO daran, dass Delphi von der Struktur der VCL so gebaut ist, dass man nicht so einfach MVC oder andere Modelle einführen kann.
Ein Formular bzw. die Klasse hinter dem Formular ist View und Controller zugleich.
Somit kann man eigentlich nur das Modell sauber vom Formular isolieren (leider geschieht dies viel zu selten).
Desweiteren fehlt Delphi auch das Feature, dass ein Event von mehreren Eventhandler empfangen werden kann.
Um das zu beheben habe ich mir eine EventList-Klasse programmiert, aber ohne direkte Unterstützung der Sprache bleibt es eine Krücke.
Und so besteht in Delphi zwischen Modell und View eine 1-zu-1 Beziehung, was in vielen Fällen ausreichend ist.

[Phoenix]

Zitat:

Zitat von shmia (Beitrag 1074203)

Das liegt IMHO daran, dass Delphi von der Struktur der VCL so gebaut ist, dass man nicht so einfach MVC oder andere Modelle einführen kann.

Die Aussage ist Quark. Ich habe vor 10(!) Jahren (2000 bis ca. 2002) schon mit einem (zu dem Zeitpunkt auch schon einige Jahre!! alten) MVC-Framework in Delphi gearbeitet.

Und das hat nicht viel anderes gemacht als mit einem integrierten ORM das Model bereitzustellen (Code- und Datenbankgenerierung aus XML, das mit einem eigenen Designer erstellt wurde), eine eigene Klassen-Hierarchie für die Controller bereitzustellen und ein Factory-Pattern für die normal designten Forms. Dazu gab es ein paar Vorgaben wie datengebundene Controls zu heissen haben, so dass der Controller diese dann automatisch ans Model binden konnte.

In sowas stecken dann natürlich einige Mannjahre an Entwicklung, aber so produktiv wie damals habe ich selten wieder gearbeitet.

Sowas geht allerdings auch ohne ORM.

[mquadrat]

@rweinzierl

Natürlich fragt man nicht nach dem Stil. Aber es ist doch sehr sehr ruhig was diese Themen angeht. Man kann ja durchaus fragen, welchen IoC-Container andere einsetzen. Oder wie man die Limitationen von RTTI in den älteren Delphis umgehen kann.


@shmia

Form und Code-Behind (ich benutze jetzt einfach mal den .NET Slang) sind IMHO nicht View und Controller, sondern können auch nur als View verwendet werden. Alles was man dort wirklich machen muss ist der Glue-Code, wenn man kein Convention-Over-Code Framework verwendet.

EDIT: Die rote Box war schneller ;)