Nutzt Ihr Dinge aus der professionellen Softwareentwicklung?

Hi,
ich wollte mal allgemein Fragen, was Ihr so für Sachen benutzt aus der professionellen Softwareverwaltung. In wie weit die Dinge benötigt werden bzw. was eure Alternativen dazu sind.
In wie weit die Dinge professionell sind kann man ja auch diskutieren.
Für mich persönlich (was ich in einem anderen Thread schon angedeutet habe) gehört alles zu einem Projekt hinzu, was sich halbwegs professionell nennen will.
Versionsverwaltung sollte im Team (ich nutz es auch als einzelner Entwickler und will es nicht missen) nie fehlen, weil ansonsten einfach zuviel Zeit verloren geht die Arbeiten an den Dateien zu Koordinieren und es zu aufwendig wird, alle Änderungen am Quellcode auf Dauer nachzuvollziehen.
Bugtracker ist gut um Aufgaben, Fehler und Feature-Wünsche zu sammeln und in einem Team nacheinander abzuarbeiten. Vor allem wird auf diese Weise jegliche Arbeit inhaltlich Dokumentiert, in Verknüpfung einer Softwareverwaltung auch sogar mit den Änderungen am Quellcode verbunden.
OOP und Exception Handling erleichtern sehr den Aufbau und Fehlerbehandlung in PHP und sind eigentlich die geilste Erfindung seit es PHP gibt. Datenkapselung, Wiederverwendbarkeit und komplexe Strukturen einfach abbilden sind nur ein paar der Vorteile wie ich finde.
API Kommentierung ist vor allem wichtig, wenn man nach ein paar Wochen/Monaten in Programmteilen Bugs beheben, Funktionalitäten erweitern oder einfach optimieren will. Ohne das, muss man sich immer wieder in den Quellcode einlesen und kann nicht einfach nachschauen was die Methode oder Klasse macht.
Hoffe auf Rege Beteiligung, angehakt kann von alles bis nichts

Die Umfrage ist nicht besonders gut gestaltet... ich nutze z.B. zwar OOP (PHP5), aber kein Exception Handling.
Desweiteren fehlt eine Option, dass man die genannten Dinge nicht nutzt... ohne die bekommst du aber überhaupt keine aussagekräftigen Zahlen...
Gruß,
Marc

1&2 wollt ich schon immer mal aufsetzen ..
3. ist naja. ich finde gerade in php kann man es übertreiben. Wenn ein request 0.1sec dauert, dabei 100 objekte erstellt werden müssen (inkl. tonnen von db-anfragen), nur um am ende wieder vernichtet zu werden, dann denke ich, dass dies wenig sinnvoll ist.
also gerade in php ist das etwas schwachsinnig. in java oder einer anderen sprache, die persistent läuft und das alles cachen kann, dann ist das imo überhaupt kein problem.
zu 4.: ich setze auf klare strukturen, kurze methoden und eine sinnige benennung. wenn ich mal was nicht weiss: 1-2 kommentare gibt es an den wichtigsten stellen - ansonsten kann man den code leicht verstehen.

Original von raufaser
Die Umfrage ist nicht besonders gut gestaltet... ich nutze z.B. zwar OOP (PHP5), aber kein Exception Handling.
Desweiteren fehlt eine Option, dass man die genannten Dinge nicht nutzt... ohne die bekommst du aber überhaupt keine aussagekräftigen Zahlen...

Darf die Umfrage nicht mehr nachträglich ändern und ich hatte keine Ahnung wie ich das sonst hätte gestalten können

Original von Drezil

3. ist naja. ich finde gerade in php kann man es übertreiben. Wenn ein request 0.1sec dauert, dabei 100 objekte erstellt werden müssen (inkl. tonnen von db-anfragen), nur um am ende wieder vernichtet zu werden, dann denke ich, dass dies wenig sinnvoll ist.
also gerade in php ist das etwas schwachsinnig. in java oder einer anderen sprache, die persistent läuft und das alles cachen kann, dann ist das imo überhaupt kein problem.
PHP kann das verdammt gut cachen, siehe Compilercache, dann werden deine Klassen nur einmal geparst und ab dann kommt es ausm Cache. Wenn du Daten zwischen Funktionen mit Arrays hin und her schiebst ohne Adressoperator dann werden die Daten jedes mal kopiert, ein Objekt nicht. Das geht wesentlich auch schneller (nur eines der vielen Vorteile, was die Performance betrifft).
Geschweige denn von den Vorteilen der Modularisierung und Datenkapselung. Mehr Übersicht, sichere Zugriffe und Manipulationen an Daten und vor allem Wiederverwendbar.
Im übrigen geht bei vielen größeren Projekten sehr viel Zeit drauf zum parsen der ganzen Skripte, mit OOP und Compilercache biste da wesentlich schneller.

Original von Drezil

zu 4.: ich setze auf klare strukturen, kurze methoden und eine sinnige benennung. wenn ich mal was nicht weiss: 1-2 kommentare gibt es an den wichtigsten stellen - ansonsten kann man den code leicht verstehen.
Auch klare Strukturen würden eigentlich keine Dokumentation ersetzen. Du musst ja nicht nur wissen was du machst (das kann man bei klaren Strukturen noch rauslesen) sondern vor allem auch warum du es so gelöst hast. Nur so kann man Sachen später noch gut nachvollziehen. Außerdem ist es (finde ich) wesentlich einfacher 5 Zeilen Kommentar zu lesen als 30 Zeilen PHP Quellcode um zu wissen was eine Funktion macht.
Vor allem im Team wichtig. Damit jeder deine Sachen nutzen kann und versteht was Sie machen ohne sich in den Quellcode einlesen zu müssen. Außerdem zeigen viele IDEs die Kommentare an, wenn man eine Funktion/Klasse benutzt (Parameterliste zum Beispiel).

Entschuldige bitte und verbesser mich, wenn ich falsch liege,
aber ich habe das Gefühl,
das du teilweise mit "coolen" Begriffen um dich wirfst.
Zum Beispiel compilercache, google mal bitte danach.
Du meinst sicher ein PHP accelerator/opcode cache,
der nichts weiter macht,
als die Scripte in "kompiliertem" Zustand zu speichern
und damit den Overhead des Parsens spart.
Die 100 includes müssen trotzdem gemacht werden
und die 100 Objekte müssen trotzdem bei jedem
Request neu erzeugt werden.
> Im übrigen geht bei vielen größeren Projekten sehr viel Zeit
> drauf zum parsen der ganzen Skripte,
> mit OOP und Compilercache biste da wesentlich schneller.
In der Regel ist PHP, in der jetzigen Version, nonOOP schneller.
Es wurde neulich bereits an anderer Stelle gesagt,
OOP ist kein Allheilmittel sondern eine Programmiertechnik.
Exception Handling ist auch so eine Sache.
Ich meine es ist doch klar, das man eventuelle Fehler abfängt.
Das macht doch hoffentlich jeder.
Das hat man auch schon bei PHP > 5 gemacht.
Kommentare sind teilweise sehr wichtig.
Aber auch hier kann man es meiner Meinung nach übertreiben.
Ich nutze selbst keine Versionsverwaltung, kein Bugtracker
und kurze, aussagekräftige Kommentare.
Ach ja und ( bei PHP ) kein OOP.
Als PHP accelerator nutz ich APC.

In der Auflistung fehlen aber noch so einige interessante Punkte. Aber der Reihe nach:
Versionsverwaltung ist klar, gerade da wir im Team arbeiten. Aber auch wenn ich alleine an einem Projekt arbeite, kommt sie zum Einsatz. In unserem Fall ist es SVN.
Bugtracker ist auch ein Muss, wobei Bugtracking allein meist nicht ausreicht. Zur Zeit verwenden wir Trac, aber ich bin am überlegen, auf Lighthouse umzusteigen, um eine vollständige Projektverwaltung zu haben.
OOP mit allem was dazu gehört ist auch klar, gerade da wir auf Basis von Rails entwickeln. Zu der passenden Diskussion wegen PHP5: Es kommt natürlich auch stark darauf an, wie die Skripte zur Ausführung gebracht werden. Stichwort FastCGI.
API Dokumentation machen wir auch, aber nicht so exzessiv. Das hängt natürlich auch mit an der Sprache und dem daraus resultierendem Code Umfang.
Was mir bei der Umfrage noch fehlt, sind solche Sachen, wie Test-Driven-Development inkl. Test-Coverage (machen wir), Behavior-Driven-Development (da wollen wir hin), Database Migration (wird gerade eingeführt) und Deployment Unterstützung (wird bei uns Capistrano werden).
Und wir nutzen in manchen Bereichen auch diverse Modellierungstechniken, wie ER-Modelle, UML, usw.

Original von Amun Ra
Entschuldige bitte und verbesser mich, wenn ich falsch liege,
aber ich habe das Gefühl,
das du teilweise mit "coolen" Begriffen um dich wirfst.
Zum Beispiel compilercache, google mal bitte danach.
Du meinst sicher ein PHP accelerator/opcode cache,
der nichts weiter macht,
als die Scripte in "kompiliertem" Zustand zu speichern
und damit den Overhead des Parsens spart.
Die 100 includes müssen trotzdem gemacht werden
und die 100 Objekte müssen trotzdem bei jedem
Request neu erzeugt werden.

Habe ich was anderes behauptet? Die includes müssen gemacht werden ja. Aber ich denke das eine logische Struktur in etwa gleich viel Code aufweist egal ob Sie OOP ist oder nicht. Von daher, ob ich 100 Skripte lade oder 100 Klassen kommt dann auf das selbe raus, nur dass mit OOP noch Accelerator und Co. besser mitwirken können. Und ja mit Compilercache hab ich das gemeint. Sry wenn der Begriff hier falsch ist, ich ging davon aus, dass dies ein allgemeiner Begriff ist, da mein PHP Buch, das sich damit befasst es so hinsetzt. Ich persönlich habe diesen noch nie verwendet (habe Webspace, darf nicht), habe aber noch keinerlei Probleme mit dem Erstellen von Objekten. Im übrigen müssen die Daten irgendwo gespeichert werden, ob dies in einem Objekt ist oder in anderen Variablen... Nur dass ein Objekt in der Übergabe immer als Adresse übergeben wird und somit schneller als einen String oder ein Array (zumindest ab PHP 5).

Original von Amun Ra

> Im übrigen geht bei vielen größeren Projekten sehr viel Zeit
> drauf zum parsen der ganzen Skripte,
> mit OOP und Compilercache biste da wesentlich schneller.
In der Regel ist PHP, in der jetzigen Version, nonOOP schneller.
Es wurde neulich bereits an anderer Stelle gesagt,
OOP ist kein Allheilmittel sondern eine Programmiertechnik.
Ich sehe OOP als ein Werkzeug, mit dem sich die meisten Probleme schneller, sicherer und sauberer lösen können als mit einer vergleichbaren Funktionsbasierenden Version. Bisher hab ich nur wenige Dinge, die sich überhaupt in der Form mit Funktionen lösen können. Aber allein schon, wenn man zwei Funktionen braucht, die sich eine Variable teilen kommt man nicht um eine Kapselung in eine Klasse rum, wenn man es sauber dargestellt haben möchte. Ohne geht es natürlich auch, früher wurde es ja so gemacht, aber es hat seine Gründe, warum jede moderne Sprache Klassen unterstützt, weil es ohne einfach nicht mehr gescheit geht.

Original von Agmemon

Was mir bei der Umfrage noch fehlt, sind solche Sachen, wie Test-Driven-Development inkl. Test-Coverage (machen wir), Behavior-Driven-Development (da wollen wir hin), Database Migration (wird gerade eingeführt) und Deployment Unterstützung (wird bei uns Capistrano werden).
Und wir nutzen in manchen Bereichen auch diverse Modellierungstechniken, wie ER-Modelle, UML, usw.
Dass in der Auflistung ein paar Dinge fehlen merke ich gerade, auch wenn ich mit manchen Begriffen von dir wenig anfangen kann. Techniken/Hilfsmittel zum testen sind mir in PHP bisher nur Unittests (oder ähnlicher Name) bekannt. UML hab ich tatsächlich noch rein nehmen müssen... Kann man denn eine Umfrage nicht nochmal ändern? ^^

Ich persönlich nutze
- Subversion (nicht sonderlich professionell, Preforce und andere Dinge sind mir allerdings zu teuer). Ich erhalte nur alle Monat mal ein solches Problem, dass ich manuell eingreifen muss. Auch lässt meine Eincheck-Disziplin sehr zu wünschen übrig. Meist werden es riesige Commits mit den Änderungen der letzten Woche.
- Visual Studio 2005 Standard: Von MS bei einer Werbeveranstaltung geschenkt bekommen. Geniale Sache.
- Microsoft Sandcastle: Tool zur automatischen Extraktion von Sourcecode-Dokumentaren zu einer Klassenübersicht (in Html oder chm). Der Anteil der Dokumentation bei meinen Programm bewegt sich zwischen 20 und 40%.
- Resharper: Geniales Hilfstool für Visual Studio
- Windows 2003 Web Edition: Ist allerdings per se nicht professioneller als Linux. Linux möchte ich wegen des fehlenden ASP.Net nicht nutzen.
- Datenbankdiagramme und UML-Diagramme per Visio: Ausreichend für meine Zwecke. Allerdings nur bei Neukonzeptionen. Bestehende Programme erweitere ich ohne Visio neu zu öffnen.
Ansonsten nutze ich selbstverständlich ausgiebig OOP (bleibt bei .Net und ASP.Net nicht viel anderes übrig). Da die Sache kompiliert wird, ist nahezu kein Performance-Unterschied zu spüren. Durch statische Datenhaltung können besonders oft benötigte Objekte vom Webserver über mehrere Requests gespeichert werden.
Automatisches Deployment geschieht per Visual Studio.
Unit-Tests bewegen sich bei mir in der Zahl von etwa 50 Tests bei besonders kritischen Routinen. Ich bin kein Fan von exzessiven Unittests, bei denen am besten noch mit einem zweiten Tool überprüft wird ob auch ja jede Sourcecode-Zeile vom Unittest erschlagen wurde (NCover + NUnit zum Beispiel).
Ich werfe lieber ausgiebig Ausnahmen. Diese werden dann von einem Fehlerhandler abgefangen und erhalte automatisch eine Mail. Eine Datenbankspeicherung habe ich irgendwannmal angedacht, aber in den letzten 6 Monaten Betrieb hatte ich keine Ausnahme mehr.

Original von DrakeL
Habe ich was anderes behauptet? Die includes müssen gemacht werden ja. Aber ich denke das eine logische Struktur in etwa gleich viel Code aufweist egal ob Sie OOP ist oder nicht. Von daher, ob ich 100 Skripte lade oder 100 Klassen kommt dann auf das selbe raus, nur dass mit OOP noch Accelerator und Co. besser mitwirken können. Und ja mit Compilercache hab ich das gemeint. Sry wenn der Begriff hier falsch ist, ich ging davon aus, dass dies ein allgemeiner Begriff ist, da mein PHP Buch, das sich damit befasst es so hinsetzt. Ich persönlich habe diesen noch nie verwendet (habe Webspace, darf nicht), habe aber noch keinerlei Probleme mit dem Erstellen von Objekten. Im übrigen müssen die Daten irgendwo gespeichert werden, ob dies in einem Objekt ist oder in anderen Variablen... Nur dass ein Objekt in der Übergabe immer als Adresse übergeben wird und somit schneller als einen String oder ein Array (zumindest ab PHP 5).

*argh* das forum hat meinen post gegrillt.
nochmal in kurz:
wenn 2 funktionen sich eine var teilen, dann geht das problemlos, wenn
a) die var per referenz als parameter übergeben wird oder
b) man eine global nutzt
Das du alleine keine probleme mit tonnen von objekten hast, ist mir klar. Mach mal weiter. Wenn du dann später mal 200-500 leute auf den server lässt, dann bricht er zusammen.
Ich hab grad mal ein bissl getestet und bemerkt, dass objekte echt per referenz übergeben werden. Ich frag mich immernoch, was der scheiss soll.. weil wenn ich was per referenz übergeben will, dann bin ich als programmierer derjenige, der das entscheidet. Aber bei Objekten scheint es als wäre zwischen foo($objekt) und foo(&$objekt) gar kein unterschied mehr.
Alle anderen Objekte werden meines wissens nach mit CopyOnWrite behandelt - sprich: übergabe per referenz, kopieren/duplizieren erst bei veränderung. Ne echte referenz macht man wie gewohnt mit &.
Aber man kann ja auch nicht zu viel von einer aufgebohrten Template-Engine erwarten. Bald fordern sicher noch leute, dass es auch objekte in einer Template-Engine in der Template-Engine gibt (sprich smarty), weil das doch soo viele probleme löst..
mir gehen die OOP-Fetischisten langsem genauso auf den Senkel, wie die GPL-Taliban .. Es gibt kein universelles Allheilmittel.

Original von Drezil
Ich hab grad mal ein bissl getestet und bemerkt, dass objekte echt per referenz übergeben werden. Ich frag mich immernoch, was der scheiss soll.. weil wenn ich was per referenz übergeben will, dann bin ich als programmierer derjenige, der das entscheidet. Aber bei Objekten scheint es als wäre zwischen foo($objekt) und foo(&$objekt) gar kein unterschied mehr.

Ich finde das ehrlich gesagt überhaupt nicht negativ, im Gegenteil, das war ein wirklich wichtiger Schritt in PHP5, denn wenn du OOP machst, dann ist es viel häufiger der Fall, dass du Objekte als Referenz übergibst, eben WEGEN der Performance. Wenn du eine Objekt nicht referenziert übergeben willst, kannst du das Objekt klonen. (www.php.net/manual/de/language.oop5.cloning.php)
In PHP4 wurde standardmäßig jedes Objekt bei der Übergabe geklont/kopiert. Das hat den Speicherverbrauch während der Laufzeit in die Höhe getrieben und die Performance hat darunter stark gelitten, weil es viel länger dauert ein Objekt zu kopieren, als eine Referenz darauf zu übergeben. Wenn du OOP gemacht hast musstest du alle Objekte immer von Hand referenziert übergeben.... das hat vielleicht genervt!
Ich hab bei mir auf einem kleinen Virtual Server lighttpd und php5 über fastcgi mit einem opcode cache laufen und mache nur OOP. Und das rockt wie die Hölle, ohne Witz. Sau schnell.
Mit PHP5 hast du keine Probleme mit OOP und der Performance.
just my 2 cent
Gruß,
Marc

Original von Drezil
nochmal in kurz:
wenn 2 funktionen sich eine var teilen, dann geht das problemlos, wenn
a) die var per referenz als parameter übergeben wird oder

Je nach Menge der verwendeten Variablen könnte das Problematisch und unübersichtlich werden.

Original von Drezil

b) man eine global nutzt
Global ist kein Mittel, es ist die unsauberste Art das Problem zu lösen. Mach mal in großen Projekten alles mit global. Spätestens wenn eine globale Variable von einem ganz anderen Programmteil aus versehen verwendet und manipuliert wird freut man sich auf die lange Bugsuche. Global ist ne gefährliche Angelegenheit, wäre wie wenn man sein Auto mit dem Schlüssel und offenen Türen in die Stadt stellt und nen Monat wartet.

Original von Drezil

Das du alleine keine probleme mit tonnen von objekten hast, ist mir klar. Mach mal weiter. Wenn du dann später mal 200-500 leute auf den server lässt, dann bricht er zusammen.
Geb ich dir vollkommen recht, ich hatte noch nie das Vergnügen eines fertigen Browsergames mit 500 Spielern. Wobei ich nicht denke, dass man da wegen dem OOP dann Probleme bekommen. Sondern eher wegen der Menge. Ob ich die Sachen per OOP bearbeite oder mit Funktionen sollte von der Laufzeit auf das selbe raus kommen (siehe letztes Kommentar weiter oben dazu, gleiche Variablen, gleiche Operationen, nur anders verpackt). Außerdem ist es für mich einfacher eine Klasse komplett als abgekapseltes Packet auf Performancemängel hin zu untersuchen und zu optimieren als einzelne Funktionen oder Skriptteile.

Original von Drezil

Ich hab grad mal ein bissl getestet und bemerkt, dass objekte echt per referenz übergeben werden. Ich frag mich immernoch, was der scheiss soll.. weil wenn ich was per referenz übergeben will, dann bin ich als programmierer derjenige, der das entscheidet. Aber bei Objekten scheint es als wäre zwischen foo($objekt) und foo(&$objekt) gar kein unterschied mehr.
Ganz und gar nicht. Nur weil es veraltete Sprachen so machen, die OOP erst später drangeheftet haben, heißt das nicht, dass PHP und Java (Ja, Java macht das genau so) die gleichen Fehler machen müssen. Wie sieht denn ein größeres OOP Projekt in C++ aus? Entweder sackt die Performance saumäßig ein, weil Objekte bei jeder Übergabe kopiert werden müssen, oder du hast ein Programm voller Zeiger, die (bei falscher Verwendung) recht schnell zu Fehler führen. In PHP und Java ist das perfekt gelöst, ein Objekt, egal ob 1 Variable enthalten oder 100 Variablen enthalten wird immer per Adresse übergeben, somit werden nur ein paar Byte übergeben, was im Vergleich zu Arrays und Strings sehr viel schneller geht.
Im übrigen kannst ein Objekt auch anders übergeben, indem es nicht mit $objekt übergibst, sondern $objekt->clone(). Musst nur die Clone Methode definieren. Aber das wäre, als wenn man nem Holzfäller die Kettensäge wegnimmt und Ihm nen Buttermesser gibt.

Original von Drezil

Alle anderen Objekte werden meines wissens nach mit CopyOnWrite behandelt - sprich: übergabe per referenz, kopieren/duplizieren erst bei veränderung. Ne echte referenz macht man wie gewohnt mit &.
Aber man kann ja auch nicht zu viel von einer aufgebohrten Template-Engine erwarten. Bald fordern sicher noch leute, dass es auch objekte in einer Template-Engine in der Template-Engine gibt (sprich smarty), weil das doch soo viele probleme löst..
mir gehen die OOP-Fetischisten langsem genauso auf den Senkel, wie die GPL-Taliban .. Es gibt kein universelles Allheilmittel.
Jep, andere Datentypen werden per Call by Value übergeben. Das ist aber auch ein Nachteil, da der komplette Inhalt kopiert werden muss, aber dafür kann mans ohne Rücksicht manipulieren.
Ich gebe dir Recht, es gibt kein universelles Allheilmittel, aber wieso soll ich mir das Leben schwer machen, wenn es mit neuen Techniken doch viel einfacher geht?
PS: Ein Allheilmittel kann es alleine schon nicht sein, weil OOP alleine kein Problem löst. Aber es ist ein Allzwegwerkzeug mit dessen Hilfe man Probleme lösen kann und in der Regel kann man dies wesentlich eleganter lösen als es jemals mit Funktionen oder Skripten lösen könnte. Natürlich nur wenn man es richtig benutzt, aber das ist bei jedem Werkzeug so.

>Ich hab grad mal ein bissl getestet und bemerkt, dass objekte echt per referenz übergeben werden.
In allen neuen OOP-Programmiersprachen werden Objekte standardmäßig per Referenz übergeben ;-) C++ ist Mithilfe der Zeigerarithmetik etwas flexibler, C# kann auch struct-Objekte festlegen, die per Wert übergeben werden. Aber ich fände ein standardmäßiges Klonen einen Overkill, da 95% aller Objekte per Referenz übergeben werden sollen.
BTW: *brrrrr* global, der Tod eines jeden Projektes. Spätestens wenn zwei Komponenten die gleiche global-Variable nutzen. Dann lieber statische Klassenvariablen, die das gleiche leisten, aber ordentlich im 'Namensraum' (soweit man in PHP von Namensraum reden kann) verpackt sind.
@DrakeL: Ich hasse Computer-Auto/Wohnungs-Vergleiche ;-)

Jep, "global" ist das "GOTO" von PHP. :-)
Gruß,
Marc

Teilweise geb ich ja Drezil Recht.
Zum Teil ist es vernünftiger funktionsorientiert zu schreiben oder die Klassen nur als Namensraum zu nutzen ohne die OOP-Features wie Vererbung, Polymorphie und anderen schönen Dinge zu nutzen.
Man muss nicht auf Gedeih und Verderben alles in Objekte packen. Ich bevorzuge lieber eine Mischen aus objektorientierten Programmieren und das was ich klassenorientiertes Programmieren nenne.
Dies zeigt sich, dass es dann Klassen mit einer sehr geringen Zahl von Eigenschaften (meist das Kern-Objekt) gibt, aber sehr vielen Methoden. Normalerweise würde es völlig ausreichen diese als reine Funktionen zu deklarieren, dann bekomme ich aber Probleme, da ich nicht all meinen Funktionen ein Präfix anhängen möchte. Daher nutze ich die Klasse einfach als Ordnungsobjekt. Zum Teil gibt es auch rein statische Klassen bei mir.
Aber jeden einzelnen Drachen in ein Objekt verpacken.... Nene, das wäre mir zuviel Aufwand (von der Performance wäre es egal, da .Net einen linearen Heap hat, der in praktischer Nullzeit Objekte erstellt und vernichtet).
Aber global..... Das kommt von der Bösartigkeit sogar vor goto.

Ich bin nicht abgeneigt Funktionen zu verwenden, wenn diese Sinnvoll sind, so isses ja nicht.
Zum Beispiel hatte ich lange Zeit Funktionen für das formatieren von Timestamp:

function toDate($timestamp)

...
function toTime($timestamp)
...
Waren bei mir 9 Funktionen (Tag, Monat, Jahr, Datum, Sekunde, Minute, Stunde, Zeit, Datum und Zeit), die alle einen Timestamp übergeben bekommen haben. Mittlerweile ist selbst dies zu eine Klasse gewandelt worden, die nur im Konstruktor nen Timestamp bekommt und Methoden hat um diesen formatiert auszugeben.

class Timestamp

{
protected $timestamp;
public function __construct($timestamp)
{
$this->timestamp = $timestamp;
}
public function toDate()
{
...
}
}
Aber bisher hab ich in der Engine nur Einstellungsdateien, Sprachdateien und die "index.php", die keine Klassen sind. Alle anderen Sachen könnte ich ohne Klassen überhaupt nicht lösen.
Allein meine Tabellenklassen, ich kann mit PHP ohne SQL auf einzelne Datensätze zugreifen, beliebig verändern, zurückspeichern und löschen:

//Benutzer mit der ID 5 laden

$benutzer = new BenutzerDatabase(5);
//Werte ändern
$benutzer->name = "Neuer Name";
//Speichern
$benutzer->save();
Das würde mit Funktionen überhaupt nicht ohne Probleme gehen. Und ohne Vererbung? Müsste ich für jede Tabelle eine Klasse machen mit allen Funktionalitäten um ein Statement zusammenzupuzzeln. Oder ich dürfte nur eine Klasse machen und müsste jedesmal Tabellenname übergeben, definieren was die Primary Key sind (fürs where) etc.
Ich weiß, dass ich es an manchen Stellen sehr übertreibe mit OOP, da ich wirklich alles in eine Klasse packe. Aber je mehr ich das tue, umso mehr sehe ich den Vorteil darin und merke, dass das was meine Engine leistet, mit einem funktionalem Aufbau überhaupt nicht möglich ist. (Soll jetzt nicht so eingebildet wirken, wie es vielleicht rüberkommt, will damit nur sagen, dass manche Sachen ohne Klassen gar nicht auf eine einfache Möglichkeit umzusetzen wären). ^^
PS: Ich übertreibe es teilweise auch, weil ich sehen will, was mit PHP alles möglich ist und die Grenzen der Sprache ausreizen will, das sau lustig.

Original von Drezil
Aber man kann ja auch nicht zu viel von einer aufgebohrten Template-Engine erwarten. Bald fordern sicher noch leute, dass es auch objekte in einer Template-Engine in der Template-Engine gibt (sprich smarty), weil das doch soo viele probleme löst..

Also ich verwende in meinen Rails-Projekten und in meinen Java-Projekten Objekte in der Template-Engine. Wäre ja noch schöner, wenn ich die erste wieder zerlegen müsste, um sie zu visualisieren.
Und was die angeblichen Performance-Probleme betrifft, sollte man sich vielleicht mal überlegen, ob das an OOP selbst liegt oder an der Implementierung in PHP und wie sie dort eingesetzt wird.
PHP hat in seinen Anfängen gar kein OOP unterstützt, hat dann etwas bekommen, was dem Entwickler OOP vorgegaukelt hat und mit PHP5 wurde nun der Schritt in eine vernünftige Richtung gemacht. Fakt ist aber, das OOP in PHP ein aufgesetztes Feature ist. Das kann natürlich nicht so gut sein, wie wenn eine Sprache direkt für OOP entwickelt wurde. Mein BG (Rails) hat im Moment 96 Klassen, wobei ca. 50% Testklassen für Unit-, Functional-, und Integration-Tests sind. Ich rechne damit, dass sich die Anzahl noch verdoppelt. In PHP würde ich da langsam anfangen, mir Gedanken zu machen. Das liegt aber nicht an OOP, sondern an der Art, wie klassische PHP Anwendungen den Request-Zyklus bearbeiten.
Der Request kommt rein, eine neue Apache Instanz wird erstellt (egal ob neuer Thread oder Fork), das Skript wird aus dem FS geladen, geparsed. Das gleiche geschieht dann noch für die Abhängikeiten, also die includes und Co.. Dann wird der Request abgearbeitet und der ganze Kram wieder vernichtet. Da geht natürlich Performance verloren.
In Rails funktioniert das ähnlich, wenn man sich im Development-Mode befindet. Aber interessant wird es, wenn man in den Production-Mode wechselt. Ich verwende das Grundsetup für Rails-Anwendungen: Einen klassischen Webserver, in meinem Fall einen Lighty, als Proxy und zum ausliefern statischer Inhalte. Dahinter habe ich ein kleinen Mongrel-Cluster. Mongrel ist ein kleiner Web-/Appserver für Rails. Bei dessen Start, wird die komplette Anwendung geparsed und vorgehalten, die Datenbankverbindungen initialisiert, usw.. Caching und ähnliche Geschichten nicht mitgerechnet, habe ich eine Leistungssteigerung gegenüber Parsen bei jedem Request von über 50%.
Ähnlich verhält es sich natürlich auch bei .NET mit dem JIT-Compiler und Java, je nach verwendeter Technik. Bei JEE5 werden z.B. schon fertig initialisierte Objekte und Daten vorgehalten.
In PHP lässt sich ähnliches erreichen, wenn man ein Setup verwendet, wie raufaser es verwendet.
Die angeblichen Performance Probleme entstehen also nicht durch den Einsatz von OOP an sich, sondern durch das verwendete Setup. Aber das ist im PHP-Bereich noch nicht vollends angekommen.

Wir nutzen das volle Programm, wobei Bugtracking etwas eingeschlafen ist, da wir atm schnell fixen können und ein verkleinertes Team haben.
Bei neuen Sprach-Features (gibts allerdings bei Java nicht so massig, letztes nennenswertes waren Enumerations) machen wir oft eine Referenz-Implementierung bei einem aktuellen Problem, allerdings gehen wir nicht so weit alten Code umzugraben.
Als VCS setzen wir Subversion ein, wobei wir trotz verbesserungsfähiger Commit-Disziplin und Branches sowie ohne Lock-Features keine Probleme bisher manuell lösen mussten. Als Clients nehmen wir TortoiseSVN sowie das - verbesserungsfähige - Netbeans-Plugin.
Als IDE arbeiten wir mit Netbeans, für die es auch eine Reihe nützlicher Web-Entwicklungs-Plugins gibt, aber vor allem gute Features für Refactoring und Code-Generierung.
Für Klassen-Rümpfe und (Reverse-)Modelling ist ArgoUML kostenlos und inzwischen ganz gut handhabbar (unbedingt Windows-Look-And-Feed bei Win einstellen...!).

Ich will mich in den Glaubenskrieg hier garnicht einmischen, nur kurz etwas einwerfen:
Arrays, Strings und alles was so an Parametern anfällt werden als "Copy on Write" übergeben. Das bedeutet, dass essentiell eine Referenz übergeben wird, und sobald was geändert wird, wird erst das Objekt kopiert.

Außerdem ist es für mich einfacher eine Klasse komplett als abgekapseltes Packet auf Performancemängel hin zu untersuchen und zu optimieren als einzelne Funktionen oder Skriptteile.

Es ist aber ein riesen-Aufwand, von der Klassenstruktur wieder zu einem sauberen Prozeduralen Aufruf zu kommen.
Und dass bei deinem Paket schon die Objekte selbst das Perfomanceproblem darstellen können, ist dir bewusst? Viel Spaß beim "Perfomance fixen".

Von daher, ob ich 100 Skripte lade oder 100 Klassen kommt dann auf das selbe raus, nur dass mit OOP noch Accelerator und Co. besser mitwirken können.

Weiß nicht woher du dieses Wissen nimmst, das ist mir wirklich neu - mein Wissen und meine Erfahrung sprechen zu 100% dagegen.

Original von Nuky
Arrays, Strings und alles was so an Parametern anfällt werden als "Copy on Write" übergeben. Das bedeutet, dass essentiell eine Referenz übergeben wird, und sobald was geändert wird, wird erst das Objekt kopiert.

Das ist mir neu, aber sehr gut zu wissen. Daher solang man Sie nicht verändert, sind se genau so schnell. Dann muss man aber aufpassen, dass man Sie auch nicht ändert.

Original von Nuky

Es ist aber ein riesen-Aufwand, von der Klassenstruktur wieder zu einem sauberen Prozeduralen Aufruf zu kommen.
Und dass bei deinem Paket schon die Objekte selbst das Perfomanceproblem darstellen können, ist dir bewusst? Viel Spaß beim "Perfomance fixen".
Warum sollte man das auch tun? ich will es auch nicht ändern in einen Prozenduralen Aufruf, sondern ein Objekt einzeln nehmen und dies durch testen auf Performanceschwächen.
Ich wüsste keinen Grund warum Objekte ein Problem darstellen sollten. Höchstens die Menge an Klassen die geparst werden müssen. Wobei die Menge an Code in etwa gleich oder bei kleiner ist, daher sollte da wenig Unterschied sein.

Original von Nuky

Weiß nicht woher du dieses Wissen nimmst, das ist mir wirklich neu - mein Wissen und meine Erfahrung sprechen zu 100% dagegen.
Mein Buch, das sich mit Performance beschäftigt
Kann sein, dass ich es falsch verstanden habe, hab das Thema mehr überflogen, da es für mich noch nicht relevant ist, weil ich kein Accelerator und Co einsetzen kann. Aber soweit ich verstanden habe, lassen sich Klassen besser cachen als Skripte bei denen HTML und PHP gemischt ist.

Lustig, ich habe gerade vor kurzem auch ein Buch von Schlossnagle gelesen.

Ich wüsste keinen Grund warum Objekte ein Problem darstellen sollten. Höchstens die Menge an Klassen die geparst werden müssen. Wobei die Menge an Code in etwa gleich oder bei kleiner ist, daher sollte da wenig Unterschied sein.

Das ist die eine Meinung. Solang du deine Klassen für exakt eine Aufgabe schreibst, sinnvoll machst, und nicht überpowerst: ja.
Ich habe ein Gegenbeispiel für dich, auch wenns natürlich von der extremen Seite kommt:
Habe für einen Kunden das exV2 Content-Management-System umgeschrieben und angepasst. Eine der Anforderungen war, an alle Teilnehmer vom Forum sofort eine Nachricht zu schreiben wenn ein neuer Thread kommt - in dem Kontext sinnvoll.
Nun wurde für die Klasse generiert, alle Emailadressen eingetragen, danach die Klasse mit (sinngemäss) $mail->send(); aufgerufen.
Fakt war, das nach jedem neuen Thema die Plattform ca. 8-10 Sekunden gebraucht hat um alle Emails zu versenden - und das auf nem dedizierten Server (2k+, 1gb ram, eAccelerator).
Nun hab ich den Aufruf (Klasse erstellen,...) auf einen (direkten) Funktionsaufruf reduziert.
Der Code ist ungefähr 1/10 so lang, mindestens 3x so lesbar und xfach so schnell änderbar.
Perfomanceunterschied? Mind. 1:50 - die Geschwindigkeit war danach im nicht mehr messbaren Bereich.
Wieso Klassen besser gecacht werden sollten ist mir absolut unklar.
Klassen sind dynamisch und können nur begrenzt vorkompiliert werden - auf den ausführbaren Code halt.
Wenn in einem Skript PHP und HTML gemischt ist, ist der HTML - Teil perfekt vorkompilierbar, da der ja wirklich statisch ist. Müsste also allein logischerweise schneller sein als eine Ausgabe mit "dvv" o.ä.
In meinem Buch spricht er zumindest davon, dass die Ausgabe von HTML - Tags in "" den Sinn von PHP stark verwirrt, und der PHP-Parser für gemischte Ausgabe Optimiert ist.
Ich glaube nicht, dass sich seine Meinung so schnell ändert..
Denk daran: PHP ist eine virtuelle Maschine! Alle Befehle werden nur indirekt ausgeführt - weshalb der Unterschied von PHP zu C & C++ Programmen und auch der Unterschied zwischen einer Funktion die in PHP geschrieben ist zu einem Aufruf einer PHP-internen Methode 1:100 beträgt!

Original von Nuky
Das ist die eine Meinung. Solang du deine Klassen für exakt eine Aufgabe schreibst, sinnvoll machst, und nicht überpowerst: ja.

Ich hasse überpowerte Klassen, bei mir bekommt jede Klasse exakt die Aufgabe, für die Sie gebraucht wird, und nicht mehr. Alles was nicht mehr gebraucht wird fliegt sofort raus.

Original von Nuky

Ich habe ein Gegenbeispiel für dich, auch wenns natürlich von der extremen Seite kommt:
Habe für einen Kunden das exV2 Content-Management-System umgeschrieben und angepasst. Eine der Anforderungen war, an alle Teilnehmer vom Forum sofort eine Nachricht zu schreiben wenn ein neuer Thread kommt - in dem Kontext sinnvoll.
Nun wurde für die Klasse generiert, alle Emailadressen eingetragen, danach die Klasse mit (sinngemäss) $mail->send(); aufgerufen.
Es macht 0 Sinn für jede E-Mail ein neues Objekt anzulegen, wenn überhaupt einzeln raus schicken, dann übergibt man der send() Methode einfach ein Array von Empfängern. Aber das würde ich nicht auf ein Problem von OOP schließen, sondern einfach von deren falschen Benutzung. Im übrigen würde es doch eigentlich mehr Sinn machen bei sowas, die E-Mail an eine allgemeine Adresse des Forums zu senden und alle Empfänger als BCC einzutragen. geht noch schneller.
Ich achte sehr darauf, dass eine Klasse keine Engpässe hat, zum Beispiel wird bei mir immer beim Erstellen eines Objekt einer Tabellenklasse auch die Beschreibung der Tabelle benötigt. Diese wird mit einer anderen Klasse zusammengebaut. Da sich die Beschreibung nicht ändert, wird diese in eine statische Variable gespeichert und nur beim ersten Gebrauch zusammen gepuzzelt.

Original von Nuky

Wieso Klassen besser gecacht werden sollten ist mir absolut unklar...
Ok, dann habe ich es wirklich falsch verstanden. statisches HTML oder allgemein direkte HTML Ausgaben gibt es bei mir jedoch nicht. Auch wenn es etwas Performance kosten mag, aber ich bau mir die HTML Seite mit einer XML Klasse zusammen.

Original von Nuky

Denk daran: PHP ist eine virtuelle Maschiene! Alle Befehle werden nur indirekt ausgeführt - weshalb der Unterschied von PHP zu C & C++ Programmen und auch der Unterschied zwischen einer Funktion die in PHP geschrieben ist zu einem Aufruf einer PHP-internen Methode 1:100 beträgt!
Aus dem Grunde sollte man nie eine eigene Funktion schreiben, wenn es ein äquivalent in PHP selbst gibt. Was ich auch nie tun würde bzw. im jetzigen Projekt auch nirgends getan habe

"Es macht 0 Sinn für jede E-Mail ein neues Objekt anzulegen, wenn überhaupt einzeln raus schicken, dann übergibt man der send() Methode einfach ein Array von Empfängern."
Es wurde EIN Objekt generiert, und dem pro Empfänger ein $mail->addRecipient($adresse) übergeben.
Ja, die haben da was falsch gemacht - ich hab gesagt, es ist ein extremes Beispiel.

Original von Nuky
Es wurde EIN Objekt generiert, und dem pro Empfänger ein $mail->addRecipient($adresse) übergeben.
Ja, die haben da was falsch gemacht - ich hab gesagt, es ist ein extremes Beispiel.

Ui, wie kann man da was falsch machen, was zu so einem extremen Unterschied führt? ^^ so ein Methodenaufruf ist ja auch nichts anderes als ein Funktionsaufruf.

Vielleicht mal ein paar Gedanken aus dem Compilerbau zu der Thematik:
Ob das eigentliche Parsen einen Unterschied macht, wenn man OOP oder prozeduralen Code hat, lässt sich eigentlich ganz einfach bestimmen. PHP wird zu den kontextfreien Grammatiken inkl. Rekursion gehören. Und Funktionen sind aus Sicht der Grammatik eine Untermenge von Klassen. Somit sind beim Parsen von Klassen mehr Schritte notwendig. Wenn dann noch Vererbung usw. dazu kommt, sind es noch mehr Schritte.
Und auch beim Ausführen, jetzt aus Interpreter-Sicht, wird es einen Unterschied machen. Ich mag jetzt nicht beurteilen, ob man PHP so den VM-artigen Interpretern zählen kann, oder klassisch interpretiert wird.
Aber man muss ganz klar unterscheiden. Das liegt nicht an OOP selbst, sondern alleinig an PHP und wie es eingesetzt wird. PHP ist nun mal für diesen Mix auf Code und HTML entwickelt worden, auch wenn das heute kein guter Stil mehr ist. Und alles was danach kam, sei es Trennung von Code und Visualisierung, OOP, usw. ist aufgesetzt und kann niemals so leistungsfähig sein, wie Sprachen, die gezielt für OOP entwickelt wurden.

Original von DrakeL

Original von Nuky
Es wurde EIN Objekt generiert, und dem pro Empfänger ein $mail->addRecipient($adresse) übergeben.
Ja, die haben da was falsch gemacht - ich hab gesagt, es ist ein extremes Beispiel.

Ui, wie kann man da was falsch machen, was zu so einem extremen Unterschied führt? ^^ so ein Methodenaufruf ist ja auch nichts anderes als ein Funktionsaufruf.
Die Frage hast Du Dir im Post vorher eigentlich selbst beantwortet. Schreibe niemals eine Funktion für etwas, was PHP von sich aus schon anbietet.
Bei n Empfängern hast du n Methodenaufrufe mit jeweils mindestens einer String-Operation. Direkt alle Empfänger als Array übergeben und in der Methode einen join machen, geht da schon viel viel schneller.

> ob man PHP so den VM-artigen Interpretern zählen kann, oder klassisch interpretiert wird.
Nur als Info: PHP 5 wird noch klassisch interpretiert [bzw der Opcode wird interpretiert, ist aber nicht mit Java-Opcode oder .Net-Opcode zu vergleichen]. Mit PHP 6 soll ein gemeinsamer Jitter mit Perl und Python rauskommen [glaube mit dem Namen Parrot]. Warum sie nicht auf bestehende Jitter wie Java oder der CLR gesetzt haben? Keine Ahnung, Konkurrenz belebt das Geschäft....