Hallo,
ich bin von Hause aus leider kein Programmierer/Informatiker und soll hier erklären, was man unter dem Schlagwort „objektorientierte Programmierung“ versteht. Nun habe ich schon etliche Foren und Seiten besucht, aber konnte leider nirgends eine Erklärung für nicht Informatiker finden.
Nun wollte ich mich hier mal Erkundigen, ob irgendjemand mir mit einfachen und verständlichen Worten erklärenkann, was man darunter versteht!
Besten Dank
Hallo!
Wikipedia sagt:
Objektorientierte Programmierung (OOP) ist ein Verfahren zur Strukturierung von Computerprogrammen, bei dem zusammengehörige Daten und die darauf arbeitende Programmlogik zu Einheiten zusammengefasst werden, den sogenannten Objekten.
Zumindest konzeptionell arbeitet ein Programm dann nicht mehr (wie bei der prozeduralen Programmierung) so, dass sequentiell einzelne Funktionsbereiche eines Algorithmus durchlaufen werden, der dabei eine Anzahl Daten verändert, sondern die Programmlogik entfaltet sich in der Kommunikation und den internen Zustandsveränderungen der Objekte, aus denen das Programm aufgebaut ist.
Vorteile der objektorientierten Programmierung liegen in der besseren Modularisierung des Codes, dadurch bedingt in einer höheren Wartbarkeit und Wiederverwendbarkeit der Einzelmodule, sowie in einer höheren Flexibilität des Programmes insgesamt, insbesondere in Bezug auf die Benutzerführung, da Programme dieser Art weniger stark gezwungen sind, dem Benutzer bestimmte Bedienabläufe aufzuzwingen.
Eine bessere/andere Erklärung kann ich leider auch nicht bieten!
Gruß
Florian
http://www.fs-it-online.de
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hi,
die u.g. Erklärung aus Wikipedia finde ich immer nocht recht kompliziert…
Hier ein Versuch einer noch simplereren Erklärung:
Wesentlich bei der OOP ist, daß Daten und Code zu einer Einheit zusammengefaßt werden. Diese Zusammenfassungen nennt man „Objekte“. Es soll sich an unserer gewohnten Sicht der Welt orientieren, wo wir ja auch mit „Objekten“ umgehen. So ist das Gewicht einer Banane eine Eigenschaft eben dieser Banane und kein Datum, welches losgelöst von der Banane existiert. Weitere Eigenschaften (die von Interesse sein könnten) sind dann zB. Reifegrad, Zustand, „Schale“ (ja/nein), usw. Nicht-OO programmiert wären diese „Eigenschaften“ simple Variablen im Programm, die im prinzip überall (im Programm) beliebig geändert werden könnten. Vieles macht aber keinen Sinn. So ist es eigentlich unsinnig, den Reifegrad zu verringern oder eine Schale, die bereits weg ist, wieder „hinzuzaubern“. In der OOP sind nun diese Eigenschaften programmtechnisch mit Code verbunden, über welchen die Werte dieser Eigenschaften abgefragt bzw. geändert werden können. Solche Objekt-bezogenen Prozeduren nennt man Methoden (und die Objekt-bezogenen Variablen nennt man Felder).
Das schöne an der OOP ist zum einen, daß ein Programmierer das Objekt benutzen kann, ohne dass er wissen muß, wie das Objekt im Inneren aussieht und funktioniert. Wenn der Programmierer die Methode „Schälen“ eines Bananen-Objekts aufruft, so sorgt die Methode dafür, dass das Feld „Schale“ zB. korrekt auf FALSCH gesetzt wird und evtl. noch das Gewicht um das Gewicht der Schale reduziert wird. Zum anderen kann ein Programmierer ein bereits programmiertes Objekt hernehmen und ihm neue, zusätzliche Eigenschaften verpassen. Das nennt man Vererbung: Das neue Objekt erbt quasi alles vom „Vorgänger“ und kann um neue Eigenschaften erweitert werden. Aus unserem Bananen-Objekt könnten wir so ein „Chiquitabananen“-Objekt machen, was die neuen Eigenschaften „Herkunftsland“ und „Aufkleber“ haben soll. Ein anderer kommt auf die Idee, Zierbananen zu entwickeln, welche die weiteren Eigenschaften „Farbe“ und „Muster“ usw. haben. Durch OOP läßt sich also Programmcode praktisch „weiderverwenden“ bzw. einfach erweitern, ohne daß der Programmierer den bereits existierenden Code kennen müßte und ohne daß mit den Erweiterungen alte funktionierende Programmteile „zerschossen“ werden könnten. Übrigends kann man natütlich im Computer auch abstrakte „Objekte“ definieren, also zunächst mal ein Objekt „Frucht“ zB., mit den Eigenschaften Größe, Gewicht, Wassergehalt, Reifegrad, Anzahl Keimanlagen etc. Von „Frucht“ kann man dann Objekte wie „Getreide“ und „Obst“ ableiten, von Obst wiederum „Beere“, „Nuss“, usw. immer mit den jeweils typischen Eigenschaften.
Übrigends nennt man die Definitionen von Objekten „Klassen“. Die oben als Objekt bezeichnete Banane ist also eigentlich eine Klasse „Banane“ und das gelbe Ding, das geade bei mir hier auf dem Schreibtisch liegt, ist eine Instanz dieser Klasse, ein Banenen-Objekt. Das soll dich aber nicht verwirren. Den Unterschied zwischen
Klasse und Objekt braucht man nicht (unbedingt), um das Konzept der OOP grob zu verstehen.
LG
Jochen
Hallo knut747
ich bin von Hause aus leider kein Programmierer/Informatiker
und soll hier erklären, was man unter dem Schlagwort
„objektorientierte Programmierung“ versteht. Nun habe ich
schon etliche Foren und Seiten besucht, aber konnte leider
nirgends eine Erklärung für nicht Informatiker finden.
Programmierer sind faule, aber schlaue Leute. Wenn
ein Programmierer einmal nächtelang an einem Stück
Code gearbeitet hat, dann möchte er diesen Code
gerne auch in einem späteren Programm wiederverwenden.
Dem stehen mehrere Schwierigkeiten entgegen.
so ein Code ist meistens lang. Nach zwei Wochen hat
der Programmierer beinahe immer vergessen, worum es
eigentlich ging und wie es funktioniert
der Code wird ja im aktuellen Programm verwendet
und hängt daher mit dem aktuellen Programm zusammen,
verwendet dessen Variablen und liefert bestimmte Werte,
die für den aktuellen Code wichtig sind. Um den Code neu
zu verwenden, muss sich der Programmierer daran erinnern,
was zum eigentlichen Code gehört und was zum Restprogramm.
Das ist nach 6 Monaten oft unmöglich. Oder man hat keine
Lust dazu.
wenn der Code dann ins neue Programm übertragen wird,
vergisst der Programmierer, dass z.B. eine ganz wichtige Zahl
am Anfang des alten Programms immer unbedingt auf 5.25 gesetzt
werden musste, damit der Code funktioniert.
Nach 3 Jahren Programmiertätigkeit hat der Programmierer
in 5 Projekten 5 Varianten dieses Codes eingebaut, die alle
etwas anders aussehen. Es funktionieren aber alle nur manchmal,
der Programmierer hat vergessen, welcher Code wann richtig
funktioniert.
Nun wollte ich mich hier mal Erkundigen, ob irgendjemand mir
mit einfachen und verständlichen Worten erklärenkann, was man
darunter versteht!
Die ganze Programmiererei ist auch einer Evolution
unterworfen. Es bleibt am Ende genau das übrig, was
sich in der realen Welt stark genug bewährt hat.
Aufgrund der obigen Schwierigkeiten beginnt jeder
Programmierer irgendwann auf die eine oder andere
Art, seine Programmierfunktionalität, die er geschaffen
hat, abstrakt umzuformen (weil er die og.
leidvollen Erfahrungen gemacht hat).
D.h., er findet heraus, dass er mit dem eigenen Code
auch später noch gut klar kommt, wenn er folgende Ei-
genschaften hat:
Aus diesen Punkten ist die Richtung schon erkennbar.
So ein „abgeschottetes“ Stück Code heisst dann auf
„neuinformatikerisch“ eben ein „Objekt“.
„Objektorientiert Programmieren“ bedeutet dann nicht
mehr und nicht weniger, als dass man sich das Leben
auf o.g. Weise leichter macht.
Die Schwierigkeit dabei ist - bereits am Anfang
der Programmiererei zu wissen, was später mal
ein „Objekt“ sein soll und was nicht. Das erfordert
grosse Erfahrung, ist eine „Schwarze Kunst“.
Daher ist es auch o.k., wenn man erstmal die „Objekte“,
die andere Leute programmiert haben, in seine eigenen
Projekte einbaut. Nicht-Gurus arbeiten auf diese Weise
ihr ganzes Leben - und sie leben gut damit 
Wenn du verstanden hast, worum es geht, wirst Du
auch die vielen Beispiele verstehen, die Dir die
anderen in diesem Thread genannt haben.
Grüße
CMБ
Auch hallo.
Der Ansatz des „Objektorientierten Programmieren“ (kurz OOP genannt) versucht reale Objekte der realen Welt mit all ihren Eigenschaften, Methoden, Attributen,… im Computer abzubilden. Wurde ja auch schon erwähnt. Allerdings ist OOP (C++, Java, C#,…) für Leute ohne richtigen Hintergrund im prozeduralen Programmieren (Basic, Pascal, COBOL,…) schon ein hartes Stück Brot.
Nun denn, unter http://www.jeckle.de/vorlesung/sei/kII.html findet sich noch weiteres Futter. Oder hier: http://www.oose.de/artikel.htm
HTH
mfg M.L.
***freu, freu***
BIW @ SAP WAS 6.40 RC1 erfolgreich aktiviert. War gar nicht so schwer…
Hi CMБ,
nette Erklärung. Jetzt verstehe ich aber erst recht nicht, warum VB nicht als Objektorientierte Sprache gilt. Deine Beschreibung trifft zu 100% auf die ‚Module‘ in VB zu.
Gruß, Rainer
Hi CMБ,
nette Erklärung. Jetzt verstehe ich aber erst recht nicht,
warum VB nicht als Objektorientierte Sprache gilt. Deine
Beschreibung trifft zu 100% auf die ‚Module‘ in VB zu.
Du meinst sowas?
http://www.terrashop.de/RW61215A/artikel.php
Die ganze objektorientiererei ist ein starkes
Paradigma und hat irgendwie auch in anderen
Sprachen Einzug gehalten, die aber dieses
ursprünglich nicht unterstützten oder
förderten. Und dazu zählt eben Basic.
Andere Sprachen wurden schon im Hinblick
auf Objekte entworfen. Das sind dann
„objektorientierte“ Sprachen
Grüße
CMБ
Hi CMБ,
Du meinst sowas?
im Prinzip ja, aber … Ich habe immer noch die Vorgängerversion.
Die ganze objektorientiererei ist ein starkes
Paradigma und hat irgendwie auch in anderen
Sprachen Einzug gehalten, die aber dieses
ursprünglich nicht unterstützten oder
förderten. Und dazu zählt eben Basic.Andere Sprachen wurden schon im Hinblick
auf Objekte entworfen. Das sind dann
„objektorientierte“ Sprachen
aahhhhh, OK, jetzt habe sogar ich das verstanden.
Danke!
Gruß, Rainer
„objektorientierte Programmierung“ versteht
Nun wollte ich mich hier mal Erkundigen, ob irgendjemand mir
mit einfachen und verständlichen Worten erklärenkann, was man
darunter versteht!
Hallo
Der Beginn der objektorientierten Programmierung ist eigentlich die Zulassung von benannten Datenobjekten mit Eigenschaften und die Verwendung von Punktoperatoren für die einzelnen Eigenschaften des Daten-Objektes.
Das Beispiel mit „Banane“ beschreibt es ganz gut.
Es gibt auch Code-Objekte, die sich instanzieren lassen, das bedeutet die bereits beschriebene Wiederverwendbarkeit von Code innerhalb eines Programmes.
Beispiel:
Programm A ist ein Datenserver.
Es hat beim Starten einen Code um einen einzelnen Clienten zu bedienen.
Um mehrere Clienten zugleich zu bedienen, muß der Code mehrfach gestartet werden.
Ist ein Codeobjekt fertig, beendet es sich z.B. selbst.
Solche Objekte können ganz verschiedeartig komplex sein und zum Beispiel untereinander kommunizieren, aber es ist eigentlich schon das Gegenteil zu einem Code beschrieben, welcher nicht objektorientiert ist. Einer der zugeordneten Begriffe lautet z.B. „Multitier“.
MfG
Matthias
Hi!
Erstmal *schauder*, dass hier überlegt wird, VB als objektorientierte Sprache anzusehen. 
Die obige Erklärung ist zwar sehr verständlich, auch für fachfremde Leser, beschreibt aber eigentlich nur die prozedurale Programmierung in Moduln.
Zu OOP gehört das zwar auch (Stichwort „Kapselung“), aber eben auch andere wichtige Sachen wie z.B. Vererbung und Polymorphie.
Ich versuch’ die 2 Sachen auch noch einfach zu erklären:
Beides sind Autos, auch wenn sie sich im Detail unterscheiden.
Nun können Klassen auch von einander erben, d.h. die Kind-Klasse übernimmt alle Eigenschaften und Funktionalitäten der Vaterklasse und fügt u.U. noch weitere hinzu, die dann eben NUR auf die Kind-Klasse zutreffen.
Beispiel: Die Klasse „Cabriolet“ erbt von „Auto“ und bietet neben den ganzen Sachen, die jedes Auto kann (Gas geben, Bremsen, …) zusätzlich noch die Möglichkeit, das Verdeck auf- und zuzuklappen.
Das kann man beliebig tief schachteln.
Beispiel: Klasse „Geometrisches Objekt“, davon abgeleitet „Kreis“ und „Rechteck“.
„Geometrisches Objekt“ hat eine Methode „Berechne Fläche“, der Kreis wird hier „a = r^2 * PI“ rechnen/zurückgeben, das Rechteck rechnet „a = b * h“ und gibt das zurück.
Damit kann ein Programm einfach generell nur mit „Geometrischen Objekten“ arbeiten und bekommt immer die Gesamtfläche, egal, von welchem konkreten Typ das jeweilige Objekt ist.
Ich hoffe, das war einigermaßen verständlich, wenn nicht, dann melde Dich bitte.
Gruß,
Martin
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Martin,
Erstmal *schauder*, dass hier überlegt wird, VB als
objektorientierte Sprache anzusehen.
tja, für mich hat’s mit der Beschreibung zusammen gepasst.
Die obige Erklärung ist zwar sehr verständlich, auch für
fachfremde Leser, beschreibt aber eigentlich nur die
prozedurale Programmierung in Moduln.
Zu OOP gehört das zwar auch (Stichwort „Kapselung“), aber eben
auch andere wichtige Sachen wie z.B. Vererbung und
Polymorphie.
Jetzt kommen die Teile, die ich noch nicht verstehe.
Weil ich aber die Absicht habe, C++ zu lernen, wäre das von Vorteil.
Ich versuch’ die 2 Sachen auch noch einfach zu erklären:
- Vererbung:
Die bereits erwähnten Objekte haben jeweils einen Typ, der
Klasse genannt wird.
Z.B. können die Objekte „Porsche 911 Carrera“ und „Trabant
501“ konkrete Ausprägungen (sog. „Instanzen“) der Klasse
„Auto“ sein.Beides sind Autos, auch wenn sie sich im Detail unterscheiden.
Nun können Klassen auch von einander erben, d.h. die
Kind-Klasse übernimmt alle Eigenschaften und Funktionalitäten
der Vaterklasse und fügt u.U. noch weitere hinzu, die dann
eben NUR auf die Kind-Klasse zutreffen.
Beispiel: Die Klasse „Cabriolet“ erbt von „Auto“ und bietet
neben den ganzen Sachen, die jedes Auto kann (Gas geben,
Bremsen, …) zusätzlich noch die Möglichkeit, das Verdeck
auf- und zuzuklappen.Das kann man beliebig tief schachteln.
Die ‚praktische‘ Erklärung habe ich so weit verstanden, auch wenn mich die ‚Vokabeln‘ immer noch verwirren. Was das für mich im Umgang mit der Entwicklungsumgebung der Programmiersprache bedeutet, wie ich damit umgehen muß, habe ich nicht verstanden.
Womit ich umgehen kann sind Module in VB, eventuell ist der unterschied da leicht zu finden. Ich habe z.B. ein Modul, mit dem ich Barcode so drucken kann, daß der gesamte Streifen immer gelich Breit ist, unabhängig von der Anzahl der Zeichen. In VB sieht das so aus:
BCD zl , 20 , 20
Auf dem Papier habe ich dann in der linken oberen Ecke ( 20 - 20 mm) den Barcode. Das Modul kann nichts anderes, als Zeichen in Barcode umzurechnen und an den Drucker zu senden.
was müßte ich mit C++ anders machen?
- Polymorphie:
Das hat damit zu tun, wie unterschiedliche Kind-Klassen
bestimmte Funktionalitäten einer Vaterklasse umsetzen. Die
Funktionalitäten („Methoden“) haben den selben Namen, bedeuten
auch das selbe, werden aber unterschiedlich behandelt.Beispiel: Klasse „Geometrisches Objekt“, davon abgeleitet
„Kreis“ und „Rechteck“.
„Geometrisches Objekt“ hat eine Methode „Berechne Fläche“, der
Kreis wird hier „a = r^2 * PI“ rechnen/zurückgeben, das
Rechteck rechnet „a = b * h“ und gibt das zurück.Damit kann ein Programm einfach generell nur mit
„Geometrischen Objekten“ arbeiten und bekommt immer die
Gesamtfläche, egal, von welchem konkreten Typ das jeweilige
Objekt ist.
Aber dem Programmteil muß ich doch sicher ‚sagen‘, um welche Art Geometrischer Form es sich handelt, sonst wird die Berechnung etwas schwierig.
Ich hoffe, das war einigermaßen verständlich, wenn nicht, dann
melde Dich bitte.
Ich melde mich gerade. Eigentlich hat Dein Beitrag bei mir eher Verwirrung gestiftet. Um C++ zu lernen sollte ich aber genau das verstehen, so viel ist mir schon klar geworden.
Danke für Deine Mühe,
Gruß, Rainer
Hallo Martin,
Hi nochmal.
[…]
auch andere wichtige Sachen wie z.B. Vererbung und
Polymorphie.Jetzt kommen die Teile, die ich noch nicht verstehe.
Weil ich aber die Absicht habe, C++ zu lernen, wäre das von
Vorteil.
Diese Konzepte haben mit konkreten Programmiersprachen noch nicht wirklich was zu tun. Man kann in C++ auch prima nicht-OO-programmieren, da schenken sich C++ und VB dann nichts.
Ich versuch’ die 2 Sachen auch noch einfach zu erklären:
- Vererbung:
[…]
was müßte ich mit C++ anders machen?
Klammern um die Argumente und einen Strichpunkt hinter die Anweisung
Darum geht’s aber eigentlich nicht.
Sondern z.B. darum, wie es gemacht wird, wenn Du unterschiedliche Barcode-Systeme unterstützen willst (da gibt’s ja meines Wissens nach etliche unterschiedliche). Oder verschiedene Drucker.
Momentan würdest Du vermutlich elends lange und hässliche if-then-else Abfragen oder switches einbauen.
Mit OO kannst Du definieren, dass Du eine Klasse Barcode hast, die die Funktion („Methode“) „Print“ anbietet. Davon abgeleitet gibt es dann z.B. für jeden Barcode-Typ eine eigene Kind-Klasse, die von Barcode erbt. Jede erbt auch die Standard-Implementierung von Print der Vaterklasse, kann diese aber auch überschreiben, um für die jeweilige Klasse die richtige Art von Barcode zu drucken.
In C++ beispielsweise wäre es dann in etwa so (bei … habe ich Teile ausgelassen):
class Barcode
{
...
virtual void Print(...)
{...}
}
class Barcode1 : public Barcode
{
...
virtual void Print(...)
{ ...hier wird der Barcode für Schema 1 gedruckt... }
}
class Barcode2 : public Barcode
{
...
virtual void Print(...)
{ ...hier wird der Barcode für Schema 2 gedruckt... }
}
und beim Aufruf hast Du dann nur noch:
Barcode \*bc;
switch (barcodeType)
{
case 1: bc = new Barcode1(); break;
case 2: bc = new Barcode2(); break;
}
bc->:stuck\_out\_tongue\_winking\_eye:rint(...);
Also der selbe Aufruf an die selbe Methode, je nach gewählter Klasse aber mit unterschiedlichem Ergebnis.
- Polymorphie:
[…]
Aber dem Programmteil muß ich doch sicher ‚sagen‘, um welche
Art Geometrischer Form es sich handelt, sonst wird die
Berechnung etwas schwierig.
Das wird beim Erstellen des jeweiligen Objekts gesagt (beim new im obigen Beispiel)
Ich hoffe, das war einigermaßen verständlich, wenn nicht, dann
melde Dich bitte.Ich melde mich gerade. Eigentlich hat Dein Beitrag bei mir
eher Verwirrung gestiftet. Um C++ zu lernen sollte ich aber
genau das verstehen, so viel ist mir schon klar geworden.Danke für Deine Mühe,
Gruß, Rainer
Gern,
Martin
Hallo Martin,
Zu OOP gehört das zwar auch (Stichwort „Kapselung“), aber eben
auch andere wichtige Sachen wie z.B. Vererbung und
Polymorphie.
Naja, es ist ja modern, diese vier Punkte
1 und 2 sind paradigmatisch, 3 und 4 untergeordnet.
„Vererbung“ ist ja eine triviale Sache, sie bedeutet
ja nur, dass man das vorhandene „Objekt“ in einem
neuen „Objekt“ wiederverwendet.
Bei 4 kann man sich streiten, gerade beim üblichen
dynamischen (Laufzeit-) Polymorphismus geht es ja nur
um eine technische Frage, nämlich wie man unterschied-
liche Objekte, die jeweils das gleiche vorhandene Objekt
(Basisobjekt) enthalten, über einen Kamm scheren kann.
Das kann man auch durch geeignete (nicht-polymorphe)
Container-Datentypen erreichen, die jeweils ein unter-
schiedliches „Unterobjekt“ enthalten.
Nun können Klassen auch von einander erben, d.h. die
Kind-Klasse übernimmt alle Eigenschaften und Funktionalitäten
der Vaterklasse und fügt u.U. noch weitere hinzu, die dann
eben NUR auf die Kind-Klasse zutreffen.
Beispiel: Die Klasse „Cabriolet“ erbt von „Auto“ und bietet
neben den ganzen Sachen, die jedes Auto kann (Gas geben,
Bremsen, …) zusätzlich noch die Möglichkeit, das Verdeck
auf- und zuzuklappen.
Das ist meiner Ansicht nach nicht 100% richtig. Es ist zwar
„irgenwie“ zutreffend, aber nicht wesentlich. Ich denke, das
wesentliche ist, dass diese Basisklasse „AUTO“ ein
konstantes Interface besitzt, welches nicht von
den späteren Ausprägungen der Autoentwicklung abhängig ist.
Spätere Autos können zwar zusätzliche Eigenschaften (Methoden)
besitzen (fliegen oder schwimmen), aber sie können immer noch
lenken und bremsen, wie von der Basisklasse bereitgestellt.
- Polymorphie:
Das hat damit zu tun, wie unterschiedliche Kind-Klassen
bestimmte Funktionalitäten einer Vaterklasse umsetzen. Die
Funktionalitäten („Methoden“) haben den selben Namen, bedeuten
auch das selbe, werden aber unterschiedlich behandelt.
Na ja
„Polymorphie“ leitet sich imho direkt aus der „Vererbung“ ab
und wird eben dadurch erforderlich, dass z.B. (in Deinem Beispiel)
verschiedene Autos verschiedene Motoren haben.
Wenn ich in einer Programmschleife z.B. „Motoren starten“
will, so ist eben für einen M1-A2 eine andere Routine
nötig als für einen Passat. Also bekommen in den
„vererbten“ Klassen für Panzer M1 und PKW Passat
die Motorstartfunktionen den selben Namen aber
unterschiedlichen Inhalt. Das Ziel dabei ist, eine
„generische Behandlung“ aller Fahrzeuge zu ermöglichen.
Beispiel: Klasse „Geometrisches Objekt“, davon abgeleitet
„Kreis“ und „Rechteck“.
„Geometrisches Objekt“ hat eine Methode „Berechne Fläche“, der
Kreis wird hier „a = r^2 * PI“ rechnen/zurückgeben, das
Rechteck rechnet „a = b * h“ und gibt das zurück.
o.k.
Grüße
CMБ
Hallo Rainer,
Beispiel: Klasse „Geometrisches Objekt“, davon abgeleitet
„Kreis“ und „Rechteck“.
„Geometrisches Objekt“ hat eine Methode „Berechne Fläche“, der
Kreis wird hier „a = r^2 * PI“ rechnen/zurückgeben, das
Rechteck rechnet „a = b * h“ und gibt das zurück.Damit kann ein Programm einfach generell nur mit
„Geometrischen Objekten“ arbeiten und bekommt immer die
Gesamtfläche, egal, von welchem konkreten Typ das jeweilige
Objekt ist.Aber dem Programmteil muß ich doch sicher ‚sagen‘, um welche
Art Geometrischer Form es sich handelt, sonst wird die
Berechnung etwas schwierig.
Hier kommt das ins Spiel, was ich im anderen Posting auszudrücken
versuchte. Das Stichwort ist „generische Programmierung“.
Du schreibst z.B. eine FOR-Schleife über „generische“
geometrische Objekte in einem Feld/Array.
DIM GeoObject(100) As Object
...
GeoObject(1) = KREIS(4.0, 2.0, 20)
GeoObject(2) = DREIECK(4.0, 2.0, 3.0, 1.0, 2.0, 3.0)
GeoObject(3) = RECHTECK(4.0, 2.0, 6.0, 1.0)
Irgendwo im Programm willst Du wissen, welche Fläche
alle Deine geo-Objekte haben:
FOR i = 1 TO n
area = area + GeoObject(i).flaeche
NEXT i
d.h. ein Funktionsname für viele (polymorphe)
Objekte.
So gehts
Grüße
CMБ
Semjon,
die Frage war doch, was OOP ist.
Und da gehören nunmal die 4 Punkte dazu, unabhängig davon, ob Du sie als wichtig erachtest oder nicht.
Einem absoluten Neuling mit einfachen Worten in wenigen Zeilen zu erklären, was OO ist, ist sicherlich nicht einfach, aber die erforderlichen Punkte sollte man schon erwähnen.
Wenn es dann später mal ans Eingemachte geht, dann stellt sich eh’ viel mehr die Frage, ob es sich um gutes oder schlechtes OO-Design handelt.
Leider habe ich halt schon (viel zu) viele Leute gesehen, die meinten, weil sie jetzt von VB auf VB.NET oder von C auf C++/C#/Java umsteigen würden sie automatisch objektorientiert programmieren (hab einige Jahre als Trainer für SW-Entwicklungsmethoden gearbeitet).
Letztlich kam dann EINE Klasse „MeinOOSystem“ mit zig statischen (shared in VB) Methoden heraus. Funktionalität gekapselt: irgendwie schon, OO: NEIN.
Es wird schlicht der alte Stiefel weiter gemacht, nur unter neuem Namen.
Damit OO funktioniert muss auch im Denken was passieren. Dieses Wissen zu vermitteln ist aber m.M. nach nicht in 10 Zeilen www-Artikel möglich. Die nötigen Begriffe zu erwähnen und kurz zu erläutern, damit der geneigte Leser sich damit weiter bilden kann, schon.
Martin
Hallo CMБ,
Hier kommt das ins Spiel, was ich im anderen Posting
auszudrücken
versuchte. Das Stichwort ist „generische Programmierung“.
Du schreibst z.B. eine FOR-Schleife über „generische“
geometrische Objekte in einem Feld/Array.DIM
GeoObject(100) As Object
…
GeoObject(1) = KREIS(4.0, 2.0, 20)
GeoObject(2) = DREIECK(4.0, 2.0, 3.0, 1.0, 2.0, 3.0)
GeoObject(3) = RECHTECK(4.0, 2.0, 6.0, 1.0)Irgendwo im
Programm willst Du wissen, welche Fläche
alle Deine geo-Objekte haben:FOR i = 1 TO n
area = area + GeoObject(i).flaeche
NEXT id.h. ein Funktionsname für viele (polymorphe)
Objekte.
Verstanden! Danke!
Gruß, Rainer
Hallo Martin,
danke, ich hab’s so weit verstanden. Das ist für mich immer noch ein wenig abstrakt, aber das weitere Verständnis bringt dann wohl die Praxis.
Gruß, Rainer