Mir fehlt glaube ich das Verständnis......

[webba]

Hallo,

immer wieder hört man wenn man über das Programmieren redet von Objekt Orientierte Programmierung.
Ich habe diese OOP mal unter die Lupe genommen und folgendes festgestellt:
Wenn ich nun mit einer Klasse einen Mensch beschreiben sollte dann so:

Klasse: Mensch

Eigenschaften:
z.B
------------------------------
-Größe
-Alter
-Hautfarbe
-Haarschnitt
-Augenfarbe
-Geschlecht

Methoden:

-Laufen
-Sprechen
-Schlafen
-Benehmen

etc.

---------------------------------

Die eigenschaften können ja Variablen sein in dem die Werte gespeichert werden.
Methoden sind ja mehr oder weniger Funktionen.

Aber was habe ich davon?
Nur weil ich von der Klasse eine Instanz erstellen kann?

Was bringt mir das OOP in der Praxis?
Mir fällt kein wirklicher grund ein aus alles eine Klasse zumachen?

Währe schön wenn mir da so einer ein paar Tips geben kann wie man sowas auch in der Praxis gebrauchen kann.

Danke schonmal!

[_roro]

Hallo,

immer wieder hört man wenn man über das Programmieren redet von Objekt Orientierte Programmierung.
Ich habe diese OOP mal unter die Lupe genommen und folgendes festgestellt:
Wenn ich nun mit einer Klasse einen Mensch beschreiben sollte dann so:

Klasse: Mensch

Sorry, Du bist hier bereits bei einem Objekt angelangt, was aus der Klasse der Tiere abgeleitet wurde.

Leider hat das Objekt Mensch nicht alle Eigenschaften und Methoden geerbt, die ein gutes Tier ausmachen.

SCNR, Rolf

[Johannes Zeller]

Hallo Rolf,

Sorry, Du bist hier bereits bei einem Objekt angelangt, was aus der Klasse der Tiere abgeleitet wurde.

Leider hat das Objekt Mensch nicht alle Eigenschaften und Methoden geerbt, die ein gutes Tier ausmachen.

Seit wann kann man Objekte aus Klassen ableiten?

Grüße,

Jo*scnr*hannes

[stareagle]

Hallo,

immer wieder hört man wenn man über das Programmieren redet von Objekt Orientierte Programmierung.

Das ist das im Moment vorherrschende Programmierpradigma.

Ich habe diese OOP mal unter die Lupe genommen und folgendes festgestellt:
Wenn ich nun mit einer Klasse einen Mensch beschreiben sollte dann so:

Klasse: Mensch

Eigenschaften:
z.B

-Größe
-Alter
-Hautfarbe
-Haarschnitt
-Augenfarbe
-Geschlecht

Methoden:

-Laufen
-Sprechen
-Schlafen
-Benehmen

etc.

---

Die eigenschaften können ja Variablen sein in dem die Werte gespeichert werden.
Methoden sind ja mehr oder weniger Funktionen.

Ist so korrekt.

Aber was habe ich davon?
Nur weil ich von der Klasse eine Instanz erstellen kann?

Nein, die Stichworte heißen Modularisierung, Kapselung und derer anderer.

Mehr findest du z.B. in der Wikipedia.

Was bringt mir das OOP in der Praxis?

Ein - wenn es gut gemacht wird - gut strukturiertes, gut wartbares Programm.

Mir fällt kein wirklicher grund ein aus alles eine Klasse zumachen?

Du solltest in der Wikipedia (oder in einer andreren Quelle deiner Wahl) mal nach Programmierpradigma suchen. Es gibt nämlich nicht nur die OOP. Es gibt auch die aspektorientierte Programmierung (eine Erweiterung der OOP), die funktioniale und die logische Programmierung.

Das OOP im Moment so "in" ist, liegt daran, dass man sie auch ohne Informatikstudium verstehen kann und man in ihr die meisten Probleme recht elegant lösen kann.

Gruß

Stareagle

[Der Martin]

n'Abend,

Das OOP im Moment so "in" ist, liegt daran, dass man sie auch ohne Informatikstudium verstehen kann ...

halte ich für ein Gerücht. Ich kenne sowohl die "klassische" prozedurale Programmierung (und fühle mich wohl dabei), als auch das Konzept der OOP. Und ich finde die objektorientierte Philosophie _wesentlich_ komplizierter als den klassischen linearen Ansatz.
Und auch die Menschen, denen ich bisher Grundzüge der Programmierung vermitteln wollte, hielten den OO-Ansatz durchweg für komplizierter gehalten als die traditionelle prozedurale Denkweise - und das waren teilweise Laien, die *keine* Ahnung/Erfahrung mit Programmieren hatten teilweise auch Leute, die schon Grundkenntnisse hatten.

und man in ihr die meisten Probleme recht elegant lösen kann.

Das streite ich nicht ab; vor allem gibt es Aufgaben, für die OOP geradezu prädestiniert ist. Aber es ändert nichts daran, dass man zu einem hohen Grad an Abstraktion fähig sein muss - so viel, dass man sich diese Denkweise erst mühsam aneignen muss, weil sie eben _nicht_ dem natürlichen  Alltagsdenken entspricht, auch wenn das immer wieder behauptet wird.

So long,
 Martin

[Christoph Schnauß]

hallo,

Ich kenne sowohl die "klassische" prozedurale Programmierung (und fühle mich wohl dabei), als auch das Konzept der OOP. Und ich finde die objektorientierte Philosophie _wesentlich_ komplizierter als den klassischen linearen Ansatz.

Das Problem scheint zu sein, daß manche meinen, in Ausschließlichkeiten denken zu müssen. Also: entweder OOP oder was andres - wobei das "andre" oftmals als weniger "elegant" oder "wertvoll" dargestellt wird. Eine solche Herangehensweise ist aber verkehrt.

Tatsächlich haben sich große "klassische" Sprachen wie C, Java und Perl sehr schwer getan, das Prinzip der Objektorientierung zu übernehmen. Auch in PHP ist es eigentlich erst mit PHP 5.x wirklich durchsetzbar. Man muß sich beim Entwickeln von Applikationen oder von Scripts erst einmal fragen, wie "groß" die Applikation bzw. das Script werden soll, also welche Aufgaben man ihm überhelfen möchte. Wenn feststeht, daß ein völlig neues CMS entwickelt werden soll, wird man sich für OOP entscheiden (müssen), aber ein einfaches Upload-Script kommt ganz gut mit einer "linearen" Scriptlogik aus und würde mit Objekten vermutlich nur überladen.

Und auch die Menschen, denen ich bisher Grundzüge der Programmierung vermitteln wollte, hielten den OO-Ansatz durchweg für komplizierter gehalten als die traditionelle prozedurale Denkweise

Ich übrigens auch (auch wenn _du_ mir da bisher nichts beizubringen gezwungen warst ;-)). Es bedarf eines ziemlich komplexen Verständnisses, um tatsächlich "in Objekten" denken und dann auch so schreiben zu können, und ich fühle mich noch immer nicht sehr wohl, wenn ich mich dem Dictum OOP unterwerfe.

vor allem gibt es Aufgaben, für die OOP geradezu prädestiniert ist.

Schön wärs, wenn du hier eine solche Aufgabe benannt hättest. Selbst ein Gästebuchscript in PHP verlangt nicht unbedingt, daß das zugrundeliegende Script OOP nutzt; ein PHP-Board dürfte das aber voraussetzen - und tut es in vielen im Internet eingesetzten PHP-basierten Boards ganz einfach nicht.

Aber es ändert nichts daran, dass man zu einem hohen Grad an Abstraktion fähig sein muss

Ich würde es nicht "Abstraktion" nennen, sondern "strukturelles Denken".

Grüße aus Berlin

Christoph S.

[Der Martin]

Hallo Christoph,

Das Problem scheint zu sein, daß manche meinen, in Ausschließlichkeiten denken zu müssen. Also: entweder OOP oder was andres - wobei das "andre" oftmals als weniger "elegant" oder "wertvoll" dargestellt wird. Eine solche Herangehensweise ist aber verkehrt.

Stimmt, erst eine ausgewogene Mischung im Sinne von "hier prozedural, dort OOP" macht's wirklich spannend.

Tatsächlich haben sich große "klassische" Sprachen wie C, Java und Perl sehr schwer getan, ...

Tatsächlich? Ich dachte immer, Java sei von Anfang an streng OO konzipiert gewesen. Mit C/C++ stimme ich allerdings zu; Perl kenne ich selbst nicht.

Und auch die Menschen, denen ich bisher Grundzüge der Programmierung vermitteln wollte, hielten den OO-Ansatz durchweg für komplizierter gehalten als die traditionelle prozedurale Denkweise
Ich übrigens auch (auch wenn _du_ mir da bisher nichts beizubringen gezwungen warst ;-)).

Das wäre vermutlich auch Eulen nach Athen tragen. ;-)
Obwohl ich mir vorstellen könnte, dass wir in völlig unterschiedlichen Bereichen wahrscheinlich viel voneinander lernen könnten.

vor allem gibt es Aufgaben, für die OOP geradezu prädestiniert ist.
Schön wärs, wenn du hier eine solche Aufgabe benannt hättest.

Oh, sorry - ich hatte da mal wieder das vielzitierte Beispiel eines fensterorientierten GUI vor Augen. Gerade für sowas gibt es ja eine ganze Reihe von OO-Klassenbibliotheken für die verschiedenen Compiler und Plattformen. Unter Windows dürfte vermutlich die MFC am bekanntesten sein.

Selbst ein Gästebuchscript in PHP verlangt nicht unbedingt, daß das zugrundeliegende Script OOP nutzt; ein PHP-Board dürfte das aber voraussetzen

Nein, "voraussetzen" würde ich das eben nicht, auch wenn es sicher sinnvoll erscheint. Dabei ist die Frage, ob man nicht viele traditionell programmierte Projekte irgendwie schon als OO einstufen sollte. Ich habe schon viele Win32-Applikationen in C auf API-Ebene gesehen, die waren so sauber und modular programmiert, dass man durchaus von OO sprechen könnte, auch wenn die speziellen Mechanismen von C++ nicht verwendet wurden und das Keyword "class" nirgendwo auftauchte.

Aber es ändert nichts daran, dass man zu einem hohen Grad an Abstraktion fähig sein muss
Ich würde es nicht "Abstraktion" nennen, sondern "strukturelles Denken".

Auch noch nicht optimal formuliert. Denn beides, Abstraktion und Struktur, kommt der traditionellen prozeduralen Programmierung ebenso zugute.

So long,
 Martin

[Christoph Schnauß]

hallo,

Tatsächlich haben sich große "klassische" Sprachen wie C, Java und Perl sehr schwer getan, ...
Tatsächlich? Ich dachte immer, Java sei von Anfang an streng OO konzipiert gewesen. Mit C/C++ stimme ich allerdings zu; Perl kenne ich selbst nicht.

Ich kann dir versichern, daß JAVA anfangs nix mit OOP am Hut hatte und das auch erst "lernen" mußte. JAVA war die allererste "Sprache", mit der ich mich vor vielen Jahren ausführlicher zu beschäftigen begonnen habe (und von der ich bis heute noch immer am wenigsten wirklich verstehe). Auch für Perl kann ich dir versichern, daß es sich so verhält, wie ich angegeben habe.

Obwohl ich mir vorstellen könnte, dass wir in völlig unterschiedlichen Bereichen wahrscheinlich viel voneinander lernen könnten.

Nicht unbedingt "voneinander", aber sicherlich "aneinander" ;-)

Aber es ändert nichts daran, dass man zu einem hohen Grad an Abstraktion fähig sein muss
Ich würde es nicht "Abstraktion" nennen, sondern "strukturelles Denken".
Auch noch nicht optimal formuliert. Denn beides, Abstraktion und Struktur, kommt der traditionellen prozeduralen Programmierung ebenso zugute.

Wenn es schon so schwierig ist, sich auf eine gemeinsame Begrifflichkeit zu verständigen, wie sollen wir dann versuchen, OOP an den Stellen, an denen sie vermutlich wirklich Sinn macht, zu erläutern?

Nur um richtig verstanden zu werden: ich spreche mich keinesfalls gegen OOP aus. Es gibt mittlerweile ganze "Projekte", in denen ich sie (vermutlich) umgesetzt habe - die gemeinsam mit Alexander Brock im ersten Halbjahr 2006 entwickelte Software der Zitatesammlung gehört dazu. Trotzdem hätte ich Schwierigkeiten, zu erklären, wieso das nun OOP geworden ist bzw. werden mußte.

Grüße aus Berlin

Christoph S.

[Christian Seiler]

Hallo Christoph,

Ich kann dir versichern, daß JAVA anfangs nix mit OOP am Hut hatte und das auch erst "lernen" mußte.

Und ich kann Dir versichern, dass Du Java gerade mit irgend etwas komplett anderem verwechselst. Java war von Anfang an objektorientiert, das war gerade eines der primären Entwicklungsziele von Java, ich zitiere mal James Gosling und Henry McGilton, The Java Language Environment, dort unter dem Abschnitt "Design Goals" (Entwurfsziele (!)) steht nämlich klipp und klar:

| The Java programming language is designed to be object oriented from the
| ground up.

Übersetzt auf Deutsch:

| Java wurde von Grund auf als objektorientierte Programmiersprache entworfen.

Und wenn Du Dir das Hello-World-Beispiel für Java ansiehst, dann wird sogar dafür eine Klasse verwendet, Java kann gar nicht ohne OOP auskommen (natürlich kann man vom Stil her in OOP auch prozedural programmieren, allerdings hat man trotzdem noch mindestens eine Klasse):

/**  
 * The HelloWorldApp class implements an application that  
 * simply prints "Hello World!" to standard output.  
 */  
class HelloWorldApp {  
    public static void main(String[] args) {  
        System.out.println("Hello World!"); // Display the string.  
    }  
}

Viele Grüße,
Christian

[Christoph Schnauß]

hallo Christian,

Java war von Anfang an objektorientiert, das war gerade eines der primären Entwicklungsziele von Java
| Java wurde von Grund auf als objektorientierte Programmiersprache entworfen.

Das Problem ist, daß Sun mit seiner "Geschichte" nicht korrekt umgeht. Es gibt eben nicht nur "Java 2". Ich habe mir 1995 ein ziemlich dickes und sündhaft teures Buch über Java gekauft (Addison Wesley), das einen Lizenzvermerk von Sun trägt und im Vorwort ausdrücklich auf OOP als "coming soon" aufmerksam macht.

Und wenn Du Dir das Hello-World-Beispiel für Java ansiehst, dann wird sogar dafür eine Klasse verwendet

Es ist eben nicht mehr das Beispiel, das es vor zehn Jahren einmal war. Im Übrigen bedeutet die Benennung von "class" noch lange nicht, daß damit von Anfang an eben die "Klassen" gemeint waren, die wir heute mit diesem Begriff verbinden.

(natürlich kann man vom Stil her in OOP auch prozedural programmieren, allerdings hat man trotzdem noch mindestens eine Klasse)

_Das_ war anfangs das Problem bei JAVA - allerdings eben vor einem Jahrzehnt. Unter Historikern könnte sich eine weiterführende Debatte lohnen, aber ich finde, wir sollten uns als Anwender verhalten und davon ausgehen, daß JAVA _heute_ eben ganz gut OOP kann.

Grüße aus Berlin

Christoph S.

[Biesterfeld]

Christoph,

Java war von Anfang an objektorientiert, das war gerade eines der primären Entwicklungsziele von Java
| Java wurde von Grund auf als objektorientierte Programmiersprache entworfen.

Das Problem ist, daß Sun mit seiner "Geschichte" nicht korrekt umgeht. Es gibt eben nicht nur "Java 2". Ich habe mir 1995 ein ziemlich dickes und sündhaft teures Buch über Java gekauft (Addison Wesley), das einen Lizenzvermerk von Sun trägt und im Vorwort ausdrücklich auf OOP als "coming soon" aufmerksam macht.

entweder versuchst du dich gerade ziemlich unnütz herauszuwinden oder aber in dem "sündhaft teuren Buch" stand Unfug drin. Kannst du bitte nachvollziehbare Quellen benennen die belegen, dass Java nicht seit dem ersten Tag als objekt-orientiert gedacht war? Könntest du uns bitte wenigstens den Titel des "sündhaft teueren Buches" nennen?

Beste Grüße
Biesterfeld

[Christoph Schnauß]

hallo,

entweder versuchst du dich gerade ziemlich unnütz herauszuwinden

I wo. Ich bin ein von grundauf aufrichtiger Typ.

Kannst du bitte nachvollziehbare Quellen benennen die belegen, dass Java nicht seit dem ersten Tag als objekt-orientiert gedacht war?

Nein, bedauerlicherweise nicht, jedenfalls nicht sofort und nicht online.

Könntest du uns bitte wenigstens den Titel des "sündhaft teueren Buches" nennen?

"Java programmieren in 21 Tagen" SAMS München 1996 (?). Ich habe es allerdings nicht mehr. Das älteste, das ich noch habe, ist "Java 1.2 programmieren in 21 Tagen", 1998 by SAMS München, ISBN 3-8272-2030-0. In dem wird nun allerdings bereits ausdrücklich darauf aufmerksam gemacht, daß JAVA objektorientiert sei. Ich habe mir lediglich handschriftlich auf der Cover-Seite vermerkt: "neu ist die Betonung der objektorientierten Programmierung gegenüber der vorausgegangenen Auflage, die von objektorientierter Programmierung noch nichts wußte (Begriffsklärung vonnöten und Überprüfung, was das praktisch bedeutet)". Ein zweifelhafter Eintrag - aber wenn du unbedingt willst, kann ich das auch noch scannen und hier hereinstellen. Es entsprach jedoch meinen damaligen Angewohnheiten, in Büchern auf der Cover-Seite ein paar grundlegende Bemerkungen zu notieren

Ich bedaure, daß ich selber da nicht exakter sein kann. Vor zehn Jahren habe ich aber Bücher noch fortgeworfen, wenn es neue Auflagen oder andere Bücher zum selben Thema mit neueren Inhalten gab. Würde ich heute nicht mehr tun.

Teuer waren die Bücher übrigens immer. Das letzte, das ich mir tatsächlich gekauft habe (ehe ich anfing, mir relevante Tutorials aus dem Internet zu holen), war "Java 2 mit Methode", 1999, Vaterstetten C&L, ISBN 3-932311-53-1. Es kostete 98 DM (Euro hatten wir damals noch nicht). Und 98 DM entsprachen ungefähr der Gesamtsumme an Lebensmitteln für einen vollen Monat. Daher habe ich beschlossen, mir nie wieder solche teuren Bücher zu kaufen. Und tatsächlich habe ich seit 2000 kein Buch mehr gekauft, das irgendwie mit dem Computer oder mit Programmiersprachen zu tun hat. Auch SELFHTML habe ich nie gekauft - besitze aber ein paar Buchausgaben verschiedener Versionen (die zum Teil immer noch in ihrer Plastikhülle eingeschweißt sind) ;-)

Es gibt seit ca. drei Wochen eine Absprache, daß rund 350 Kilo Bücher aus meinem Besitz schön kategorisiert als Schenkung an eine öffentliche Bibliothek übergehen sollen - einschließlich mehrerer Dutzend Jahrgänge von "Sinn und Form" (das war die Zeitschrift der DDR-Akademie der Künste, enorm wichtig mit einigen Texten, die sonst nirgends gedruckt werden konnten, und ich hatte die Zeitschrift seit 1970 abonniert und tatsächlich lückenlos geliefert bekomen), einiger Jahrgänge GEO usw. Wenn man 20 oder mehr Jahrgänge solcher Zeitschriften zuhause hat, ist das einerseits eine enorme Belastung für die Bücherregale, andrerseits aber auch ein ziemlich wertvoller kultureller Schatz. Dazu kommen dann auch noch etliche "teure" Bücher aus meiner Anfangszeit mit dem Rechner. Ich lese das alles nicht mehr nach, also ist es sinnvoll, den ganzen wertvollen Krempel in eine öffentliche Bibliothek zu überführen. Ich kriege einen zeitlebens gültigen kostenlosen Leseausweis dafür, und das reicht mir.

Grüße aus Berlin

Christoph S.

[Biesterfeld]

Hej,

Könntest du uns bitte wenigstens den Titel des "sündhaft teueren Buches" nennen?

"Java programmieren in 21 Tagen" SAMS München 1996 (?). Ich habe es allerdings nicht mehr. Das älteste, das ich noch habe, ist "Java 1.2 programmieren in 21 Tagen", 1998 by SAMS München, ISBN 3-8272-2030-0. In dem wird nun allerdings bereits ausdrücklich darauf aufmerksam gemacht, daß JAVA objektorientiert sei.

Du meinst so, wie es in der von mir bereits verlinkten Oak-Spezifikation getan wurde? Nur mal kurz zur Erinnerung, diese ist von 1994. Und um nochmal daraus zu zitieren:

"4 Classes

Classes represent the classical object oriented programming model."

Christoph ... gibs auf ,-)

Beste Grüße
Biesterfeld

[Christoph Schnauß]

hi,

Du meinst so

... wie ich es bereits geschrieben habe, ja.

Christoph ... gibs auf ,-)

Ich habe etwas dargestellt, was meinem Kenntnisstand entspricht. Da gibt es nix aufzugeben, es gibt allenfalls etwas zu revidieren. Wofür ich noch nicht ausreichend Hinweise gefunden habe.

Im übrigen sind wir uns hoffentlich darin einig, daß JAVA _heute_ selbstverständlich OOP kann und ich das auch nicht bestritten habe.

Grüße aus Berlin

Christoph S.

[Biesterfeld]

Hej,

Ich kann dir versichern, daß JAVA anfangs nix mit OOP am Hut hatte und das auch erst "lernen" mußte.

:-?
Also in der Oak Language-Spec. (*.ps, 250 kb) steht im Abschnitt 1.1

"At least one class per program must implement the main()-method."

Ferner behandelt die Spec die Kapitel Typen (5), Klassen (6) und Interfaces (7). Ähm, was sagtest noch genau, was du unter OOP verstehst?

Nur mal so in Ergänzung zu Christian hinterherschieb.

Beste Grüße
Biesterfeld

[Christoph Schnauß]

hallo,

Ähm, was sagtest noch genau, was du unter OOP verstehst?

Vermutlich verstehe ich OOP darunter?

Grüße aus Berlin

Christoph S.

[stareagle]

n'Abend,

Das OOP im Moment so "in" ist, liegt daran, dass man sie auch ohne Informatikstudium verstehen kann ...

halte ich für ein Gerücht. Ich kenne sowohl die "klassische" prozedurale Programmierung (und fühle mich wohl dabei), als auch das Konzept der OOP. Und ich finde die objektorientierte Philosophie _wesentlich_ komplizierter als den klassischen linearen Ansatz.
Und auch die Menschen, denen ich bisher Grundzüge der Programmierung vermitteln wollte, hielten den OO-Ansatz durchweg für komplizierter gehalten als die traditionelle prozedurale Denkweise - und das waren teilweise Laien, die *keine* Ahnung/Erfahrung mit Programmieren hatten teilweise auch Leute, die schon Grundkenntnisse hatten.

Das kann gut sein. Ich bin wahrscheinlich zu lange an die Denkweise gewöhnt (worden). Allerdings kann ich dir was die traditionelle prozedulare Programmierung fast zustimmen. Ich bin gerade dabei ein Projekt in C (wirklich C und kein C++) zu realisieren. Gegenüber dem Projekt in Java das ich vorher gemacht habe, ist sind die Probleme mit Pointer etc. fast angenehm ;-)

und man in ihr die meisten Probleme recht elegant lösen kann.

Das streite ich nicht ab; vor allem gibt es Aufgaben, für die OOP geradezu prädestiniert ist. Aber es ändert nichts daran, dass man zu einem hohen Grad an Abstraktion fähig sein muss - so viel, dass man sich diese Denkweise erst mühsam aneignen muss, weil sie eben _nicht_ dem natürlichen  Alltagsdenken entspricht, auch wenn das immer wieder behauptet wird.

Auch das konnte ich sehr häufig bei meinen Kommilitionen beobachten, die erst mit Beginn des Studiums auf objektorientierte Programmierung getrimmt wurden...
Und was ich besonders schlimm finde: Einige Profs die ich kenne sind extrem auf OOP (und Java) fixiert und lassen sich auf keine Diskussion darüber ein, ob OOP und Java für das jeweilige Problem wirklich der beste Ansatz ist...

Gruß

Stareagle

[hkl]

Hallo !

Hallo,

immer wieder hört man wenn man über das Programmieren redet von Objekt Orientierte Programmierung.
Ich habe diese OOP mal unter die Lupe genommen und folgendes festgestellt:
Wenn ich nun mit einer Klasse einen Mensch beschreiben sollte dann so:

Klasse: Mensch

Eigenschaften:
z.B

-Größe
-Alter
-Hautfarbe
-Haarschnitt
-Augenfarbe
-Geschlecht

Methoden:

-Laufen
-Sprechen
-Schlafen
-Benehmen

etc.

---

Die eigenschaften können ja Variablen sein in dem die Werte gespeichert werden.
Methoden sind ja mehr oder weniger Funktionen.

Aber was habe ich davon?
Nur weil ich von der Klasse eine Instanz erstellen kann?

Was bringt mir das OOP in der Praxis?
Mir fällt kein wirklicher grund ein aus alles eine Klasse zumachen?

Währe schön wenn mir da so einer ein paar Tips geben kann wie man sowas auch in der Praxis gebrauchen kann.

Danke schonmal!

Da hilft gkaube das hier weiter

OOA/D
-----
Grady Booch
"Objektorientierte Analyse und Design"
2. Auflage
Addison Wesley 1994

OOP
---
Bjarne Stroustrup
"Die C++ Programmiersprache"
4. Auflage
Addison Wesley 2000

und vielleicht ein Aufsatz des Autors

Bjrane Stroustrup

Die Konzepte kann man in diesem Rahmen wohl kaum geschlossen darstellen.

Gruesse

Holger

[Jonathan]

Was bringt mir das OOP in der Praxis?
Mir fällt kein wirklicher grund ein aus alles eine Klasse zumachen?

Erstmal Aufgabenteilung. Wenn ein Team z.B. ein Spiel Programmiert programmiert einer die Oberfläche, einer die Netzwerkkomunikation, einer die Grafikengine und einer die Spielmechanik. Jeder programmiert einfach seine Klasse und ist von anderen Programmcode vollkommen unabhängig. Das macht nicht nur die Kommunikation einfacher, sondern man kann das Netzwerkmodul oder die Grafikengine bei Bedarf auch ganz einfach austauschen.

Anderes Beispiel: Ein Downloadmanager. Hierbei empfielt es sich, jedem einzelnen Download ne eigene Klasse zu geben, welche dann die Methoden Abbrechen, Wiederaufnehmen, Starten, GeschwindigkeitErmitteln usw. hat. Das über Klassen/Objekte zu programmieren wäre sehr viel einfacher, als alles über ein Array o.ä. zu lösen. Und mit Vererbung könnte man auch einfach eine HTTP-Downloadklasse, eine FTP-Downloadklasse und eine SFTP-Downloadklasse erstellen, die alle eine unterschiedliche Programmierung haben, aber vom sonstigen Programm gleich behandelt werden können.

[Biesterfeld]

Hej,

Anderes Beispiel: Ein Downloadmanager. Hierbei empfielt es sich, jedem einzelnen Download ne eigene Klasse zu geben, [...]

Sicher dass du kein Objekt meinst?

Das über Klassen/Objekte zu programmieren [...]

Wie programmierst du denn ein Objekt?

wäre sehr viel einfacher, als alles über ein Array o.ä. zu lösen.

Und wie realsierst du ein(e) Menge/Liste/Feld/Array von Download-Objekten?

Beste Grüße
Biesterfeld

[Jonathan]

Hej,

Anderes Beispiel: Ein Downloadmanager. Hierbei empfielt es sich, jedem einzelnen Download ne eigene Klasse zu geben, [...]

Sicher dass du kein Objekt meinst?

Das über Klassen/Objekte zu programmieren [...]

Wie programmierst du denn ein Objekt?

Klappe, war spät gestern. Ich hoffe es ist verständlich was ich meine. Natürlich programmiert man Klassen und erstellt Objekte bzw. Instanzen davon.

wäre sehr viel einfacher, als alles über ein Array o.ä. zu lösen.

Und wie realsierst du ein(e) Menge/Liste/Feld/Array von Download-Objekten?

Ich habe nicht gesagt, dass ich ein Array von Downloadobjekten realsieren will, da müsste man wahrscheinlich sowieso ne Liste/Collection o.ä. verwenden um die einzelnen Download zu verwalten. Ich meinte nur, dass man ohne Objektorientierung vermutlich dass alles über mehrere oder blöd verschachtelte Arrays lösen muss. (Oder Alternativ mit mehreren Prozessen/Threads)

[Daniel Thoma]

Hallo webba,

Bei der prozeduralen Programmierung hat man idR. eine Trennung von Daten und Algorithmen. Man definiert zuerst seine Datentypen und anschließen die Prozeduren, die diese manipulieren.
Die Idee der OOP ist es nun, die Algorithmen direkt an die Datenstrukturen zu packen und die Software dadurch praktisch anhand der Struktur der Daten zu strukturieren. Der Programmablauf ist dann nicht mehr zentralisiert sondern über die Objekte verteilt.

Beispiel: eine Bank.

Prozedural würde man sowas schreiben (Pseudocode):

  
type Bank is record  
  name: String;  
  accounts: List of Account;  
end Bank;  
  
type Account is record  
  number: Integer;  
  balance: Integer;  
end Account;  
  
procedure transfer (fromBank: Bank, fromNumber: Integer,  
   toBank: Bank, toNumber: Integer, amount: Integer)  
is  
  fromAccount: Account := findAccount(fromBank, fromNumber);  
  toAccount: Account := findAccount(toBank, toNumber);  
begin  
  fromAccount := fromAccount - ammount;  
  toAccount := toAccount - account;  
end transfer;  

Dem OOP-Ansatz nach würde man eher so etwas schreiben:

  
class Bank is  
  name: String;  
  accounts: List of Account;  
  
  method transferTo(toBank: bank, fromNumber: Integer, toNumber: Integer,  
    amount: Integer)  
  is  
    fromAccount: Account := findAccount(fromNumber);  
  begin  
    fromAccount.decrease(amount);  
    toBank.transferFrom(this, fromNumber, toNumber);  
  end transferto;  
  
  method transferTo(fromBank: bank, fromNumber: Integer, toNumber: Integer,  
    amount: Integer)  
  is  
    toAccount: Account := findAccount(toNumber);  
  begin  
    toAccount.increase(amount);  
  end transferto;  
end Bank;  
  
class Account is  
  number: Integer;  
  balance: Integer;  
end Account;  

Hier sieht man auch je eine zentrale Stärke und Schwäche der Idee:
OOP ermöglicht es, Verhalten zusammen mit den Daten zu beschreiben und man kann das Problem so schön in kleine, lokale Aufgaben zerlegen.
Das Problem ist dabei, dass man die globalen Zusammenhänge nicht mehr so leicht sieht (da sie nicht mehr direkt dastehen sondern sich erst aus dem Zusammenspiel mehrerer Objekte ergeben) und es auch schwierig sein kann, globale Bedingungen umzusetzen.
Wenn man aufpasst, sieht man in dem Beispiel, dass man natürlich tranferFrom direkt aufrufen könnte und damit Geld überweisen, das nirgendwo abgebucht wird. Man müsste also möglicherweise die Schnittstelle ausbauen, damit Bank-Objekte feststellen können, ob ein Aufruf zulässig ist.

Um diese Idee gut umsetzen zu können, entstanden etliche Sprachkonzepte (z.B. Vererbung, Schnittstellen, ...), durch die sich OOP-Sprachen dann auszeichnen. Die grundlegende Idee kann man freilich auch in prozeduralen Sprachen umsetzen (Stichwort Abstrakte Datentypen).

Grüße

Daniel