Keiner verwendet Objektorientierung ???

[Hansa]

Hi,

ich muß dieses Thema mal ansprechen. Delphi ist eine objektorientierte Programmiersprache. Nur kommt es mir langsam so vor, daß keiner das Potential nutzt. Äußerst selten sieht man etwas darüber. Verwendet denn jeder tatsächlich nur vorgefertigte Komponenten :?: Oder ist es so schwer Vererbung, Methoden usw. zu verstehen und einzusetzen ?

[Daniel B]

Zitat:

Zitat von Hansa

ich muß dieses Thema mal ansprechen. Delphi ist eine objektorientierte Programmiersprache. Nur kommt es mir langsam so vor, daß keiner das Potential nutzt.

So ist es.

Zitat:

Äußerst selten sieht man etwas darüber. Verwendet denn jeder tatsächlich nur vorgefertigte Komponenten :?: Oder ist es so schwer Vererbung, Methoden usw. zu verstehen und einzusetzen ?

Ja, Ja, Ja, Ja, Ja.

Grüsse, Daniel :hi:

[Hansa]

hammerhart. :shock: Kann das fast nicht glauben. Mir fiel das schon länger auf. Hätte aber eher mit erheblichem Widerspruch gerechnet und gedacht, daß ich der blöde bin und das ganze sonst überall genutzt wird. Ich baue mir doch wohl besser eine Anhängerkupplung an einen PKW, anstatt einen neuen zu kaufen bzw. einen zu haben, bei dem das gar nicht geht.

Gibts so was ? Wer hat noch was dazu zu sagen? Also ich bin doch etwas perplex jetzt. Hier sind doch etliche Schüler vertreten, lernt ihr sowas nicht :?:

[Touchdown]

In meiner Firma wird sehr wohl OOP angewendet, folglich nutze auch ich die Vorteile der OOP.

Grundsätzlich muss man dir aber wohl zustimmen, dies mag auch an dem nicht bekannten Vorteilen liegen und einem nicht ganz einfachem Einstieg in die OOP.

[Daniel B]

Ich weltze Bücher. Mit der OH komme ich in dieser Beziehung nicht weiter. Aber Bücher ist Zeitraubend und die hab ich nicht. Weiss aber schon was man alles damit machen könnte und wie Gei* das eigentlich ist, dennoch fehlt mir die Zeit und die NErven um mich wirklich mit sowas zu beschäftigen. Wo das doch der Gag überhaupt an Delphi ist, da hast Du recht.

Grüsse, Daniel :hi:

[Haegar]

nein, weil wahrscheinlich die lehrer genügend damit zu tun haben die grundlegenden sachen (rekursio...prozedure/Funktionen allg, sortierverfahren) beizubringen.
ich selbst hab erst anfang der 13. (dieses jahr) mit delphi in schule angefangen. demzufolge musste ein grossteil erstmal vom aufbau des programms (komponenten..OI etc.) lernen!

gruss haegar

[jbg]

Also ich benutze sehr wohl OOP. Der gesamte Unterbau meiner Programme besteht aus Klassen. Da die VCL nicht auf dem Doc/View Model aufbaut, baue ich es mir immer selber zusammen, womit all meine Daten in Klassen stehen und die Anzeige jederzeit austauschbar bleibt.
Es gibt aber natürlich auch Ausnahmen. So mache ich mich nicht verrückt (wie jeder Java Programmierer) und sammle meine String- und sonstige Hilfsfunktionen in Klassen. Nein hier benutze ich dann doch die imperialen Eigenschaften von Delphi.

Das es aber so aussieht, dass kaum einer OOP benutzt liegt aber auch daran, dass vor allem Anfänger eher eine Abneigung gegen diese Programmierweise haben, weil dazu sehr viel Abstraktionsvermögen gehört, das diese erst erlernen müssen. Außerdem wollen sie auch so schnell wie möglich Ergebnisse sehen und nicht erst das gesamte Programm durchplanen.

[Mirilin]

Wo ihr grade so schön bei Büchern seid, könnte mir jemand ein Buch über OOP empfehlen? Sprache ist Egal (das heisst Deutsch oder Englisch, ja kein Français :D ) . Preis ist auch Egal, nur der Inhalt muss stimmen!

[Daniel B]

Zitat:

Zitat von Mirilin

Wo ihr grade so schön bei Büchern seid, könnte mir jemand ein Buch über OOP empfehlen? Sprache ist Egal (das heisst Deutsch oder Englisch, ja kein Français :D ) . Preis ist auch Egal, nur der Inhalt muss stimmen!

Den original Delphi Handbuch-Satz. Ist Deutsch, kostet ca. 30€ und steht genug drin.

Grüsse, Daniel :hi:

[Mirilin]

Hey Daniel B.

Kriege ich die in der Buchhandlung, oder muss ich da bei Borland anklopfen?

[jbg]

Um an die guten alten TubroPascal Zeiten zu erinnern: Das Update-Handbuch: TurboPASCAL 5.5 (wenn es überhaupt noch erhältlich ist) erklärt sehr gut den Sinn und Zweck sowie die Benutzung von OOP. (Zwar für TP und nicht ObjectPascal) aber der Schritt nach Delphi ist sehr klein.

[Daniel B]

Zitat:

Zitat von Mirilin

Kriege ich die in der Buchhandlung, oder muss ich da bei Borland anklopfen?

Gibts meistens dort wo man auch Delphi selbst kaufen/bestellen kann!

Grüsse, Daniel :hi:

[Hansa]

he, jetzt wirds offtopic. Scheint doch ein wichtiges Thema zu sein, das scheint ja wirklich im Keller zu liegen. Der Delphi-Handbuchsatz eignet sich aber nur bedingt dazu, das ganze zu verstehen. Am besten sind da noch die uralten Turbo-Pascal Handbücher (ab Version 5?). Da wurde das ganze eingeführt und die waren gezwungen es einfach zu erklären, da keiner das Wort Objekte in diesem Zusammenhang gekannt hat. :mrgreen:

Zitat:

Zitat von jbg

... Da die VCL nicht auf dem Doc/View Model aufbaut, baue ich es mir immer selber zusammen..

Was ist ein Doc/View Modell ?

Zitat:

...liegt aber auch daran, dass vor allem Anfänger eher eine Abneigung gegen diese Programmierweise haben, weil dazu sehr viel Abstraktionsvermögen gehört...

Typisch Schule, was wichtig ist muß man sich selber beibringen.Was ist der Unterschied zwischen einem Punkt und einem Kreis ? Beide haben einen Ursprung, aber der Kreis hat zusätzlich noch einen Radius. Ist das abstrakt, oder schwer zu verstehen? Die ganze Programmierung heutzutage läuft doch so. Ohne Objektorientierung geht das alles so nicht mehr :!: Wäre Delphi NICHT abjektorientiert geschrieben worden, käm es wahrscheinlich erst in 30 Jahren auf den Markt.

@Admin: Dauernd kommt invallid_session, sobald ich länger als eine Min. brauche, das hir reinzuhacken.

@jbg: War das 5.5 ? Schreibe Text nicht nochmal um

[Daniel B]

Zitat:

Zitat von Hansa

Was ist der Unterschied zwischen einem Punkt und einem Kreis ? Beide haben einen Ursprung, aber der Kreis hat zusätzlich noch einen Radius. Ist das abstrakt, oder schwer zu verstehen?

Nö, aber erstmal dran denken. ;)

Zitat:

@Admin: Dauernd kommt invallid_session, sobald ich länger als eine Min. brauche, das hir reinzuhacken.

Warscheinlich weil Du in der zwischenzeit die Verbindung trennst.

Grüsse, Daniel :hi:

[Hansa]

Hi,

jbg hat ja denselben Gedanken gehabt wie ich. Die alten Turbo-Pascal Handbücher verdeutlichen das Prinzip recht gut , vor allem so einfach, daß es jeder versteht. Und die gibt es irgendwo auf den Borland Seiten (glaube Museum?). Im Moment kriege ich keine Connection dort hin. Auf englisch sind sie wahrscheinlich auch. Auf jeden Fall gibt es davon eine Download-Version (hoffentlich mit Handbüchern). Aber denkt daran, das geht noch um DOS. :mrgreen:

[Daniel B]

Hallo Hansa,

ich hab hier noch TP5.5. Steht es da auch in der Hilfe, oder braucht man da andere Handbücher?

Grüsse, Daniel :hi:

[jbg]

Zitat:

Zitat von Hansa

War das 5.5 ?

Ja es war 5.5. Die Version 5.0 führte die prozeduralen Variablen ein. Eine neue IDE, den integrierten Debugger, die Verwendung von Unit-Overlays (auf der Festplatte ausgelagerte Units, die bei bedarf in den Speicher geladen werden, der wiederum bei Nichtbenutzung wieder durch andere überschrieben werden konnte) und was auch recht wichtig ist: Die uses-Anweisung im implemetation-Abschnitt.

Zitat:

Zitat von Hansa

Was ist ein Doc/View Modell ?

Eine ausführliche Erklärung kann ich jetzt nicht geben. (Das Borland C++ 5.0 Handbuch braucht dafür 150 Seiten). Im Grunde handelt es sich bei diesem Model (nach dem auch die MFC aufgebaut wird) um eine Programmierart, bei der sämtliche Daten in einem Dokument zugeordnet werden. Das Dokument kümmert sich um die Aufbewahrung, um die Speicherung und um das Laden der Daten.
Um dieses Dokument zu bearbeiten oder anzuzeigen benötigt man ein View. Da man aber die Daten auf unterschiedliche Art und Weise darstellen kann. Z.B. in Tabellenform, in Textform oder als Graph, so können jedem Dokument mehrere Views zugeordnet sein.

[Hansa]

Hier ist mal ein lustiger Link zu TP 5.5 mit Lizenzbedingungen:

http://community.borland.com/museum/

Zitat:

Zitat von BORLAND

These historical files are provided to the Borland community free of charge. They may be downloaded and used "as is" for personal use only. No developer support is provided. Each individual product contains copyright notices that are still in force. These files may not be made available via the Internet or any hard copy media (e.g. diskette, CDROM). We make no claims about Year 2000 compatibility for our antique software. If you have technical questions, you should ask the questions on our Internet newsgroups (there may be someone who remembers these old tools).

[CalganX]

Um mal zurück zum Thema zu kommen: nur weil wir nicht uns eigene Komponenten bauen, heißt das noch nicht, dass wir nicht die OOP verwenden. Ich selber nutze sie nicht, da ich sie nicht unbedingt gebrauchen kann...

Chris

[Hansa]

Zitat:

Zitat von Chakotay1308

...heißt das noch nicht, dass wir nicht die OOP verwenden. Ich selber nutze sie nicht, da ich sie nicht unbedingt gebrauchen kann...

Na was denn nun ? :chat: Benutzen oder nicht ? Kennt man nur den Ausdruck und weiß nicht, was dahinter steckt, kann man es sowieso nicht selber richtig nutzen. Dabei benutzt jeder das, ohne es zu wissen. Aber anscheinend sind sich nur wenige der Bedeutung bewußt, was man damit machen kann. Und das hat mich doch sehr verblüfft.

Wie wärs denn mal, statt Tlabel den Typ TTransparentLabel (z.B. für die Spiele-Programmierer) zu benutzen, z.B. mit der property Graustufung? Einfach nur dadurch, diese auf die Form zu legen und die Graustufung festzulegen ? Gut, das wäre eine eigene Komponente, aber wer hindert einen daran die Komponente um diese eine Eigenschaft zu erweitern ? Wahrscheinlich ist da nur eine Handvoll Code einzutippen.

Aber statt dessen wird von Hand zu Fuß bei jedem Label mühsam die Farbe geändert. Delphi selbst ist doch genau für solche Sachen entworfen und nur wenige nutzen das. Und das ist ein großer Fehler. Soll ich jetzt vor Ehrfurcht erstarren, nur weil es gelungen ist eine Komponente etwas umzubauen und sie im OI zu integrieren ?

[Daniel B]

Zitat:

Zitat von Hansa

Aber statt dessen wird von Hand zu Fuß bei jedem Label mühsam die Farbe geändert. Delphi selbst ist doch genau für solche Sachen entworfen und nur wenige nutzen das. Und das ist ein großer Fehler. Soll ich jetzt vor Ehrfurcht erstarren, nur weil es gelungen ist eine Komponente etwas umzubauen und sie im OI zu integrieren ?

Vielleicht kannst Du mal ein kleines Tutorial schreiben, wie man Standard-Komponenten um irgend eine Eigenschafft erweitern kann. Ich denke das so ein Bespiel für viele sehr brauchbar, um den ersten Schritt zu wagen sowas selbst zu machen.

Grüsse, Daniel :hi:

[Christian Seehase]

Moin Daniel,

im Prinzip hast Du das schon getan, wenn Du nur, z.B., einen Button auf ein Formular gelegt hast.

Dann hast Du eine Standard Kompo (TForm) erweitert (eben um einen Button).

[Daniel B]

Zitat:

Zitat von Christian Seehase

im Prinzip hast Du das schon getan, wenn Du nur, z.B., einen Button auf ein Formular gelegt hast.
Dann hast Du eine Standard Kompo (TForm) erweitert (eben um einen Button).

Das ist schon Klar.
Ich meinte eher z.B. ein Button um die Eigenschaft, äähm, Blinking zu erweitern. Stellt man das auf True, dann blinkt das blöde Ding zur RunTime. Aber das geht eher in richtung Komponentenentwicklung.

Grüsse, Daniel :hi:

[Hansa]

Zitat:

Zitat von Daniel B

...um den ersten Schritt zu wagen sowas selbst zu machen.

Gut gesagt, vor so etwas gibt es seltsamerweise anscheinend etwas Angst. :mrgreen: Aber völlig unbegründet. Ich glaube aber mittlerweile, daß das Prinzip weder in der Anwendung weit verbreitet ist, noch viele wissen, daß so etwas relativ einfach geht und definitiv das Grundgerüst von Delphi selbst darstellt. 8)

Zitat:

Zitat von Daniel B

...äähm, Blinking zu erweitern. Stellt man das auf True, dann blinkt das blöde Ding zur RunTime. Aber das geht eher in Richtung Komponentenentwicklung.

Tutorial? Da gibts wirklich nicht viel. Ist alles meist zu knapp erklärt. Die Delphi-Hilfe sagt auch nicht viel. Selber schreiben ? Dann müßte ich bei Adam und Eva anfangen und bin selber erst im Jahr 1800tubak. Ein narrensicheres Beispiel müßte auch noch herhalten. Das Blinken wäre schon zu kompliziert (Timer). Aber ich mache trotzdem folgendes : ich erstelle irgendeinen komischen Button. Der wird abgeleitet von einem normalen Button, erhält aber noch die Eigenschaft ??? Dann schieb ich das Ding noch neben den normalen Button in die Komponentenpalette und erkläre das dann eben Schritt für Schritt. Das geht aber wohl nicht in einem tag.

[Daniel B]

Hallo Hansa,

vielleicht was ohne Timer, ein Toggel-Funktion.
Im OI als Toggle, mit True und False.
Ist das Ding auf True, und wird geklickt, so bleibt der gedrückt und man muss nochmal drauf klicken, damit er wieder rauskommt. Irgend ne globale Variabel oder sowas, anhand man der erkennen kann, welchen Zustand das Ding gerade hat. Im prinzip wie ein CheckBox.

Grüsse, Daniel :hi:

[Hansa]

Zitat:

Zitat von Daniel B

...ein Toggel-Funktion. Im OI als Toggle, mit True und False.

Etwas schwerer kanns doch wohl sein, oder ? Die Erklärung dazu muß halt schon wasserdicht und verständlich sein, damit keiner Angst kriegt. :witch: Und am besten mach ich das scheibchenweise, um selber durchzublicken. 8)

[APP]

Hallo, nach so vielen Kommentaren (die alle hochinteressant sind) möchte ich nun auch noch meinen Senf dazugeben.

Das mit der OOP ist so eine Sache, ich habe schon zig Bücher und Tutorials (z.B. auch das vom ComputerBild oder auf OOP-Tutorial (delphi-treff.de) dazu gelesen und verstehe grundsätzlich auch, was damit gemeint ist.

Ich erstellte kürzlich eine eigene Komponente, schaute im Netz nach wie das Andere machen, bat auch Euch um Hilfe (was vorzüglich klappte) aber kann ich jetzt auch OOP?
Ich denke nein, ich benutzte einfach schon vorhandenes und baute es bei meiner Komopnente ein (z.t. auch nach dem Motto Trial and Error).

Ich meine einfach, bei mir hat es noch nicht 'KLICK' gemacht, damit ich alles durch die OOP-Brille sehe, ich schreibe meine Datenbankschnittstellen und Tools nach wie vor ohne (sagen wir, wissentlich ohne) OOP, was ich eigentlich schade finde.
Das ist vielleicht auch ein Problem, wenn man Autoditakt ist :cry:

[EDIT]
p.s. Natürlich habe ich nun gelernt, eine bestehende Komponente nach meinen Bedürfnissen umzubauen, aber ich meine das ist wohl nur ein kleiner Bereich beim OOP, denn das was jbg auf Seite 1 macht könnte ich nicht :?
[/EDIT]

Aber vielleicht kann mir jemand sagen, wie man Probleme erkennt die OOP fähig sind (damit es endlich 'KLICK' macht), oder kann man das nicht lernen?

[Hansa]

Zitat:

Zitat von APP

...ist so eine Sache, ich habe schon zig Bücher und Tutorials ...

Das Problem ist wirklich, daß das keiner richtig erklärt. Schon schlimm, daß man da auf TP 5.5 zurückgreifen muß. Habe mal im Original-Delphi6 Handbuch nachgesehen und ehrlich gesagt, wüßte ich nicht sowieso, um was es geht, verstehen würde ich das nicht.

Zitat:

Aber vielleicht kann mir jemand sagen, wie man Probleme erkennt die OOP fähig sind (damit es endlich 'KLICK' macht), oder kann man das nicht lernen?

Die wichtigsten Begriffe in OOP sind Vererbung und Erweiterbarkeit. Angenommen Du hast einen Button, den willst Du um irgendeine Methode verfeinern. Baust Du Dir dann mit Rectangle usw. einen neuen zusammen ? Nein, du gehst doch besser hin und baust eine Methode dazu ein, die Du brauchst. Alles andere erbt DEIN Button von TButton. Und TDeinButton kannst Du dann weiterreichen an TDeinSpezialButton, der wiederum eine neue Methode besitzt und ansonsten alles von TDeinbuttom "erbt", incl. der in der in TButton sowieso vorhandenen Eigenschaften.

Du hast dann letztenendes den Standard-TButton um die Methode xyz erweitert und erbst die Eigenschaften von TButton, die sowieso vorhanden sind. TDeinSpezialButton erbt logischerweise alle Eigenschaften von Tbutton zuzüglich der in TDeinButton neu eingeführten Methode.

Wenn Du das dann noch in den OI und die Komponentenpalette eingebaut kriegst, ja das war dann alles.

OOP eignet sich also vorzüglich, wenn man einigermaßen zufrieden mit einer Komponente ist, sie aber trotzdem in ein spezielles Projekt nicht 100%ig paßt. Auf deutsch : man muß das Rad nicht komplett neu erfinden. Hoffentlich versteht das jemand. Trivial ist das ganze nämlich nicht.

[Mirilin]

Also, in diesen Büchern steht teils mehr, teils weniger:

• Turbo Pascal 7.0 Das Kompendium : Kapitel 15, Seite 397
• Delphi 4 Developper's Guide : Kapitel 2, Seite 91
• Delphi 4 Unleashed : Irgendwo in der Mitte und am Rand
• Delphi 4 in 21 Days : Kapitel 1, Seite 14

Diejenigen, die die Bücher haben - werde ja wohl nicht nur ich sein - können dort nachlesen, falls sie wollen.


Ps : Ratespiel : Welche Delphi-Version besitze ich (nicht schummeln!) :D

[X-Dragon]

Zitat:

Zitat von Hansa

...
Die wichtigsten Begriffe in OOP sind Vererbung und Erweiterbarkeit. ...

Nach der Definiton, verwenden eigentlich alle Delphi-Programmierer OOP, wenn vielleicht auch unbewußt. Viele der Komponenten die verwendet werden, haben irgendwelche Eigenschaften/Methoden von einer "Standardkomponte" geerbt.

Schaut euch doch z.B. in der Delphi-Hilfe die Komponente TEdit an. Dort gibts ein Punkt der nennt sich Hierarchie, wo genau aufgelistet ist auf welchen Komponenten TEdit basiert.

Also wer schafft es da noch kein OOP in seinen Programmen zu verwenden? :)

Ok, es gibt mit Sicherheit noch viele Möglichkeiten von man es sinnvoll einsetzen kann, aber meistens ist dafür eine gründliche vorherige Planung notwendig, und zumindest ich hab selten Zeit (und Lust :)) ein Programm erstmal genau durchzuplanen.

Selbst wenn man mal ein paar grundsätzliche Dinge für ein Programm plant, passiert es auch zu oft, das man dies wieder über einen Haufen werfen kann und man wieder alles umkrempeln muss. Also zumindest nach meiner Erfahrung gibt da doch einen zu großen Unterschied zwischen Theorie (von wegen Struktogramme und so) und Praxis.

@Mirilin
Delphi 4? Steht auch immer links neben deinem Beitrag :spin: .

[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 :shock:

[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 :wink: ) 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! :wink: :bouncing4:

[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:

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. :mrgreen: 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:

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