Re: Delphi und OOP

Hallo Golo,

grundsätzlich ist Delphi m.E. sehr stark objektorientiert, aus irgendeinem
Grund wird es ja Object Pascal heißen :)

Erstellst Du Komponenten oder Klassen sieht das eigentlich nicht so viel anders
aus, als ob Du in einer Form arbeitest. Das meinte ich mit vertrauter Umgebung.
Es ist einfach in dem Sinne nichts Neues.
Du bist einfach ständig mit Klassen, Objekten, Komponenten konfrontiert.

In VFP habe ich das Definieren von Klassen, Komponenten immer als Fremdkörper empfunden,
heißt es fühlt sich für mich irgendwie prozedural an.
In Delphi bist Du halt einfach mittendrin. Aber das mag subjektiv sein.
Das das Lösen von Problemen, die Wahl der richtigen Methode/Vorgehensweise
nicht immer einfach ist, ist klar.

M.E. aber nicht unbedingt ein OOP-Problem. Es mangelt hier ja auch an guten Büchern,
die etwas zu Programmierkonzepten beitragen.

Übrigens sollen viele Elemente und Konzepte von Delphi ja auch in das .NET Framework eingeflossen
sein, sowie in C#, nachdem Anders Hejlsberg von Borland zu MS wechselte...

Viele Grüße
Michael

nun monatelang drüber nachdenken, kann ich mir nicht leisten ;)

"Golo Roden" <webmaster@xxxxxxxxxxxx> schrieb im Newsbeitrag news:uwhvo9otIHA.1936@xxxxxxxxxxxxxxxxxxxxxxx
Hi Michael,

kurz zur Antwort Deiner Frage:

> was siehst Du anders und warum ?
> dass Delphi OOP ist oder dass ich nicht viel nachdenke ;) ?

Inwieweit Delphi objektorientiert ist, kann ich nicht beurteilen, dafür kenne ich Delphi deutlich zu schlecht.

Was ich aber anders sehe, ist, dass man "halt einfach damit arbeitet und gar nicht mehr drüber nachdenkt" - klar, so lange Du nur die vorgefertigten Objekte aufrufst und keine einzige Klasse selbst schreibst, stimmt das wohl.

Aber sobald Du anfängst, eigene Klassen zu bauen, ergeben sich doch massenweise Fragen, und mit denen sind 95% der Entwickler auch heute noch überfordert.

Nur um mal ein paar Beispiele zu nennen:

- Wann nehme ich ein Interface, wann eine abstrakte Klasse?
- Sollte man ableiten oder aggregieren?
- Wie versioniert man Interfaces?
- ...

Das sind Beispiele für OOP-Fragen, über die kann man wochen-, wenn nicht monatelang diskutieren - und das ist definitiv nichts, was man "halt einfach" macht, jedenfalls nicht, wenn man eine durchdachte und tragfähige Architektur haben will.

Viele Grüße,


Golo

.

Relevant Pages

  • Re: Kopieren/Zuweisen von Klassen
    ... Die Idee, Klassen als "verkappte" Zeiger zu behandeln, ohne dies formal sichtbar zu machen, fand ich schon bei Java unglücklich. ... In C++ sieht man einer Deklaration explizit an, ob es eine Auto-Variable, ein Pointer oder eine Referenz ist. ... In Delphi ist es IMO noch unglücklicher, weil es hier ja noch die records gibt, die Klassen zwar formal sehr ähnlich, aber eben KEINE impliziten Pointer sind. ...
    (de.comp.lang.delphi.misc)
  • Re: Brett?!
    ... und lege alles in globale Variablen ab. ... Und wustest Du das es bei Delphi auch GOTO gibt? ... Records nähern sich in den letzten Delphi-Versionen immer mehr Klassen an. ... Gegenüber Klassen hat man den Vorteil, dass Records keine impliziten Pointer sind und ohne das mit Create/Free einhergehende Risiko von Speicherlecks benutzt werden können. ...
    (de.comp.lang.delphi.misc)
  • Re: was bedeutet diese VB Code?
    ... was die Konvention unsinnig erscheinen lässt. ... Bei der Delphi Language wurde diese Konvention im ... Wenn man vorhat vollständig auf .NET zu portieren oder nur neue ... wenn man die Klassen mal mit "T" beginnt und mal nicht. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: delete() auf void* anwenden
    ... Ich überleg jedesmal neü, wie ich Klassen, Variablen und Typen schreibe, ... In Delphi hatte ich Typennamen immer ein T ...
    (microsoft.public.de.vc)
  • Re: Borland/Delphi Dying blog entry from Ken Henderson at MS
    ... What I can tell you is that I found Clarion hard work to use. ... Delphi was - well, Delphi. ... Clarion's programming interface was certainly far from being ...
    (borland.public.delphi.non-technical)
Loading