OOP Projektvorschläge?

Ich bin atm. im 2 Ausbildungsjahr und habe leide fast nur Prozedural programmiert.
Hat 3 Gründe:
1. In meiner Firma programmiert keiner objektorientiert.
2. Ich hab es mir schon mehrmals angeguckt finde aber keine wirkliche Anwendungsmöglichkeit. Höchst wahrscheinlich das ich es noch nicht richtig verstanden habe ist aber auch nicht so einfach sich das selbst beizubringen ohne ein vernünftiges Projekt woran man es Testen kann
3. Leider zu wenig Zeit zwischen meinen Projekten.

Deswegen hab ich mich entschlossen dies Zuhause nachzuholen. Da viele Firmen auf oop umgestellt haben und nur welche einstellen die dadrin geübt sind.

Meine bitte an euch eventuell ein paar Projekte (mittel-groß) vorschlagen wo man oop testen kann. Zudem wäre hilfreich wenn jemand eine wirklich gute Seite dazuschreibt wo oop nochmal beschrieben & erklärt wird. :)



:handsdown:

Mfg
Masterkroko

wenn du lieber den harten einstieg haben willst guckst dir am besten symfony oder zend an sind beides 2 php framework, die auch oft von firmen benutzt werden, zu mindest fanden die firmen das immer gut wo ich bei meinen bewerbungsgespraech drauf eingegangen bin.

ich habs mit einer pserver seite zuhause gelernt und bissel bei den projekten bei meiner ausbildung, durfte vorher nix groß machen ohne oop.

Hmm, ein großes Projekt mit OOP.
Ich kann auf mein Projekt, SHPS, verweisen. Besonders die SQL Klassen sind ein gutes Beispiel für eine sinnvolle OOP Anwendung. Und insgesamt wesentlich weniger Quelltext als ein Framework, wie Symfony.
Ziel der Klasse ist es, Zugriffe auf SQL (und später NoSQL) Datenbanken so stark zu abstrahieren, dass mit den gegebenen Funktionen jede Operation möglich ist, ohne dass der Entwickler merkt, ob es eine MySQL, eine MSSQL oder eine MongoDB Datenbank ist. Zudem muss er sich keine Gedanken mehr um Injections oder Optimierungen machen.

In meinem Beispiel sieht man denke ich auch gut, was man so mit OOP anstellen kann.
- Wiederverwertbarer Quelltext (SQL)
- einfacher Quelltext (keine zick Variablen, um all die Handler zu managen)
- Container für Eigenschaften

Du wolltest zudem einen Link. Hier, die Uni Potsdam hat eine kleine einfache grobe Übersicht (die Links im grauen Kasten beachten):
[Only registered and activated users can see links. Click Here To Register...]

Masterkroko, wenn du dich in deinem Betrieb nicht ausleben kannst, wechsel ihn. Problemlos möglich.

Quote:

- einfacher Quelltext (keine zick Variablen, um all die Handler zu managen)

Ich finde den Quelltext ziemlich umständlich zu lesen, andere Projekte haben da eine viel schönere API (z.B. der Query-Builder von Doctrine).

Quote:

- Wiederverwertbarer Quelltext (SQL)

Wiederverwertbar wäre das doch auch mit Funktionen. Ohne Polymorphie - und die sieht man in deinem Beispiel gar nicht - zwar nicht so gut erweiterbar, wiederverwertbar aber sicherlich.

Quote:

Originally Posted by dowhile Ich finde den Quelltext ziemlich umständlich zu lesen, andere Projekte haben da eine viel schönere API (z.B. der Query-Builder von Doctrine).

Nunja, wenn man Äpfel mit Birnen vergleicht wird man feststellen, dass Äpfel in der Regel runder sind.
Du kannst mein Werk nicht mit _irgendwas_ vegleichen. Der Doctrine Query Builder hat einen ganz anderen Fokus als meine Klasse. Insofern finde ich meine Klasse vom Abstraktionsniveau her wesentlich besser.
Und ich finde sie auch besser lesbar als Doctrine. Ich schätze, das ist einfach eine Sache der Gewohnheit. Wenn du mein System regelmäßig benutzen würdest, fändest du es sicherlich auch besser als im Moment - ohne Ahnung.
*** [Only registered and activated users can see links. Click Here To Register...] ***

Quote:

Originally Posted by dowhile Wiederverwertbar wäre das doch auch mit Funktionen. Ohne Polymorphie - und die sieht man in deinem Beispiel gar nicht - zwar nicht so gut erweiterbar, wiederverwertbar aber sicherlich.

Zeig mir deine wiederverwertbaren Eigenschaftscontainer Funktionen. Da wär ich nun doch sehr gespannt drauf, wie du die sauber implementierst.
Zudem habe ich nur ein Beispiel gemacht. Wenn ich den vollen Umfang von OOP hier präsentieren wollte, dann müsste ich eine halbe Doktorarbeit schreiben.
Da du wohl auf Vollständigkeit stehst, kannst du das gerne tun, aber ich hab weitaus besseres, wichtigeres in meinem RL mit meiner kostbaren Zeit zu tun.

Hi,

so anders ist der Fokus doch gar nicht, oder? Bei Doctrine wird schließlich auch ein Query gebaut, das dann auf ein beliebiges Datenbanksystem angewendet werden kann (und dabei natürlich auch noch optimiert wird).
Noch eine Anregung: Bei Doctrine (oder auch anderen ORMs wie Hibernate in Java) ist es auch möglich in einem eigenen SQL-Dialekt ein Query zu schreiben, das dann zerlegt, ggf. optimiert und für die richtige Datenbank wieder richtig zusammengebaut wird. Damit hat man auch alle Vorteile (universell, optimierbar, sicher, ...), muss aber nicht so viel Code schreiben.

Das Abstraktionsniveau ist bei beiden Produkten gleich, oder sehe ich das falsch? Wo ist deine Lösung in diesem Sinne besser als Doctrine?

Quote:

wiederverwertbaren Eigenschaftscontainer (Funktionen)

Den Begriff kenne ich nicht. Wäre nett wenn du kurz was dazu sagen könntest.

Quote:

Da du wohl auf Vollständigkeit stehst, kannst du das gerne tun, aber ich hab weitaus besseres, wichtigeres in meinem RL mit meiner kostbaren Zeit zu tun.

Das habe ich nicht gemeint. Ich denke nur, dass doch gerade die Polymorphie eine der größten, wenn nicht der größte Punkt ist, an dem man die richtige Vorteile von OOP sehen kann. Deswegen finde ich es schade, dass dein Beispiel gerade das nicht zeigt.

Ich habe mir Doctrine angesehen und entsprechende Anpassungen überlegt (siehe Link in meinem vorherigen Post).
Einen eigenen SQL Dialekt möchte ich nicht unbedingt verwenden. Das würde bedeuten, dass ein Entwickler sich zusätzliches Wissen aneignen müsste. Ich finde, wenn man in PHP entwickelt, sollte man in PHP bleiben können - und nicht noch zusätzlich SQL in verschiedenen Dialekten lernen müssen.
Zudem würde das Parsen einer solchen Query sich nachteilig auf die Performance auswirken. PHP muss immerhin jedes Mal komplett ausgeführt werden. Da man in Strings einfach Variablen einsetzen kann, ist auch Caching eines solchen SQL Strings im momentanen Stadium leider nicht umsetzbar. Aber Danke für das Feedback!

"wiederverwertbaren Eigenschaftscontainer (Funktionen)" ist ein Neologismus. So etwas gibt es natürlich nicht. In der Objekt-Orientierten Welt sind das Strukturen, die viele Eigenschaften enthalten. Zum Beispiel ein Vektor:


Wenn ich nun 100 3D Vektoren brauche, dann kann ich ein Array über 100 3D Vektoren machen. Ohne OOP müssten das 3 Arrays mit je 100 Werten sein, die nicht miteinander verknüpft sind - was zu Problemen führen kann.

Zu Polymorphie: Ich finde nicht, dass es der wichtigste Teil ist. Es ist ein wichtiger Teil von OOP und furchtbar nützlich. Aber auch die anderen Eigenschaften von OOP können mir als Programmierer das Leben wesentlich leichter machen.
Es kommt natürlich immer darauf an, was man entwickeln will und was deshalb tatsächlich Sinn macht.

Quote:

Wenn ich nun 100 3D Vektoren brauche, dann kann ich ein Array über 100 3D Vektoren machen. Ohne OOP müssten das 3 Arrays mit je 100 Werten sein, die nicht miteinander verknüpft sind - was zu Problemen führen kann.

In C könnte man dafür struct verwenden. In PHP ohne Klassen auch ein zweidimensionales Array, $array[0]['x'] wäre gleich wie $array[0]->x.

Quote:

Das würde bedeuten, dass ein Entwickler sich zusätzliches Wissen aneignen müsste. Ich finde, wenn man in PHP entwickelt, sollte man in PHP bleiben können - und nicht noch zusätzlich SQL in verschiedenen Dialekten lernen müssen.

Die Syntax könnte der von MySQL entsprechen, die kennen sowieso die meisten. Oder sich eben einfach auf die nicht-Datenbank-spezifischen Elemente beschränken; dann kann jeder damit umgehen, der sich generell mit Datenbanken auskennt.

Quote:

Zudem würde das Parsen einer solchen Query sich nachteilig auf die Performance auswirken. PHP muss immerhin jedes Mal komplett ausgeführt werden. Da man in Strings einfach Variablen einsetzen kann, ist auch Caching eines solchen SQL Strings im momentanen Stadium leider nicht umsetzbar.

Wenn mit prepared Statements gearbeitet wird sollte es doch einen Sonderfall abbilden, dass das Query (also das für deine Lib) erst zur Laufzeit generiert wird. Zu PHP kompilieren und cachen sollte daher in den meisten Fällen doch problemlos funktionieren.

Ich sehe ein, dass PHP viele Dinge erleichtert. Bleiben wir also mal bei dem Vektor.
Sagen wir, wir haben 2D und 3D Vektoren gemischt.
Nun wollen wir, dass alle Vektoren den Standardwert 100 für x,y und z haben. Zudem bekommen ein paar der Vektoren eine weitere Variable, die eine eindeutige ID (whatsoever) enthält und nicht verändert werden darf.
Dieses Szenario ist schaurig ohne OOP umzusetzen. Ich sehe viele isset-Prüfungen in Funktionen, die damit arbeiten wollen und auf einen bestimmten Typ Vektor prüfen müssen.
Wie gesagt. Du kannst eigentlich alles, was es gibt, auch ohne OOP umsetzen. Aber das ist nicht das Thema dieses Threads. Der OP wollte wissen, wie er OOP lernen kann, nicht ob und wie weit es Sinn macht.

Zum Thema SHPS bitte ich dich, die Diskussion in den [Only registered and activated users can see links. Click Here To Register...] zu verlagern. Ich bin sehr an deiner Meinung interessiert, aber dieser Thread ist der falsche Ort dafür.

Quote:

Nun wollen wir, dass alle Vektoren den Standardwert 100 für x,y und z haben.

a) Die Werte werden initialisiert bevor die Objekte in das Array kommen: Geht ohne OOP genau so gut.
b) Die Werte sollen danach initialisiert werden: Dann liegt der Vorteil bei Polymorphie und nicht mehr darin, dass Klassen Attribute "zusammen fassen".

Quote:

Zudem bekommen ein paar der Vektoren eine weitere Variable, die eine eindeutige ID (whatsoever) enthält

Wenn diese ID nur für ein paar der Objekte vorhanden ist, gibt es keine Zugriffsmethode dafür in der gemeinsamen Oberklasse. Man benötigt also auch bei der OOP Lösung ein instanceof.
Soll die ID hingegen nur in den gemeinsamen Methoden genutzt werden, liegt der Vorteil wieder bei Polymorphie.

Quote:

und nicht verändert werden darf.

Datenkapselung sieht man bei deinem Beispielcode aber auch nicht, oder täusche ich mich?

Quote:

Dieses Szenario ist schaurig ohne OOP umzusetzen. Ich sehe viele isset-Prüfungen in Funktionen, die damit arbeiten wollen und auf einen bestimmten Typ Vektor prüfen müssen. Wie gesagt. Du kannst eigentlich alles, was es gibt, auch ohne OOP umsetzen. Aber das ist nicht das Thema dieses Threads. Der OP wollte wissen, wie er OOP lernen kann, nicht ob und wie weit es Sinn macht.

Ja, ohne OOP ist das doof - aber wegen Polymorphie und nicht wegen der Funktion als "wiederverwendbaren Eigenschaftscontainer".

Folgende Aussage von ihm:

Quote:

2. Ich hab es mir schon mehrmals angeguckt finde aber keine wirkliche Anwendungsmöglichkeit. Höchst wahrscheinlich das ich es noch nicht richtig verstanden habe ist aber auch nicht so einfach sich das selbst beizubringen ohne ein vernünftiges Projekt woran man es Testen kann

klingt für mich schon stark danach, dass er eben gerade wissen möchte, wieso eine Lösung mit OOP in manchen Fällen mehr Sinn macht (besser ist) als eine andere.