Keiner verwendet Objektorientierung ???

[svehei]

bevor man tatsaechlich oop in delphi verwenden will, ist es doch sinnvoller erst einmal die prinzipien von oop zu verstehen (und dies nicht ueber delphi-handbuecher, da dort doch immer delphi-speziell erklaert wird). wenn du da einmal dahinter gestiegen bist, ist es prinzipiell egal mit welcher programmiersprache du arbeitest, nur eben der syntax ist leicht unterschiedlich.

bei mir war das zumindest so der fall

erste programmierschritte mit turbo pascal (prozedural) und delphi 1, dann studium und nur noch oop mit java und c++. jetzt komm ich berufsbedingt wieder zu delphi zurueck und siehe da ich arbeite mit objekten

[Motzi]

Also meine Programme sind großteils schon objektorientiert. Egal ob das jetzt neue Komponenten sind oder nur kleine Objekte um irgendwelche Daten zu verwalten... Ich hab mir das ganze Prinzip und Konzept des OOP aus diversen Büchern angeeignet und dann per learning by doing (und Versuch und IRRTUM ) die Praxis dazu geholt...

Ich hab für meine Matura (österr. Version des Abitur) als Informatik-Spezialgebiet OOP in Delphi gehabt. Hier ist meine Ausarbeitung dafür. Wer Lust hat kann es sich mal anschaun und einen Kommentar dazu abgeben. Würde mich interessieren ob es gut verständlich ist und ob man was damit anfangen kann!
Für die Matura hat es auf jeden Fall für ein "Sehr gut" gereicht!

[Minz]

Hallösche,

ein wie ich finde gutes Tutorial gibts hier

http://www.grundlagen.delphi-source.de/pascal/

Wo ist das Problem mit der Benutzung von Kompos?

So ein Button oder ein Edit-Feld sind doch auch Klassen. Selbst wenn
ich Kompos benutze bleibe ich demnach objektorientiert.
Ich kann die Dinger ja auch zur Laufzeit erstellen:

Button1=TButton.create;

Der unterscheidet sich ja nicht von so einem, der zur Design-Zeit erstellt wird, ist halt nur viel umständlicher!!

Ansonsten benutze ich schon oop, und hier sind einige die das tun.

Ich glaube, das aber oft algorithmische- und Syntax-Probleme auftreten, die man dann nicht unbedingt oop-mäßig beantworten sollte!!

Minz

[oki]

Hallo.

Mir ist auch aufgefallen, dass manche auch in diesem Forum sich Gedanken machen wie manches Problem auf alt hergebrachte Weise gelöst werden könnte und die Einfachste Lösung eigentlich ein Objekt ist. Da waren so Beiträge: Wie kann ich Strings in einem dyn. Array sortieren? - und keiner denkt an Stringlisten.

Ich glaube, das Problem ist, dass viele den kleinen Mehraufwand scheuen. Es ist ja einfacher erst mal irgentwo eine Variable global zu definieren als zu schauen ob eine Eigenschaft an der richtigen Stelle oder ein neues Objekt die Tür für später nicht besser offen hält.

Wer schafft es schon seine Projekte vollständig vorzuplanen? Bei mir hilft da ein eisernes Prinzip: Erst prüfen ob die aktuelle Detailumsetzung in ein bestehendes oder neues Objekt paßt!

Dann entsteht immernoch genug unstrukturierter Code, aber man läßt sich die Changs zwischendurch aufzuräumen. Gerade wenn Projekte wachsen (was ich nie so richtig vermeiden kann) wandern Variablen und Methoden zwischendurch in neue Objekte. Es wird mir irgentwann einfach zu konfuß und ich "räume" sozusagen auf indem ich Teile in Objekte packe. Der Aufwand hällt sich dann immer in Grenzen. Das passiert aber nur dann, wenn ich einfach zu kurzfristig gedacht habe.

Somit habe ich mir ein eisernes Prinzip angewöhnt: Immer erst den Objektweg! Nur wenn nicht anders möglich andere Wege nehmen.

Hierbei ist es nicht wichtig, ob mann schon perfekt ist. Wenn eine Methode das zweite mal schreibt, überlegt man automatisch, wie man die erste "verbiegen" kann um den Aufwand zu sparen. Und schon ist man bei Objekten und Vererbung ohne es so richtig zu merken.

Das man als Anfänger erst mal die Grundbegriffe der Programmierung lernt und glaubt mit dem was kann besser vorwärts zu kommen ist normal.

Es ist dann immer nur die Frage welchen Weg man geht. Mann kann mit den konventionellen Programmierwegen solange riesen Projekte schreiben bis man selber nicht mehr durchsieht und beschäftigt sich in logischer Konsequenz mit OOP; oder man hört auf die anderen, beißt in den sauren Apfel und schlägt sich gleich mit OOP rum und spart somit den mühsamen Erkenntnisweg.

Ich glaube viele denken auch immer wunder was OOP ist und sehen nicht, dass sie OOP zwar "verwenden" aber konsequenterweise nicht "benutzen".

Gruß Oki

[Hansa]

Zitat von oki:

Mir ist auch aufgefallen, dass manche auch in diesem Forum sich Gedanken machen wie manches Problem auf alt hergebrachte Weise gelöst werden könnte...

jo, aus der Steinzeit. Wie man nicht objektorientiert ein Spiel programmieren will, das soll mir mal einer erklären. Hier gibts ja genügend Fragen zu sowas.

Zitat:

...Ich glaube, das Problem ist, dass viele den kleinen Mehraufwand scheuen...

Wers kapiert hat, ja der hat gewonnen. Ich habs zwar kapiert, aber Umsetztung in Delphi, das ist noch ein Thema. Der Mehraufwand liegt mehr im Verständnis oder (wie bei mir) in der Umsetzung. Was ich noch nicht genau verstehe ist, das mit dem read und write.

Zitat:

...Somit habe ich mir ein eisernes Prinzip angewöhnt: Immer erst den Objektweg! Nur wenn nicht anders möglich andere Wege nehmen...
Ich glaube viele denken auch immer wunder was OOP ist und sehen nicht, dass sie OOP zwar "verwenden" aber konsequenterweise nicht "benutzen".

Tja, offensichtlich wird das tatsächlich kaum genutzt. Für mich zwar kaum nachzuvollziehen, aber anscheinend Tatsache. Das hier aber auch (Zitat frei aus Internet) :

Zitat von ???:

Warum sollte man objektorientiert vorgehen ?

1. der Einfachheit halber (Wiederverwendung bestehenden Codes)...
2. Debugging : zentralisierter Code läßt sich leichter warten
3. Geld : Es gibt eine Menge an Firmen, die sind gerade zu überglücklich, für das Priveleg zu zahlen, das Rad nicht neu erfinden zu müssen.

[oki]

Hi Hansa,

das mir dem read und write ist ganz einfach.

Im Grunde passiert nichts anderes, als ob du eine Variable direkt liest oder beschreibst. Der Witz kommt erst mit der Verwendung in deinem objekt.

Stell dir vor du bist der Erfinder eines Listobjektes. Jetzt hast du eine Eigenschaft Count. Wenn die einfach einer neu setzen würde, ändert sich dadurch aber nicht automatisch die Größe deiner Liste. Also deklarierst du sie einfach mal nur mit property read.
Keiner kann mehr schreibend darauf zugreifen!
Nun ist das natürlich doof so. Also schreibst Du eine Methode

procedure SetCount(NewCount : Integer);

Count lesen aus Count und setzen mit SetCount ist zwar ok, aber auch doof.

Jetzt deklarierst du

Property Count : Integer read FCount write SetCount;

mit der Zuweisung Count := 20 wird automatisch die Methode SetCount aufgerufen und von außen gesehen, zauber zauber, wird nicht nur Count gesetzt, sondern auch deine Listegröße geändert.

Gruß oki