Nach dem andere Blogs den Ball zum Thema “Regeln brechen” aufgenommen haben, hab ich mir ebenfalls nochmal Gedanken dazu gemacht.
René z.B. ist der Ansicht, das Programmierung im OOP Sinne wesentlich sauberer ist als prozedurale Programmierung. “Alles Geschmackssache” sagte der Affe und biss in die Seife ;) Ich denke, das Performance kein Freibrief für schlampige Programmierung sein sollte. Die kommt leider zu oft vor - ich kenne es von mir. Es gibt nur wenige Arbeitgeber, die genügend Entwicklungszeit einräumen und kein Verständnis entgegenbringen, wenn es um angemessene Projektzeiten geht.
Ich bin generell der Ansicht, dass man prozedurale Programmierung nicht mit Objektorientierter Entwicklung vergleichen kann. Das sind einfach zwei unterschiedliche Disziplinen. Die eine etwas einfacher und älter als die andere, aber beide haben Vorteile.
Wird ein Projekt nicht erst dann unübersichtlich und wirkt schlecht programmiert, wenn beide Arten zu programmieren mit einander vermischt werden?
Prozedurale Entwicklung
Auch moderne Umgebungen bieten oft einen prozeduralen Ansatz: Ein Beispiel ist Actionscript von Adobe, ehemals Macromedia. Mit Actionscript kann man durchaus größere Flash-Applikationen performant programmieren und mit üppigen Funktionen ausstatten.
Der Vorteil der Prozeduralen Entwicklung liegt meines Ermessens ganz klar in der Einfachheit der Strukturen. Die sind einfacher und somit schneller zu parsen, als bei OOP-Code. Ganz einfach weil die Abhängigkeiten nicht so üppig analysiert werden müssen.
Auch komplexe Projekte lassen sich prozedural lösen, die Übersicht muss nicht unbedingt direkt unter dem prozeduralen Faktor leiden - schließlich kann man in nahezu jeder prozeduralen Sprache Programmcode in beliebig viele Dateien aufteilen - Das geht bei Javascript, Actionscript und natürlich auch mit PHP.
Der Nachteil von prozeduraler Programmierung kommt erst dann zum Tragen, wenn es um die Entwicklung von umfassenden “Objekten” geht, die verschiedene Zustände und Instanzen haben können. Das geht nur auf biegen und brechen mit einfachen Funktionen und globalen Variablen. Solch eine Anwendung prozedural zu lösen, wäre ganz klar am Ziel vorbeigeschossen.
Objektorientierung
Objektorientierte Programmierung bildet genau das hervorragend ab, woran prozedurale Entwicklung scheitert: Objekte und ihre Zustände. Ganz klar die Spezialität von OOP, und das erklärt wohl auch die Namensgebung.
Fluch und Segen gleichzeitig bei OOP ist wohl die Klassendefinition, die fällt im Gegensatz zu prozeduralen Strukturen recht üppig aus, kann die verschiedensten Abhängigkeiten abbilden und tausend Sonderfälle berücksichtigen. Und dann gibt es ja noch die Vererbung.
Was bei einer Sprache mit Compiler vielleicht wenig ins Gewicht fällt, macht die Waagschale bei interpretierten Sprachen etwas schwerer, denn die ganzen Strukturen müssen zur Laufzeit analysiert und geparst werden. Das frisst Zeit - und zwar imens.
Mischmasch oder Homogenität
Spassig wirds, wenn OOP und prozedurale Entwicklung vermischt wird. Passiert ganz automatisch bei meinen drei Lieblingen: Actionscript, Javascript und PHP. Die Sprachen sind von Natur aus nicht homogen aufgebaut und bringen allesamt sowohl prozedurale Funktionen wie Objekte mit.
Wenn sich dazu die Entwicklungsstile verschiedener Entwickler mischen, ist es ganz schnell vorbei. Denn es ist für ein Projekt tödlich, prozedural gewachsenen Code mit schicken neuen Objekten zu bereichern. Man sollte schon einen Programmierstil beibehalten.
Da mach ich eine Wette auf: Komplexer, aber homogener Prozeduralcode ist einfacher zu pflegen und weiterzuentwickeln als ein Haufen OOP/Prozedural/Mischmasch. Wenn man mit einem Projekt einmal an die Stelle kommt, wo man prozedural nicht weiter kommt, funktionieren nur ein paar Dinge wirklich:
- neu aufsetzen und objektorientiert entwickeln
- knallhartes refactoring
Was jetzt wann wie wo
Wie schon erwähnt, manche Programmiersprachen nehmen dem Entwickler nicht die Entscheidung ab, wie entwickelt wird. Gut habens da C++ und Java-Entwickler. Wenn man mit einem Interpreter arbeitet, dreht sich letzten Endes alles um die Performance.
Spart man bei einem Funktionsaufruf etwa 5% Ausführungszeit, dann sind das bei einer Sekunde etwa 3 Millisekunden pro Ausführung. Wenn man einen hochfrequentierten Server mit 1000 Abrufen pro Sekunde hat, macht das wieder 3 Sekunden - Das wären dann 3 Besucher mehr, die in der selben Zeit abgefrühstückt werden können.
Ich denke, es ist eine gute Idee, ein bisschen Performance durch die Nutzung von globalen Funktionen zu ziehen. Solange es die Programmiersprache zulässt. Die Vermischung sollte allerdings nicht überhand nehmen und nur für Hilfsfunktionen gelten, die man schlecht gruppieren kann.
Wenn man beispielsweise mehrere Funktionen zur Stringmanipulation hat, bietet es sich an, diese Funktionen in einer Klasse zusammenzufassen. Denn dafür sind Klassen ja da. Eine Klasse mit nur einer Hilfsfunktion aufzustellen wäre meiner Meinung nach allerdings unnötiger Overkill.
Solche Dinge sollte man für Projekte immer in einer Coding-Guideline festlegen. Dann kommen keine Programmierer-Eigenen Stilblüten zum Vorschein und man erhält ein homogenes Projekt - auch mit vielen Köchen ;)
Warten wir mal ab, was mit PHP noch passiert. Vielleicht müssen PHP Scripte bald vor der Ausführung generell kompiliert oder in Bytecode umgewandelt werden. Von Vorteil wäre es allerdings.
