Reale Anwendung der OOP

[Sadret]

Hallo,

ich kenne momentan kaum reale Anwendungen, in der OOP wirklich hilfreich ist. Im Internet gibt es überall Beispiele wie "Kunden in einem Verkaufssystem mit Name, Nummer, etc". Das Ding ist aber doch, dass sich das alles zwar sehr schön oo-modellieren lässt, aber in Wirklichkeit ist der Kunde nur ein Datensatz in einer Tabelle und nicht als Instanz einer Klasse gespeichert. Wenn dann was mit dem Kunden gemacht werden soll, dann wird doch eher der Tabelleneintrag direkt geändert, als dass erst eine Instanz aus dem Datensatz erzeugt und dann damit gearbeitet wird. Das Problem ist also aus meiner Sicht häufig die Kurzlebigkeit der Instanzen.

Anwendungen, bei denen dies nicht so ist, und die oop sind:
GUI (Buttons, Menüs etc.)
Spiele (Sämtliche Objekte des Spielinhalts sind als Instanz einer Klasse vorhanden)

Sieht man von der Kapselung ab (die meiner Meinung nach ein gutes Feature der OOP ist, aber die alleine noch kein oop-Programm macht), was gibt es ansonsten noch für Anwendungsmöglichkeiten?

 

[faetzminator]

Du sprichst hier vor allem über die Daten. Natürlich kann man irgendwelche DB-Daten als [c]String[][][/c] speichern und so verwalten. Warum nicht einfach eine [c]List<Datensatz>[/c] verweden? Was hat das mit der Kurzlebigkeit der Objekte zu tun?
Zusätzlich kann - oder besser sollte - das ganze Programm in OO geschrieben werden. So sind die GUI-Teile Objekte, die Controller etc.
Ich verstehe nicht genau, warum du OOP anprangerst.

 

[tribalup]

Steinigt ihn :lol:

 

[SlaterB]

OO bietet sich für alles an, z.B. auch ein Forum wie dieses hier in einem schönen Java-Server

die wenigen Daten, die man zu 80% durchkauen muss, etwa hier Postings, Threads, User, kann man ja gern optimieren und gleich in der DB updaten/ nur bestimmte Nutzdaten wie den Text laden statt ganze Objekte zu erstellen,

aber wenn es dann zu selteneren Aktionen und Daten kommt, etwa Login, User-Rechte, Such-Filter usw.
kann man in der Breite mit einfachen sicheren Objekt-Mitteln arbeiten statt überall mühsam SQL-Code oder bereits genannte String[][] als Darstellung
(edit: ganz abgesehen davon dass String und Array auch schon wichtige Objekte sind)

und dann noch im Falle des Java-Servers die kontrollierte Anwendung an sich, etwa Session-Objekt für jeden Besucher

 

[bygones]

du verwechselst hier meiner ansicht nach unter anderem Modellierung und Datenpersistenz.... abgesehen davon gibt es auch Objektorientierte Persistenzmodelle.

 

[Sadret]

Zusätzlich kann - oder besser sollte - das ganze Programm in OO geschrieben werden.

Nur weil man OO-Syntax nutzt, heißt das nicht, dass ein Programm oo ist.

Ich verstehe nicht genau, warum du OOP anprangerst.

Mache ich doch gar nicht. Ich finde die OOP in den Bereichen, wo man sie wirklich nutzen kann, richtig gut. Nur kenne ich halt kaum Bereiche.

 

[Sadret]

du verwechselst hier meiner ansicht nach unter anderem Modellierung und Datenpersistenz.... abgesehen davon gibt es auch Objektorientierte Persistenzmodelle.

Ich denke nicht, dass ich das verwechsle. Mein Argument zur Kurzlebigkeit war, dass man mit vielen Instanzen nur eine Operation ausführt und sie danach sofort wieder fallen lässt. Dies ist umständlich und meistens mit klassischer Programmierung besser zu lösen.

 

[Marcinek]

Mach doch mal ein Praktikum in einer Software-Firma, die auch entwickelt.

Allein die Tatsache, dass Du Kunden und Interessenten hast, macht die Nutzung iterativer Sprachen uninteressant.

 

[Sadret]

Allein die Tatsache, dass Du Kunden und Interessenten hast, macht die Nutzung iterativer Sprachen uninteressant.

Warum denn? Kann mir das hier niemand erklären?
Der Stand meines Wissens:
In einer Firmensoftware sind Kundendaten gespeichert. Wird etwas mit dem Kunden gemacht, wird ein Wert in der DB überschrieben oder noch eine Funktion aufgerufen, die eine Aktion ausführt. Alles Sachen, die mit klassischer Programierung mindestens so gut funktionieren wie mit OOP.
Wieso sollte OOP also gerade für sowas besonders gut sein?

Und legt mir jetzt nicht wieder Worte in den Mund, die ich nicht gesagt habe: Ich finde das Konzept der OOP gut, aber ich sehe kaum Anwendunggebiete (s.o.)

(Guter Einwand ist allerdings Benutzerverwaltung auf einem Server von SlaterB)

Zum Praktikum noch schnell was: bin momentan Dualer Student, in meinem Betrieb wird zwar auch programmiert, sämtliche OOP-Nutzung beschränkt sich hier aber auf Kapselung und statische Elemente.

 

[SlaterB]

> Allein die Tatsache, dass Du Kunden und Interessenten hast, macht die Nutzung iterativer Sprachen uninteressant.

kann mir nur vorstellen, dass hier gemeint ist,
dass die Kunden nachfragen/ informiert werden/ beim Einsatz ja wissen müssen, mit was programmiert wird,
und dann Java/ Net viel cooler/ werbefähiger als Uralt-Pascal ist

 

[bygones]

Ich denke nicht, dass ich das verwechsle. Mein Argument zur Kurzlebigkeit war, dass man mit vielen Instanzen nur eine Operation ausführt und sie danach sofort wieder fallen lässt. Dies ist umständlich und meistens mit klassischer Programmierung besser zu lösen.

und das ist eben auch falsch - ich weiss nicht ob es dir nun viel bringt wenn dir jeder hier seine Software oder seine Domain erklaert, ich bezweifle es. Nur weil es in deiner Firma anscheinend so ist, sollte man nicht generell auf das allgemeine schliessen.

Hier zb haben wir Daten die weit langlebiger sind als 1 Operation und genauer gesagt, in meiner nun 10+ Jahre Entwicklung sind diese Hopp-und-weg Ansaetze am geringsten, wenn nicht sogar gegen 0.

 

[maki]

Wenn man von Massendaten ausgeht, dann ist OOP oft nciht das beste Mittel, bei "simplen" CRUD Anwendungen sieht das IMHO sehr ähnlich aus.

OOP hat eben dort ihre stärken, wo Daten & Verhalten zusammenkommen.
Habe ich nicht viel verhalten, habe ich eigentlich nur noch Daten... Datenstrukturen wie JavaBeans u.ä. werden ja nicht ohne Grund nicht als "echte" Objekte im Sinne der OOP berachtet.

dazu kommt, dass viele Frameworks eher Prozedurales Design in den Vordergrundstellen, zB. EJB 2.x, selsbt mit EJB 3.x ist das oft noch so.
Sag doch mal Leuten dass eine Entity selber Logik enthält und schon wirst du oft hören "das geht ja gar nicht in Entities", "verboten" oder gar "schlechtes Design"... in OOP ist das alles i.O. und sogar gewünscht, als Beispiel sei Domain Driven Design genannt.

 

[Sadret]

Hier zb haben wir Daten die weit langlebiger sind als 1 Operation[...]

Dann gib mal ein Beispiel von einer Instanz, die langlebig ist.

 

[Sym]

Warum denn? Kann mir das hier niemand erklären?
Der Stand meines Wissens:
In einer Firmensoftware sind Kundendaten gespeichert. Wird etwas mit dem Kunden gemacht, wird ein Wert in der DB überschrieben oder noch eine Funktion aufgerufen, die eine Aktion ausführt. Alles Sachen, die mit klassischer Programierung mindestens so gut funktionieren wie mit OOP.
Wieso sollte OOP also gerade für sowas besonders gut sein?

Du hast einen Kunden. Das ist doch erst mal ein Objekt und keine Zeile einer Tabelle. Die Frage sollte doch eher sein, warum möchtest Du ein fachliches Object (Kunde) technisch als eine Zeile einer Tabelle behandeln?

Ich finde das Konzept der OOP gut, aber ich sehe kaum Anwendunggebiete (s.o.)

Ich nehme einfach mal an, dass Du noch keine Erfahrung im ecommerce-Bereich gemacht hast.

 

[Sadret]

Wenn man von Massendaten ausgeht, dann ist OOP oft nciht das beste Mittel, bei "simplen" CRUD Anwendungen sieht das IMHO sehr ähnlich aus.

OOP hat eben dort ihre stärken, wo Daten & Verhalten zusammenkommen.
Habe ich nicht viel verhalten, habe ich eigentlich nur noch Daten... Datenstrukturen wie JavaBeans u.ä. werden ja nicht ohne Grund nicht als "echte" Objekte im Sinne der OOP berachtet.

[...]

Das hilft mir doch schon eher weiter. Also bin ich nicht der einzige, der das so sieht. Jetzt brauche ich nur noch ein paar Bsp's, die halt nicht CRUD sind.

 

[tfa]

Ist das nicht völlig egal, wie langlebig eine Instanz ist? Ich kann mir beim besten Willen nicht vorstellen, wie man eine Business-Anwendung ohne OOP programmieren will. Security-, Session-, Remoting-, Transaction-Management usw. möchte ich nicht in Pascal schreiben müssen...

 

[maki]

Das hilft mir doch schon eher weiter. Also bin ich nicht der einzige, der das so sieht. Jetzt brauche ich nur noch ein paar Bsp's, die halt nicht CRUD sind.

Jede komplexere Anwendung würde sich da anbieten, aber deswegen wird nicht jede komplexere Anwendung auch in "reinstem" OOP geschrieben, selbst in Java.

Ein guter Anhaltspunkt ist IME immer, wenn daten und logik eben nicht getrennt sind (komplettte Logik in Services, alle Daten in Entities), aber eben keine Garantie.

Persönlich tue ich mir immer etwas schwer Beispiele für "gute" Javaprogramme zu geben, da IMHO über 95% der Javaanwendungen (meist teure) Massanfertigungen sind die auf Kundenwunsch gefertigt wurden und nicht frei verfügbar sind.

 

[Marcinek]

In einer Firmensoftware sind Kundendaten gespeichert. Wird etwas mit dem Kunden gemacht, wird ein Wert in der DB überschrieben oder noch eine Funktion aufgerufen, die eine Aktion ausführt. Alles Sachen, die mit klassischer Programierung mindestens so gut funktionieren wie mit OOP.
Wieso sollte OOP also gerade für sowas besonders gut sein?

Funktionieren tut das schon. Die Frage ist, wie wartbar, anpassungsfähig oder skalierbar ist es.

Wenn ich eine Konstruktion habe wie: Person, Kunde und Interessent.

Dann teilen sich Kunden und Interessenten 90 % der Funktionen und 10 % nicht.

In iterativen Programmiersprachen hast du hier doppelten Code oder Code, der nicht direkt der Funktion zu einer Person zugeordnet werden kann. Anpassungen müssen mehrfach durchgeführt werden.

Du kannst nix überladen, verstecken, kein Polymorphismus.

Zum Praktikum noch schnell was: bin momentan Dualer Student, in meinem Betrieb wird zwar auch programmiert, sämtliche OOP-Nutzung beschränkt sich hier aber auf Kapselung und statische Elemente.

Was beduetet das? Oder "kapselt" ihr einfach statische Methoden in einer Klasse? ^^

Das macht natürlich in kleinen Programmen Sinn, aber wenn es bissel größer wird...

Dann gib mal ein Beispiel von einer Instanz, die langlebig ist.

Warenkorb.

 

[Sadret]

Du hast einen Kunden. Das ist doch erst mal ein Objekt und keine Zeile einer Tabelle. Die Frage sollte doch eher sein, warum möchtest Du ein fachliches Object (Kunde) technisch als eine Zeile einer Tabelle behandeln?

Weil nicht alle Objekte immer im Hauptspeicher liegen können. Daher muss es Möglichkeiten geben, "Kunden" zu speichern und wieder aufzurufen. Und das passiert dann logischerweise immer dann, wenn man mit einem Kunden arbeitet. Dann wird aber in vielen Anwendungsbereichen nicht viel gemacht, sondern nur eine Aktion ausgeführt.

Ich nehme einfach mal an, dass Du noch keine Erfahrung im ecommerce-Bereich gemacht hast.

Nein, da hast du recht.

 

[Landei]

Keine moderne Architektur würde einen Kunden direkt in der Datenbank manipulieren. Frameworks wie Hibernate oder JPA sind dafür da, dass du dich mit solchen Details nicht beschäftigen musst - du arbeitest nur mit einem Kunden-Objekt, die Persistenz übernimmt das Framework.

Benutzeroberflächen als OOP-Beispiel hast du schon genannt.

Viele Bibliotheken bieten ein Grundgerüst von Klassen mit einer gewissen Funktionalität, ohne den Benutzer damit allzu sehr festzulegen, denn dieser kann ja über Vererbung diese Klassen an seine Bedürfnisse anpassen. In diese Richtung geht auch Polymorphismus, der z.B. erlaubt, dass eine Bibliothek ein Standardverhalten implementiert, dieses aber geändert werden kann.

Schließlich erlauben Templates/Typpolymorphismus/Generics ein Abstraktionslevel, das mit imperativen (nicht-OO) Sprachen oft nur unter umfangreicher Codeduplikation oder unsicherer Makro-Programmierung nachzubilden ist. Ein praktisches Beispiel wäre die JScience-Bibliothek - damit hätte die NASA ihre eine Mission nicht in den Marsboden gerammt.

Vielleicht solltest du dir doch einmal genauer anschauen, was es mit OO auf sich hat, ehe du hier solch wilde Thesen heraushaust. Ich bin der Letzte, der nicht auch die Probleme von OO (und die Vorteile funktionaler Programmierung) sieht, aber mit deinen Behauptungen bist du auf dem Holzweg.

 

[Templarthelast]

Mal Angenommen du willst ein Space Invader Spiel programmieren. Dann erstellst du für jedes Raumschiff(Spielfigur + Gegner) eine Überklasse wie z.B. Spielobjekt, mit den Variablen Leben, Bild und den Methoden zeiche() und bewege(). Danach erstellst du deine Spielfigur als Vererbung des Raumschiffes und fügst dieser wiederrum Methoden wie feuer() oder lvlup() hinzu. Dann kannst du wieder eine neue Klasse names Rakete erstellen, die wieder eine Vererbung der Spielobjekt Klasse sind.

Das ganze Spiel kann man dann ewig so weitertreiben...


In der "richtigen" Programmierung verwendest du normalerweise statt einer direkten Datenbankverbindung oop basierende Datenbankmapping wie z.B. in hibernate umgesetzt. Da hast du einen Datensatz als Javaobjekt und kannst direkt mit diesem weiterarbeiten.

 

[Sadret]

Was beduetet das? Oder "kapselt" ihr einfach statische Methoden in einer Klasse? ^^

Das macht natürlich in kleinen Programmen Sinn, aber wenn es bissel größer wird...

Wir haben viele Anwendungen, bei denen in einer DB neue Datensätze erstellt und bestehende verändert werden. Da wird das meiste dann über statische Methoden gemacht. Klassen werden also im Grunde nur zur Kapselung / Vereinhetlichung / Übersichtlichkeit gebraucht.

 

[Sadret]

Warenkorb.

Gutes Beispiel. Noch was außerhalb des Web-Bereichs?

 

[SlaterB]

DB-Connection,
ConnectionPool,
Thread,
Enums,
Cache

 

[Sadret]

Mal Angenommen du willst ein Space Invader Spiel programmieren. Dann erstellst du für jedes Raumschiff(Spielfigur + Gegner) eine Überklasse wie z.B. Spielobjekt, mit den Variablen Leben, Bild und den Methoden zeiche() und bewege(). Danach erstellst du deine Spielfigur als Vererbung des Raumschiffes und fügst dieser wiederrum Methoden wie feuer() oder lvlup() hinzu. Dann kannst du wieder eine neue Klasse names Rakete erstellen, die wieder eine Vererbung der Spielobjekt Klasse sind.

Aus dem Spielebereich kenne ich auch unendlich viele Anwendungen. Dachte halt nur an Programme wie z.B. Browser, Office-Produkte etc.

 

[Michael...]

In einer Firmensoftware sind Kundendaten gespeichert. Wird etwas mit dem Kunden gemacht, wird ein Wert in der DB überschrieben oder noch eine Funktion aufgerufen, die eine Aktion ausführt. Alles Sachen, die mit klassischer Programierung mindestens so gut funktionieren wie mit OOP.
Wieso sollte OOP also gerade für sowas besonders gut sein?

Wenn Du die Objektdaten in einer Datenbank hälst, könnte man in vielen Fällen tatsächlich auf eine OOP verzichten. Ein Kundenobjekt ist jetzt nicht unbedingt ein Fürsprecher von OOP.

Meiner Meinung ist OOP auch ein gutes Mittel zur Entkopplung.
Je nach verfügbarer Infrastruktur und dem zu verwaltenden Datenumfang ist es vielleicht sinnvoll nicht alles direkt in die DB zurück zu speichern.

Was aber wenn sich die Datenbank im Hintergrund ändert, was wenn die Verbindung zur Datenbank abreißt?
Im ersten Fall müsste man alle Codestellen an denen irgendetwas mit Kundendaten gemacht wird anpassen. Hat man ein Kundenobjekt muss man (je nachdem wie man es implementiert) nur den zwei Stellen anpassen, an der es aus der Datenbank befüllt und an der es in die Datenbank gespeichert wird.
Im zweiten Fall ist man beim Ausfall der Datenbank arbeitsunfähig, schlimmsten Falls sind die Änderungen verloren. Hat man aber ein oder mehrere Objekte im Arbeitsspeicher kann man diese weiterhin bearbeiten und diese zurückspeichern sobald die Datenbank wieder verfügbar ist.

Ein Objekt Kunde ist aber wie gesagt ein schlechter Maßstab für OOP. Da es sich hier in der Regel meist nur um einen "flachen" Datenspeicher handelt - und wie Du selbst festgestellt hast kann man Daten auch in einer DB speichern.

 

[Templarthelast]

Ein mögliches Anwendungsbeispiel wäre ein auf oop basierendes Tabellenkalkulationsprogramm: Dabei hast du deine Klasse sheet, welche wiederum ein Array der Klassen row und column beinhaltet. Diese wiederum haben ein Array der Klasse cell. cell hat dann bestimmte Eigenschaften wie Inhalte, Farbe, Größe etc.

 

[Marcinek]

Gutes Beispiel. Noch was außerhalb des Web-Bereichs?

Wieso Webbereich?

---

Aber klar, wenn ihr so minianwendungen habt, die ein paar Daten modifizieren, ist es erheblich aufwendiger es in OOP initial zu machen. Aber selbst da würde es Sinn machen.

Es sei den es sind so wegwerfscripte.

Ich befürchte, dass die Frage einfach aus zu wenig Praxis resultiert ;D

 

[Sadret]

Wieso Webbereich?

[...]

Ich befürchte, dass die Frage einfach aus zu wenig Praxis resultiert ;D

Warenkorb ist doch Webbereich? Oder meinst du keinen Online-Shop?


Praxis habe ich bisher wirklich erst recht wenig.

 

[ARadauer]

Grundsätzlich finde ich es nicht verkehrt wenn man OOP nicht als gegebenes Dogma hinnimmt.
Sadret ist mit seiner Einstellungn nicht alleine. Da kenn ich genug erfahrene Programmierer die oft negativ über OOP sprechen.

Man muss sich aber genau ansehen, woran das liegt. Oftmals liegt es an der falschen Verwendung oder einfach an einer schlampingen Arbeitsweise. Andererseits gibt es einige Anwendungsfälle wo eine statisch getypte OO Sprache wie java einfach zu schwerfällig ist.

 

[Icewind]

Oder folgender Fall:
Schaun ob ein Eintrag schon einmal vorgekommen ist.

Speichern wir neue einträge in List<Entry> wenn sie noch ned drinnen sind.

Hm wenn jetzt Datenmengen kommen wo man 10k verschiedene Einträge hat, dann wird das wohl recht langsam.

Effizienter wäre wohl die Verwendung eines HashSets. Wenn jetzt allerings HashSet und List nicht die gleiche Abstammung hätten (Collection) und das Program mittlerweile schon groß oder wie auch immer geartet ist. Dann wird die umstellung echt nicht hübsch...

 

[Gregorrr]

@Sadret: Sei wenigstens froh, dass du das wichtigste bei der OOP verstanden hast. (Anwendung ist immernoch was ganz anderes.) Es gibt Programmierer, die kreieren hauptsächlich nur Namespaces in Klassen und geben dann beispielsweise ganze Implementierungsdetails nach außen zur Verfügung, ohne die Logik abzukapseln.

Das Ergebnis ist dann, dass man als Benutzer auch alle Implementierungsdetails wissen muss, wenn man die Klasse benutzt. Das ist aber überhaupt keine OOP. Das sind einfach nur Namespaces und Gruppierungen von Objekten. "Echte" OOP ist überhaupt nicht einfach. Richtig die Semantik und Logik abzukapseln ist hart. Vorallem wenn man eine API erstellt, bei der sich ein Dritter nicht die ganze Zeit mit der Implementierung befassen kann (aus Zeitgründen, man will ja Features implementieren, und nicht über die Implementierung sinnieren müssen). Dann noch aussagekräftige Namen, etc.

Dazu kommt, dass die Namespaces dann überhaupt nicht thread-safe sind. Was wären beispielsweise die concurrent Klassen, ohne gescheite Abkapselung? Dann müsste der Programmierer selbst für die Thread-Sicherheit sorgen. Das ist keine modulare Programmierung, das ist Bullshit.

Ich finds so lustig, dass viele Programmierer über die OOP herziehen, ohne genau begriffen zu haben (und wirklich real world angewendet) was die Grundprinzipien sind. Wahrscheinlich eher, weil ihnen richtige OOP zu schwierig ist. Sie benutzen wohl nur APIs und lassen die anderen OOP machen. Im grunde sind as nur Integratoren, die die ganz schwierige Design-Aspekte echten Programmierern überlassen.


Anwendungsgebiete von OOP: Alles, was man als Modul nach außen semantisch (kohärent) anbieten kann. Das kann ein Server, thread-safe Datenstrukturen, Datenstrukturen im Allgemeinen. Jegliche mathematische Konzepte, bspw. Matrizen, Vektoren, usw. mit deren Funktionen. Das können Crawler sein, Betriebssystem-Abstraktionen von realen Hardware-Objekten, usw. Auch Funktionen können als Klassen implementiert werden. Im weiteren Sinne sind ja Closures Klassenfunktionen.

 

[ARadauer]

Wir haben viele Anwendungen, bei denen in einer DB neue Datensätze erstellt und bestehende verändert werden. Da wird das meiste dann über statische Methoden gemacht. Klassen werden also im Grunde nur zur Kapselung / Vereinhetlichung / Übersichtlichkeit gebraucht.

Das ist aber nicht OOP.

 

[Sadret]

Das ist aber nicht OOP.

Sag ich doch auch.