hi alle.

ich habe bisher immer schön prozedural in php gecoded, und bin sehr gut damit klargekommen.
nun haben wir im geschäft java gelernt (was mich nicht sehr freut, mir wäre c++ lieber gewesen ), aus dem einfachen grund, weil java 100% oop ist.

nun, wer von euch benutzt oop? was sind die vorteile, was die nachteile? ich muss gestehen, dass ich noch nicht sehr versiert im oop bin, und ich sehe auch nicht viele vorteile darin gegenüber normalem prozeduralem code-design, ausser, dass man damit klassen erschaffen und diese leicht wiederverwenden kann...

was denkt ihr dazu?

gr33tz j0sh

OOP ist die Königsklasse des Programmierens
sagt zumindestens der Informatik Lehrer

mhhh ich hab mir Meinungen eingeholt und viel gelesen ... wie schon in einem anderen Thread erwähnt, Java Entwickler gehören mit zu den bestbezahltesten in der Branche ... es gubt Leute die könn C++ , aber sagen das sie lieber Ihre Zeit damit verbracht hätten, Java zu lernen.
Ansonsten
Java nicht mit Javascript verwechseln

jau, in java programmen ist oop sicher absolut nützlich. aber in einem script wie in php, welches ja sowieso einfach einmal abgearbeitet, dann angezeigt wird, weiss ich nicht, was da so toll an oop sein soll... geht doch alles genau so gut mit stinknormalen funktionen??!

java vs cpp is ne heisse diskussion. ich kenn mich zu wenig damit aus, aber java is mir einfach seit jeher nicht so sympathisch. naja, vielleicht werd ich meine meinung ja noch ändern...

ja, ich programmier weder java noch c++, aber man bekommt doch einiges zu hören aus communitys

ich selber programmiere Oberon was stark oop belasted seien soll ... aber die sprach is hunzen alt .. und mir ist nicht klar das ich da grad oop progge
ich unterscheide grundsätzlich nur zwischen den sprachen .. php mach ich so und oberon in dem fall oop so ... wobei ich sagen muss, das php mitunter rechts einfach seien kann ... dann programmier ich noch Prolog ... das ist wieder ein ganz anderes programmieren ... logikbasiert und zur Wissensverarbeitung ...

mhh am Anfang meines Informatiker lebens wurde gesagt das Programmieren wie Autofahren ist ... man lernt zwar das Fahren in einem Auto, aber solbald man es kann, kann man auch mit anderen fahren ... und genau dem Grundsatz kann ich nur zustimmen ...

Also, kann ich jetzt nicht verstehen, dass ich Dir nicht symphatisch bin. ;-)

In der Tat ist es so, dass kleine Softwaresysteme gut prozedural/funktional realisiert werden können.
Die Erfahrung zeigt aber, dass dies bei komplexen bis sehr komplexen Systemen schwierig wird.

Wenn das oo-paradigma befolgt wird, kannst Du einen wesentlich besseren Entkopplungsgrad erreichen, die Software wird transparenter und somit wartbarer.

Es liegt noch sehr viel Software auf Servern rum, die wohl sehr gut funktioniert, jedoch möglichst niemand mehr anfassen will. Lieber baut man drumherum (ausgehend von sauberen Schnittstellen) weitere Software dazu.

Je nach Zustand des LegacyCodes kann dieser als "schwer wartbar" bis "praktisch unwartbar" bezeichnet werden, bzw. eine OO-Neuimplementation wäre schneller, als die Wartung des alten Stuffs insgesamt. :-)

Ich persönlich habe Mühe kein OO zu programmieren - ich find's auch viel langweiliger, ehrlich gesagt.

Java (also die Sprache *g* ) versucht OO aufzudrängen, allerdings kann man damit auch nicht OO programmieren... und genau dies tun viele leider - bzw. viele programmieren "Hybrid", was sicherlich nicht der Sinn von Java ist.
Auf der anderen Seite sollte man bei typisch prozeduralen Aufgaben (Numbercrunching) auch nicht OO-Overhead generieren. Auf der anderen Seite gibt's für diesen Zweck ja auch bessere Sprachen.

Ui das ist ja ein ganz alter Hut.

Aber trotzdem heute noch ein Thema, denke ich.

Also für grosse Projekte, wo eine Funktion mehrmals gebraucht wird, ist es natürlich von Vorteil oop zu programmieren.

Ein kleines Projekt mit ein paar funktionen und ausgaben geht normal programmiert fast besser. Ich sehe dass, wenn ich Projekte erweitern oder bearbeiten/reparieren soll, da muss ich bei oop sehr lange suchen, bis ich die richtige Stelle gefunden haben (wenn die Funktionen verschachtelt sind). Und wenn etwas indiidueles gewünscht wird, so muss man dies dann geschickt integrieren.

Ich finde es ein Mehraufwand (sowohl das programmieren, wie das einarbeiten in einen fremden Code) welcher sich nur bei grossen Projekten bezahlt macht.

Die Erfahrung zeigt, dass man am Anfang einer OO Entwicklung häufig das Gefühl hat langsamer voranzukommen, als bei prozeduraler Vorgehensweise (PV). OO bedingt meist auch etwas Designarbeit. Ist der Rahmen jedoch erst einmal gesteckt, können erweiternde Funktionen wesentlich schneller integriert werden, als mit PV.
Ich sehe nicht ein, warum das Einarbeiten in OO Code zwingend aufwändiger sein soll als bei PV. Oft ist OO-Software besser engineered und die entsprechende Dokumentation spricht für sich. Sehr schnell kann man anhand einer solchen Dokumentation erkennen wo was abgeht. OO hilft uns somit auch Software nicht zu "basteln" (was leider noch immer sehr häufig geschieht), sondern sie korrekt aufzubauen, zu engineeren.

Dann ist die Erfahrung ein sehr wichtiger Faktor: Programmierer, die die PV gewöhnt sind, denken nicht gerne um - bzw. verfallen immer wieder dem alten Paradigma, was (bei fehlender Führung/Kontrolle) dann leider in Hybrid-Software resultiert. Hier steigt der Wartungsaufwand wiederum an, jedoch hat dies nichts mit OO zu tun, sondern mit den menschlichen Eigenschaften der Programmierer.
Bezeichnend für OO ist ja auch deren Einteilung in OOA/OOD und OOP, welche aufzeigt, dass ein definiertes Vorgehen gefragt ist. Die Einstellung "ich bastel mir schnell mal ein xyz", wird weniger vertreten.

Meine Aussagen beziehen sich allg. auf IT-Projekte, nicht speziell auf den Webbereich. Wenn ich mal schnell ein kleines PHP Script brauche, benötige ich keine OO.

Naja, meist ist der Programmierer zu faul, den Code ausführlich zu dokumentieren, vorallem, wenn er von Anfang an nicht davon ausgeht, dass der Code von einer anderen Person betreut oder angepasst werden soll.

Somit ist man bei Arbeiten an anderem Code meist aufgeschmissen und weiss nicht, in welcher Datei welche Funktion ist und dies ist das Zeitaufwendige, dies zu finden und anzupassen.

Eine ausführliche Dokumentation ist bei OOP meist notwendig, beim normalen Coden sieht man eigentlich auf einen Blick, was gemacht wird.

Dokumentation ist bei OOP einfach das A und O, wer das keine richtige Dokumentation zu so einen Programm schreibt, ist oft selber irgendwann verloren. Wie soll dann da noch jemand Anderes durchsteigen. Deswegen ist die OOA auch unbedingt erforderlich, denn ein gutes UML schafft meisten einen sehr guten Überblick vom Gesamtkonzept und schafft eine vernünftige Grundlage für die OOP.

Was ist OOA?
Zur OOP:
Objektorientierte Programmierung in PHP ist nützlich aber nicht wichtig und vor allem nicht erstrangig.
PHP arbeitet das Dokument genau einmal ab (siehe Vorredner) und das wars dann.
Klassen bringen also auch nur etwas, wo man das über das ganze Script gebrauchen kann, wenn man z.B. die Klasse schon von Anfang an anlegt, dem Objekt einen Wert zuweist und diesen im Laufe des Scripts möglicherweise ändern möchte, oder das Objekt öfters seinen Dienst verrichten soll.
Dann kann man enstprechend machen $objekt->tuwas();

Es gibt viele Gründe FÜR OOP in PHP aber niemals alles in PHP und Gründe gegen prozedurale Programmierung seh ich eigentlich nicht. Die Software kann genauso gut transparent werden durch ordentliche Funktionen.

Das mit der Dokumentation von meinem Vorredner, da muss ich aber zustimmen. Habe das selbst schon erlebt. Da sitzt man Wochen dran an einem Code und muss sich dann irgendwann wieder selbst einarbeiten, weil man nicht mehr weiss, was die Klasse/Funktion erledigt.

Ui, der Beitrag ist über 3 Jahre alt? Naja, was solls.

Also OOP lohnt sich bei größeren Projekten, da der Code übersichtlicher ist und man Klassen mehrfach verwenden kann. Bei PHP schlampe ich ganz gern mal, da das OOP nur "gefaked" und umständlicher (als in Java) ist und bei kleineren Sachen einfach nur Zeit frist. Java code ich NUR OOP - wer hätte das gedacht *rolleyes*

Objektorientierung alleine ist erst einmal relativ nichtssagend. Oft genug werden Klassen nur eingesetzt, um eben zusammengehörende Prozeduren in einer Datei / DLL zusammenzufassen, der Modul-Begriff von Modula-II hat genau dasselbe geleistet.

Ich habe bei mir immer wieder festgestellt, daß ich für nicht zu große Kundenanwendungen 'richtiges OOP' (mit abgeleiteten Klassen und Interfaces oder mit abstrakten Klassen) nie brauche.

Man muß diese Begriffe allerdings trotzdem gut kennen - um die Bibliotheken (Java, NET) zu verstehen. Denn auf der Ebene dieser großen Gebilde sind die Strukturierungsmöglichkeiten, die OOP bietet, unverzichtbar.

Bei server-daten ist es natürlich eine drastische Vereinfachung, daß eine Klasse von der Page-Klasse abgeleitet und gleichzeitig das IRequiresSessionState - Interface implementiert - damit kann es alle .html-Dateien verarbeiten und Sessions nutzen. Und zwei andere Klassen implementieren die IHttpHandler-Schnittstelle - und können damit alle anderen Dateitypen ausliefern und bsp. durch Berechtigungsprüfungen ergänzen. Aber eine eigene abstrakte Klasse ist nur an einer einzigen, eher untypischen Stelle definiert.

OOA bedeutet objektorientierte Analyse. Einfach erklärt dient OOA dazu um Objekte grundlegend zu modulieren, unabhängig von gegeben Beschränkungen, wie bspw. einer begrenzten Rechenleistung - es wird bei diesen beispielhaften Punkt davon ausgegangen, dass unendlich viel Rechenleistung zur Verfügung steht. Hierzu wird unter anderen das Programm mittels dynamischen und statischen Modellen abgebiltet und durchläuft seine einzelnen Schritte, bis das Gesamtkonzept zwischen statischen und dynamischen Modell stimmig ist und keine Änderungen mehr erforderlich sind.

Nun, das Ganze kann man nun noch wesendlich weiter ausdehnen, OOA ist ein relativ großes Thema.

Hehe, witzig, auf alte Posts zu stossen, welche man in der Zeit, als man noch jung und dumm war, erstellt hat und sich gar nicht mehr daran erinnert hatte. ;-)

Zum Thema: In den vergangenen Jahren habe ich OOP verstehen und schätzen gelernt. Mittlerweile bin ich bei der Programmiersprache Ruby gelandet, welche einem sehr grosse Freiheiten lässt, wie genau man etwas programmieren will, selbst jedoch 100% objektorientiert ist (und wenn ich 100% sage, dann meine ich mindestens 1% mehr als Java von wegen primitiven Datentypen etc.).
Spätestens seit ich mit Ruby on Rails, einem MVC Web-Framework basierend auf Ruby, arbeite, begreife ich, welche tollen Möglichkeiten gute Designstrukturen bieten, und diese müssen nicht zwingend oo sein, auch wenn es sich natürlich sehr anbietet. Gerade an Ruby on Rails finde ich es schön, dass der Novize sich in vielen Bereichen wie in einem prozeduralen Umfeld fühlen kann, und der OOP Profi sich mit all den Raffinessen von Ruby rumschlagen kann.
Ich empfehle jedem Webprogrammierer, sich die grundlegenden Features von RoR mal anzuschauen - und wer behauptet, ähnliche programmiertechnische Möglichkeiten und Raffinessen bieteten auch PHP Abkömmlinge wie CakePHP, der hat Grundlegendes von RoR nicht verstanden (ohne behaupten zu wollen, dass es nicht auch ohne diese gehe - aber wieso kompliziert, wenn es auch elegant geht?). :-)