Vor- / Nachteile von Objektorientierung
0 0 
Marc Reichelt
0 
Der Martin
0
0 dedlfix
0 0 dedlfix
Vor- / Nachteile von Objektorientierung
Hallo Forum!
Ich stehe vor der Überlegung, eine Webanwendung mit PHP (leider Version 4.3) objektorientiert zu programmieren - oder eben nicht. Was mich davon abhält, ist vor allem auch das limitierte Objektmodell bei Versionen < 5, allerdings ist es in meinem Fall leider nicht möglich, auf Version 5 umzusteigen.
Allerdings kommt es mir auch so vor, als ob mir die komplette objektorientierte Programmierung nur Mehraufwand verursacht. Warum für jeden Krümel get- und set-Methoden schreiben? Auch die Sichtbarkeitsbereich von Objekten, die ja wohl nur die Ausführung des Skripts andauert, verursacht in meinen Augen viel Mehrarbeit (Objekte zwischenspeichern um wieder auf sie zugreifen zu können).
Ich finde den Einsatz von Klassen nur sinnvoll, bei den "klassischen" Funktionen wie z.B. einer Datenbankklasse, die sich um die Verbindung kümmert, der ich nur ein $db->executeQuery('...') übergeben muss und eine nette Antwort bekomme. Danach kann ich das Objekt löschen und alles passierte innerhalb eines Seitenaufrufs (ich brauche das DB-Objekt also nicht serialisieren und irgendwo zwischenspeichern).
Ansonsten kommt mir eine modulare Aufteilung sinnvoller vor. Ich will zum Beispiel gleiche Teile einer HTML-Seite, wie den Header-Bereich (von <!doctype bis <body>) oder z.B. das komplette Menü des Projekts in einzele php-Dateien auslagern, so dass ich sie per include laden kann und bei Änderungen nur einmal bearbeiten muss. Oder z.B. ein Datenbankmodul, dass alle DB-Funktionen enthält (und für Anfragen die DB-Klasse nutzt).
Einzelne Seiten des Projekts würde ich dann nach wie vor imperativ programmieren und dabei auf meine Module zurückgreifen. Ist das nicht viel einfacher, als auf Biegen und Brechen alles objektorientiert zu machen?
Welcher Meinung seid ihr? Was sind eure pro- und contra-Argumente für/gegen Objektorientierung mit PHP? Würd mich sehr interessieren - und vielleicht hilft's auch bei meiner Entscheidung.
Viele Grüße
osaki
-
Hallo,
Einzelne Seiten des Projekts würde ich dann nach wie vor imperativ programmieren und dabei auf meine Module zurückgreifen. Ist das nicht viel einfacher, als auf Biegen und Brechen alles objektorientiert zu machen?
selbstverständlich! Objektorientierte Programmierung ist ja kein Selbstzweck (obwohl - für manche Leute schon).
Das Tolle an PHP und anderen Scriptsprachen ist ja gerade, daß man einfache Dinge auch mit ein paar Zeilen Code erledigen kann. Aber Du hast das ja selbst schon ganz zutreffend formuliert, wie ich finde.
Sehr gut finde ich in diesem Zusammenhang den Artikel "Keep JavaScript Simple" von Peter-Paul Koch (http://digital-web.com/articles/keep_javascript_simple/) - auch wenn es da, wie der Titel schon sagt, nicht um PHP geht.Ciao,
Andreas--
"Das Corporate Design für das Internet sieht eine Reihe von Grafikelementen vor, die die Optik der Webseite visuell und funktionell beeinflussen." - (Zitat aus dem "Styleguide Corporate Design" eines großen Konzerns...)-
selbstverständlich! Objektorientierte Programmierung ist ja kein Selbstzweck (obwohl - für manche Leute schon).
Das Tolle an PHP und anderen Scriptsprachen ist ja gerade, daß man einfache Dinge auch mit ein paar Zeilen Code erledigen kann.Hallo Andreas!
Danke für den Link, der Artikel spricht mir aus der Seele.Was mir inzwischen durch den Kopf schwirrt ist, wie man so eine "gesunde Mischung" der Programmierstile nennen könnte. Was kommt denn dabei heraus, wenn man "objektorientiert" und "modular" (wobei vielleicht auch eher "prozedural", denn das Auslagern von Code in Dateien macht ja kein noch kein Modul aus) in einen Topf wirft und gut umrührt? Das Paradigma der PHPartigen Programmierung?
Ist vielleicht alles etwas weit hergeholt, aber einmal angefangen kommen mir viele solcher Gedanken :)
Viele Grüße
osaki
-
-
Hallo osaki,
Ich stehe vor der Überlegung, eine Webanwendung mit PHP (leider Version 4.3) objektorientiert zu programmieren - oder eben nicht. Was mich davon abhält, ist vor allem auch das limitierte Objektmodell bei Versionen < 5, allerdings ist es in meinem Fall leider nicht möglich, auf Version 5 umzusteigen.
Das ist bedauerlich, da objektorientierte Programmierung erst ab PHP 5 wirklich Spaß macht.
Allerdings kommt es mir auch so vor, als ob mir die komplette objektorientierte Programmierung nur Mehraufwand verursacht. Warum für jeden Krümel get- und set-Methoden schreiben? Auch die Sichtbarkeitsbereich von Objekten, die ja wohl nur die Ausführung des Skripts andauert, verursacht in meinen Augen viel Mehrarbeit (Objekte zwischenspeichern um wieder auf sie zugreifen zu können).
Als PHPler kommt einem das so vor, auch eingefleischte C-Programmierer würden dir voll und ganz zustimmen. Wenn du die Vorteile von OOP wirklich kennen lernen möchtest, empfehle ich Java. In Java ist die OOP von vorne bis hinten durchgezogen. Natürlich kann man auch in Java die objektorientierte Programmierung vernachlässigen (z. B. in dem man nur die main-Methode und statische Funktionen benutzt).
Kurz gesagt: Der absolute Vorteil von OOP liegt in der Wiederverwendbarkeit der Klassen. Nehmen wir mal an, du hättest folgende Java-Klasse:
public Raumschiff { public double speed = 0.0; /* weitere Methoden des Raumschiffs */ }Nun kann man von außen die Geschwindigkeit des Raumschiffes beliebig ändern.
Jetzt kommt plötzlich eine andere Klasse daher und führt folgenden Code aus:Raumschiff raumschiff = new Raumschiff(); raumschiff.speed = 400000000.0;Die Geschwindigkeit des Raumschiffes wird also nun auf 400 Millionen Meter pro Sekunde gesetzt, was (nach der Definition der Klasse Raumschiff) beispielsweise gar nicht erlaubt sein sollte.
Bei der folgenden Klasse ist eine solche Änderung - dass ein Raumschiff beispielsweise nur so schnell fliegen kann wie die Lichtgeschwindigkeit es erlaubt - problemlos möglich, ohne dass die andere Klasse es bemerkt:
public Raumschiff { private double speed = 0.0; public void setSpeed(double speed) { this.speed = speed; } public double getSpeed() { return speed; } /* weitere Methoden des Raumschiffs */ }Die veränderte Klasse sähe dann etwa wie folgt aus:
public Raumschiff { private double speed = 0.0; public static final double LIGHTSPEED = 299792458.0; public void setSpeed(double speed) { if (speed >= 0.0 && speed < LIGHTSPEED) { this.speed = speed; } } public double getSpeed() { return speed; } /* weitere Methoden des Raumschiffs */ }Wenn nun eine äußere Klasse den Code
meinRaumschiff.setSpeed(400000000.0);
ausführen würde, würde der Befehl stillschweigend ignoriert (eventuell könnte nun auch eine Fehlermeldung gebracht werden).Also haben selbst set- und get-Methoden durchaus ihre Berechtigung. Vor allem deshalb, weil man nie weiß, wie die Klasse sich in der Zukunft verändern wird - und natürlich, was andere so alles mit der eigenen Klasse anstellen.
Als einzelner Programmierer wirst du dir jetzt eventuell sagen:
"Hey, wozu brauche ich das denn? Ich weiß schließlich genau, wie mein Code aussieht!!111"
Was aber nun, wenn plötzlich mehrere Programmierer am Projekt arbeiten?
Oder du selbst das Projekt einige Monate lang ruhen lässt und schließlich wieder in Angriff nimmst? Oder das Projekt sehr groß wird? Kommentare sind hier natürlich immer angebracht.Ansonsten kommt mir eine modulare Aufteilung sinnvoller vor. Ich will zum Beispiel gleiche Teile einer HTML-Seite, wie den Header-Bereich (von <!doctype bis <body>) oder z.B. das komplette Menü des Projekts in einzele php-Dateien auslagern, so dass ich sie per include laden kann und bei Änderungen nur einmal bearbeiten muss. Oder z.B. ein Datenbankmodul, dass alle DB-Funktionen enthält (und für Anfragen die DB-Klasse nutzt).
Das alles lässt sich über OOP üblcherweise sehr elegant lösen.
Einzelne Seiten des Projekts würde ich dann nach wie vor imperativ programmieren und dabei auf meine Module zurückgreifen. Ist das nicht viel einfacher, als auf Biegen und Brechen alles objektorientiert zu machen?
OOP heißt nicht immer "auf Biegen und Brechen objektorientiert machen".
Das geht bei PHP übrigens überhaupt nicht (es bleibt mindestens eine Zeile als Aufruf für die main-Methode). ;-)
Aber bei Projekten, wie du sie beschreibst, kann OOP durchaus eine sehr sinnvolle Erweiterung deines Horizonts sein.Welcher Meinung seid ihr? Was sind eure pro- und contra-Argumente für/gegen Objektorientierung mit PHP? Würd mich sehr interessieren - und vielleicht hilft's auch bei meiner Entscheidung.
Ich hoffe, ich habe dir den Vorteil von OOP ein wenig näher bringen können.
Und wenn du mal wirklich "richtig" mit OOP beginnen möchtest, würde ich dir Java sehr ans Herz legen. Java ist von Anfang an erst mal sehr ungewohnt (eben, weil alles objektorientiert ist), aber nach einigen Monaten hat man den ganzen Sinn dahinter verstanden.Grüße
Marc Reichelt || http://www.marcreichelt.de/
--
Linux is like a wigwam - no windows, no gates and an Apache inside!
Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)-
Hallo Marc,
[Ausführliche Darstellung des OOP-Konzepts]
Kurz gesagt: Der absolute Vorteil von OOP liegt in der Wiederverwendbarkeit der Klassen.
Ja, unbedingt. Diesen Vorteil kann man aber mit prozeduralen Ansätzen auch haben, wenn man einzelne Module sauber kapselt und ihre Schnittstellen klar dokumentiert.
Oder du selbst das Projekt einige Monate lang ruhen lässt und schließlich wieder in Angriff nimmst? Oder das Projekt sehr groß wird? Kommentare sind hier natürlich immer angebracht.
Und genau hier komme ich und sage: Das ist die Theorie, und sie hört sich verdammt gut an.
Die Praxis ist leider oft, dass Klassen für bestimmte Aufgaben existieren, aber sie sind jämmerlich bis überhaupt nicht dokumentiert. Dann verbringe ich als Programmierer nämlich die meiste Zeit damit, den Quellcode der Klasse zu analysieren, die ich eigentlich bloß einfach benutzen wollte. Und diese Code-Analyse ist wegen der oft recht komplexen Strukturen in OOP meist wesentlich schwieriger als in der klassischen prozeduralen Programmierung. In der Zeit hätte ich den Code oft schon neu geschrieben.OOP heißt nicht immer "auf Biegen und Brechen objektorientiert machen".
Gut, dass du das sagst. Denn genau in der gesunden Mischung von prozeduralen und ojektorientierten Ansätzen liegt IMHO das Geheimnis. Und um objektorientiert zu programmieren, braucht man nicht unbedingt eine Sprache, die das "offiziell" kann. Ich programmiere z.B. am liebsten in reinem C, (C++ mag ich nicht, weil es zur Schlamperei verleitet), *denke* aber dabei trotzdem oft objektorientiert.
Schönen Abend noch,
Martin--
Viele Fachleute vertreten die Ansicht, jedes Feature eines Programms, das sich nicht auf Wunsch abstellen lässt, sei ein Bug.
Außer bei Microsoft. Da ist es umgekehrt.-
Hallo Martin,
Kurz gesagt: Der absolute Vorteil von OOP liegt in der Wiederverwendbarkeit der Klassen.
Ja, unbedingt. Diesen Vorteil kann man aber mit prozeduralen Ansätzen auch haben, wenn man einzelne Module sauber kapselt und ihre Schnittstellen klar dokumentiert.
Du hast vollkommen Recht. Selbst der Linux Kernel ist auf diese Art und Weise geschrieben. Es ist aber nie echtes OOP - wenn jemand auf eine interne Variable zugreifen will, auf die er eigentlich gar nicht zugreifen sollte, so kann er das bei Sprachen wie C und C++ machen. Nicht so bei Java.
Oder du selbst das Projekt einige Monate lang ruhen lässt und schließlich wieder in Angriff nimmst? Oder das Projekt sehr groß wird? Kommentare sind hier natürlich immer angebracht.
Und genau hier komme ich und sage: Das ist die Theorie, und sie hört sich verdammt gut an.
Die Praxis ist leider oft, dass Klassen für bestimmte Aufgaben existieren, aber sie sind jämmerlich bis überhaupt nicht dokumentiert. Dann verbringe ich als Programmierer nämlich die meiste Zeit damit, den Quellcode der Klasse zu analysieren, die ich eigentlich bloß einfach benutzen wollte. Und diese Code-Analyse ist wegen der oft recht komplexen Strukturen in OOP meist wesentlich schwieriger als in der klassischen prozeduralen Programmierung. In der Zeit hätte ich den Code oft schon neu geschrieben.Bei C / C++ habe ich bei meinen letzten Recherchen genau das erlebt, was du gesagt hast. Bei Java hatte ich eine eklige Begegnung mit FOP, dessen Doku wirklich "ein wenig" zu wünschen übrig lässt.
Ansonsten habe ich mit den Dokumentationen (sprich: JavaDocs) sehr gute Erfahrungen gemacht. Die Java API ist das beste Beispiel für gute OOP und gute Dokumentation.Grüße
Marc Reichelt || http://www.marcreichelt.de/
--
Linux is like a wigwam - no windows, no gates and an Apache inside!
Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
-
-
Hallo Marc!
Als PHPler kommt einem das so vor, auch eingefleischte C-Programmierer würden dir voll und ganz zustimmen. Wenn du die Vorteile von OOP wirklich kennen lernen möchtest, empfehle ich Java.
Ja das sollte ich glaub wirklich machen, denn auch wenn ich denke, das Prinzip hinter OOP verstanden zu haben, fällt es mir schwer, dann auch wirklich konsequent so zu programmieren. Zumindest wenn ich dann (doch wieder) mit PHP programmiere. Wie gesagt, für eine Datenbank-Klasse hab ich follstes Verständnis, hier finde ich den Einsatz logisch. Also das Erstellen eines DB-Objektes
$db = new Database('server', 'user', 'password');
wobei die Verbindung automatisch per Konstruktor hergestellt wird. Dann beliebige Anfragen über $db->executeQuery('SQL ...'); oder $db->getResult('SQL...'); und am Ende das Objekt $db wieder löschen. Auch das Beispiel mit dem Raumschiff fand ich einleuchtend.Aber bei dem "Drumherum" tue ich mir schwer, auch wenn du geschrieben hast, dass sich das üblicherweise mit OOP elegant lösen lässt. Ich versuch das mal in einem Beispiel zu erläutern. Das folgende soll meine Seitengrundstruktur sein:
<!doctype ... >
<html>
<head>...</head>
<body>
<div class="menu">
link<br /> link<br />...
</div>
<div class="content">
...
</div>
</body>
</html>Angenommen, das Menü ist immer gleich. Mit dem Menü kann ich zwischen verschiedenen Seiten wechseln (das können aber auch mehr werden, wer weiß). Im "Content"-Bereich will ich meinen Inhalt anzeigen. Woraus der erzeugt wird, sei mal egal. Konsequenterweise bräuchte ich also eine Klasse, die folgendes kann:
class Website {
const $_DOCTYPE = '<!doctype ...>';
var $_htmlhead;
var $_menu = '';
var $_content;function website() {
// leerer Konstruktor
}function setHtmlhead($value) {
$this->_htmlhead = $value;
}function addMenu($desc, $link) {
$this->_menu .= '<a href="'.$link.'">'.$desc.'</a><br />';
}function setContent($value) {
$this->_content = '<div class="content">'.$value.'</div>';
}function draw() {
echo $this->_DOCTYPE;
echo '<html><head>'.$this->_htmlhead.'</head><body>';
echo '<div class="menu">'.$this->_menu.'</div>';
echo $this->_content;
echo '</body></html>';
}
}Um meine Seite darzustellen, muss ich jetzt schreiben:
$page = new Website();
$page->setHtmlhead('<title>test</title><meta name="..." />');
$page->addMenu('google', 'http://www.google.de');
$page->addMenu('selfhtml', 'http://forum.de.selfhtml.org');
$page->addContent('So, das hier ist also mein Inhalt');
$page->draw();Das ist jetzt natürlich sehr einfach, auch dass ich alles nur als Strings realisiere. Um es noch konsequenter zu machen, bräuchte ich wohl eine Klasse "menu", die einzelne Menüpunkte enthält und sogar eine Klasse "htmlheader", die mir set-Methoden für <title>, <meta...>, <style...> anbietet.
A B E R :
Warum nicht einfach so?
Die Datei "header.php" enthält
<!doctype ... >
<html>
<head>...</head>
<body>Die Datei "menu.php" enthält das Menü (und ist jederzeit getrennt vom Rest änderbar).
Die Datei "footer.php" enthält
</body>
</html>Meine Seite erzeuge ich durch
include ('./header.php');
include ('./menu.php');
echo '<div class="content">Das ist mein Inhalt</div>';
include ('./footer.php');...fertig. Tut genau das gleiche. Ist nicht objektorientiert aber in meinen Augen viel einfacher und verständlicher als das (sehr einfach geschriebene) Beispiel oben.
==> Klassen machen für mich irgendwie nur Sinn, wenn ich mit innerhalb von Objekten einer Klasse auch mit Daten arbeite.
==> Im oben beschriebenen Fall geht es nur um Ausgabe. Hier empfinde ich Klassen als überflüssig, wenn nicht sogar verwirrend.
Hm *grübelnd*
Viele Grüße
osaki
-
-
echo $begrüßung;
Warum für jeden Krümel get- und set-Methoden schreiben?
Ja, das frage ich mich auch jedes Mal neu und entscheide dann, ob sich dieses Vorgehen an dieser Stelle lohnt oder auch nicht.
Meiner Meinung nach ist es nicht sinnvoll, streng nach philosophischen Gesichtspunkten zu programmieren, oder alle Muster, die man unter der einen Programmiersprache verwendet, und die dort sinnvoll sind, 1:1 auf alle anderen Programmiersprachen zu übertragen. Wenn ein einfaches Array unter PHP die Aufgabe erfüllt, schreibe ich mir keine Collection-Klasse, nur weil das unter C# so üblich ist.
In Unkenntnis des konkreten Projekts ist es aber nicht einfach, um nicht zu sagen unmöglich, die passende Strategie dafür festzulegen. Hier hilft nur Erfahrung, um einschätzen zu können, ob eine bestimmte Realisierungsart sich in der Zukunft vielleicht als ungünstig erweisen wird, und ob sich ein Mehraufwand lohnt oder nur Ausführungszeit kostet.
Was mich davon abhält, ist vor allem auch das limitierte Objektmodell bei Versionen < 5
Immerhin eignet sich ein Objekt auch unter PHP4 schon dazu, zusammengehörige Daten zusammenzuhalten. Daten sind an das Objekt gebunden und liegen nicht lose im globalen Variablenbereich rum, wo sie jeder versehentlich überschreiben kann, nur weil man bei der Benennung von Variablen nicht genügend aufgepasst hat.
Das Kapseln von Aufgaben in Funktionen ist schon mal ein guter Ansatz für aufgeräumtes Programmieren. Mitunter ist es aber nur noch umständlich alle innerhalb einer Funktion benötigten Daten als Parameter zu übergeben und global $var; scheidet aus nicht nur philosophischen Gründen aus. Dann hilft vielleicht eine Klasse, die Übersichtlichkeit wiederherzustellen. Dies ist aber eine Entscheidung, die du als Programmierer selbst treffen musst. Und manchmal wirst du auch eine falsche treffen, doch auch solche Fehlentscheidungen helfen beim Sammeln von Erfahrung.
Auch die Sichtbarkeitsbereich von Objekten, die ja wohl nur die Ausführung des Skripts andauert, verursacht in meinen Augen viel Mehrarbeit (Objekte zwischenspeichern um wieder auf sie zugreifen zu können).
Das ist kein Problem objektorientierter PHP-Programmierung. Wenn du Daten über mehrere Seitenaufrufe zwischenzuspeichern hast, ist es egal, ob sie in Form eines serialisierten Objekts oder anderweitig (in der Session) abgelegt werden.
Was sind eure pro- und contra-Argumente für/gegen Objektorientierung mit PHP?
Diese Frage würde ich anders stellen. Zunächst einmal solltest du dich, bzw. sollten sich alle am Projekt beteiligten, generell über die Leistungsmerkmale bestimmter Techniken informieren, und diese aus möglichst objektiver Sicht kennenlernen. Ich schreibe absichtlich nicht "beurteilen". "Urteil" ist ein recht hartes Wort, und man könnte geneigt sein, dieses als unumstößlich anzusehen. Für ein Projekt ist es notwendig, nach Schema X zu programmieren, für ein anderes ist das nur Overkill. Wenn es an die Planung eines konkreten Projekts geht, ist daher immer wieder von neuem abzuschätzen, welche Techniken das beste Aufwand-Nutzen-Verhältnis bieten. Ich sehe es auch als sinnvoll an, selbst innerhalb eines Projektes diese Abschätzung für die einzelnen Teile vorzunehmen.
echo "$verabschiedung $name";
-
Hallo $name!
Danke für die Denkanstöße!Ja, das frage ich mich auch jedes Mal neu und entscheide dann, ob sich dieses Vorgehen an dieser Stelle lohnt oder auch nicht.
Also läuft das auch auf eine "Mischform" hinaus? Ich musste mal eine Tabellen-Auflistung von recht komplexen Daten programmieren und hatte mir dafür eine Klasse "table" geschrieben, der ich Zeilenarrays übergeben konnte und die mir die Erstellung und Ausgabe der HTML-Tabelle übernommen hat. Das fand ich praktisch, denn spätere Erweiterungen (Sortierung per Klick auf eine Spalte) konnte ich in der Klasse ändern. Der Grund für die Klasse war in dem Fall ursprünglich eigentlich Faulheit... ich wollte nicht zigmal <tr><td>...</td><td>...</td></tr> schreiben. Hätte ich nur eine Tabelle in dem Projekt ausgeben müssen, hätte ich sicher keine Klasse dafür geschrieben sondern einmal in den sauren Apfel gebissen.
Meiner Meinung nach ist es nicht sinnvoll, streng nach philosophischen Gesichtspunkten zu programmieren, oder alle Muster, die man unter der einen Programmiersprache verwendet, und die dort sinnvoll sind, 1:1 auf alle anderen Programmiersprachen zu übertragen.
Die ursprüngliche Philosophie von PHP war nicht objektorientiert, oder? Das Beispiel mit den Arrays und Collection-Klassen fand ich recht gut... Ich denke mir immer, dass Arrays (bzw. Funktionen auf Arrays) bei PHP "von Haus aus" so mächtig sind, dass man doch gerade so dazu gezwungen wird, mehr mit ihnen zu machen als bei anderen Sprachen.
ob sich ein Mehraufwand lohnt oder nur Ausführungszeit kostet
Ist das denn wirklich so, dass PHP beim Ausführen von objektorientierten Skripten langsamer ist als beim Ausführen prozeduraler Skripte? Ich hab einmal gelesen, aber leider nie bestätigt bekommen.
Viele Grüße
osaki-
echo $begrüßung;
Ist das denn wirklich so, dass PHP beim Ausführen von objektorientierten Skripten langsamer ist als beim Ausführen prozeduraler Skripte? Ich hab einmal gelesen, aber leider nie bestätigt bekommen.
Nicht vorhandener Code kostet natürlich keine Rechenzeit. Wenn jedes Mal eine Zugriffsmethode aufgerufen werden muss, muss mehr Code ausgeführt werden, als beim direkten Zugriff auf die Eigenschaft. Allerdings hält sich dieser zeitliche Mehraufwand in Grenzen.
Viel wichtiger als solch eine Mikrooptimierung ist eine generelle Analyse der Schwachstellen. Während sich hier vielleicht nur einige Mikrosekunden herausholen lassen, kann man bei der Datenbankabfrage möglicherweise Einsparungen im Sekundenbereich erzielen.
Schreibe dir doch mal ein kleines Laufzeit-Mess-Script. Du wirst sehen, dass du eine ziemlich hohe Anzahl Schleifendurchläufe brauchst, um überhaupt spürbare zeitliche Verzögerung festzustellen. Wenn du so eine hohe Anzahl Zugriffe in der Praxis haben solltest, werden sicher auch dementsprechend große Datenmengen anfallen, deren Übertragungszeit ein Vielfaches der Berechnungszeit ausmachen wird, so dass der Flaschenhals auch hier nicht die Berechnung darstellt.
Bei einem hochfrequentierten Server, glaube ich auch nicht an eine ausreichende Entlastung durch Mikrooptimierung in PHP-Skipten. Hier ist vielleicht eine Lastverteilung auf mehrere Server oder eine Umstellung des Programms auf direkt ausgeführen statt (mehr oder weniger) interpretierten Code erfolgversprechender.
echo "$verabschiedung $name";
-
-