d0ne

Hallo,

natürlich - "so macht man das halt" - versuche ich so viel Oop wie möglich zu benutzen, und so wenig Funktionen wie möglich zu benutzen.
Aber ich bin mir nicht sicher, ob es wirklich immer Oop sein muss und ob Funktionen "per se" schlecht sind.

Wenn ich z.B. ein Kontaktformular aufbaue, muss ich dafür eine eigene Klasse schreiben oder kann ich auch 2-3 Funktionen schreiben und das ist immer noch "sauber/richtig"? Soll ich versuchen, alles immer in Objekte/Klassen zu quetschen?

mfg
d0ne

Mister Ad

mermshaus

Funktionen sind natürlich nicht "per se" schlecht (stating the obvious, eh? ). OOP bringt allerdings viele Vorteile mit sich, die vor allem in umfangreicheren Projekten zum Tragen kommen.

Ich habe dazu leider keine gute Quelle griffbereit und möchte nicht mit "Buzzwords" um mich werfen, ohne sie zu erklären. Vielleicht so viel: OOP gruppiert Funktionalität in logischen Einheiten. Beim Einsatz muss (oder besser: darf) ich mich als Programmierer dann jeweils auf diejenige Funktionalität konzentrieren, die der Kontext hergibt. Ein Objekt bietet nur eine überschaubare Anzahl an Methoden an. Bei einem prozeduralen Programmierstil könnte ich theoretisch zu jedem Zeitpunkt jede Funktion mit jedem Argument aufrufen. Das wäre vor allem bei unbekanntem Code nur sehr schwer zu durchblicken. Versuche ich das bei OOP, wirft PHP automatisch aufschlussreiche Fehler (zum Beispiel bei falschen Methodenaufrufen oder falschen Objekttypen als Parametern). OOP verringert also üblicherweise durch diverse Hilfestellungen und Vorschriften die Komplexität, die der Programmierer managen muss.

Das führt zu einer Reihe an günstigen Nebeneffekten wie etwa der Vereinfachung von Teamarbeit oder der besseren Wiederverwendbarkeit von Bestandteilen eines Projekts, weil sich Abhängigkeiten wesentlich einfacher erkennen lassen, als wenn potentiell an jedem Punkt der Anwendung jede Funktion aufgerufen werden könnte.

Viele dieser Vorteile lassen sich bei rein prozeduraler Programmierung nur durch ganz extreme Disziplin (das meine ich nicht als Floskel ) und die Einhaltung projektspezifischer (nicht wie bei OOP allgemein standardisierter) Konventionen erreichen.

Tendentiell gilt es abzuwägen. Bei einem Umfang von "einigen Funktionen" wird sich niemand beschweren, dass der Code nicht zu überblicken ist. Aber je länger der Code wird und je weniger diszipliniert bei der Anordnung und Benennung und dem Einsatz von Funktionen vorgegangen wird, desto eher wirst du in Erklärungsnöte geraten, wenn du nicht auf OOP setzt.

Ich persönlich arbeite bei Produktionscode nahezu immer rein objektorientiert, für simple Codebeispiele oder schnell zusammengehackte Dinge halte ich mich dagegen oft an einfache Funktionen, da es in diesen Fällen oftmals keinen Sinn ergibt, Funktionalität in ein größeres Ganzes einsortieren zu wollen. Solche Entscheidungen sind aber auch subjektive Erfahrungssache.

PS: Ich bin weitgehend überzeugt davon, dass sehr gute Programmierer (wiederum keine Floskel) auch große Projekte prozedural programmieren können, ohne Nachteile zu erfahren. Aber generell empfehlen würde ich es nicht.

__________________
Blog | Buch | Kaloa

nikosch

Ein großer Vorteil von OOP ist, dass sie zusätzliche Namens- und Funktionsräume schafft. Damit bündelst Du in Klassen bspw. objektspezifische Funktionalität. Gerade in Frameworks, wo Komponenten nur bei Bedarf geladen werden (oder gar ungenutzte Komponentenzweige herausgestrichen), ist dieses Konzept viel weniger komplex, als einen Abhängigkeitsbaum von Funktionen untereinander zu definieren.
Wird eine Funktionalität in verschiedenen Kontexten allerdings immer wieder benötigt, gehört sie nicht mehr zur Klasse und man sollte über eine Neumodellierung nachdenken.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

mquadrat

Vorteil ist die Wiederverwendbarkeit. Nehmen wir doch einfach dein Formular-Beispiel. Klar kannst du jetzt eine Methode "Prüfe Formular" und eine Methode "Sende Formular als E-Mail" schreiben. Funktioniert wunderbar. Nun hast du ein zweites Formular. Und nun? Funktionen kopieren? Was passiert dann bei einer Änderung? Nehmen wir an, du gehst schon einen kleinen Schritt Richtung OOP und schreibst deine Methoden so, dass sie mit verschiedenen Formularen klar kommen, dann hast du in deiner Prüfen-Methode ein riesiges if, in dem du prüfst welchen Typ denn die Daten im Feld haben und entsprechend die Werte validierst. Funktioniert.

Nun nochmal als OOP. Es gibt eine Klasse Feld, von der erben die verschiedenen Feldtypen. Aufgrund der Polymorphie brauchst du kein if mehr. Deine Formular-Klasse hat einfach eine Liste mit Feldern. Welche konkrete Klasse die jetzt haben ist dem Formular egal. Hauptsache Feld. Kommt ein neuer Feldtyp dazu, brauchst du an der Formularklasse rein gar nichts zu ändern. Du könntest z.B. auch einen Feldtyp für berechnete Felder erfinden. Oder einen, der automatisiert auf Basis der anderen Felder versucht weitere Daten von einem Webservice abzurufen. Egal was du dir ausdenkst deiner Formularklasse ist das völlig egal. So bastelst du eine Bibliothek zusammen und die kannst du nun auch überall verwenden. Und hast du ein Projekt, in dem genau eine Funktion anders sein soll aber der Rest gleich, dann erbst du einfach von deiner Formularklasse und brauchst nur die Änderungen zu programmieren. Alles andere bleibt davon wieder unangetastet.

OOP ist ein sehr mächtiges Werkzeug. Bei fremden Code kommt dazu, dass man sich z.B. nur das Public-Interface anschauen muss. Alles was in der Klasse passiert kann einem egal sein. Bei einer reinen Methoden-Sammlung muss man immer erstmal suchen gehen was jetzt relevant ist und was nicht.

Also ich mag OOP.

Und ich glaub im Gegensatz zu Mermshaus nicht, dass alle OOP Programme auch rein prozedural geschrieben werden könnten. Alleine diese vielen if's, weil man nicht einfach ein Interface als gegeben voraussetzen kann... Wenn ich da an ORMs denke oder Workflow-Engines oder oder oder. Nein, ich denke das würde nicht gehen.

In PHP mag man an vielen Stellen drum rum kommen, aber z.B. .NET wäre ohne OOP nicht vorstellbar. Da wird es mit Code-Behind, Lambdas und Partial Classes ja richtig wild.

__________________
Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

mermshaus

Na ja, die Frage ist vielleicht etwas theoretisch. C wird eingesetzt, .NET und Java werden eingesetzt. Die Anwendungsbereiche überschneiden sich natürlich nicht unbedingt. The right tool for the job.

-- http://www.wisegeek.com/what-is-proc...rogramming.htm

Aber wie gesagt, es ging mir nicht darum, Stellung gegen OOP zu beziehen -- ganz im Gegenteil.

__________________
Blog | Buch | Kaloa

mquadrat

Klar, wenn man eine SPS programmiert, wird es auch arg eng mit OOP. Ich wollte ja nur betonen, dass es meiner Meinung nach Systeme gibt, die ohne OOP entweder nie oder nur mittels Schuß durch das Knie in den Rücken zu machen wären.

__________________
Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de