Mailinglisten-Archive |
Hi Ihr, hi Norbert, Norbert Pfeiffer schrieb: > Und nun zum Thema OOP: > OOP ist ein "Aufsatz" um Leuten ohne jede mathematische > Vorstellungskraft zu ermoeglichen Programme zu fabrizieren. > Es ist nicht zwingend notwendig und verlangsammt in allen > Interpreter-Sprachen einfach nur die Ausfuehrung, denn > der Interpreter muss die "varbal-indizierte" Objekte erst > wieder in "maschinenlesbaren" Code umwandeln. Da merkt man, aus welcher Generation ein Entwickler kommt - ich kann mich auch noch gut an die Diskussionen für und wider objektorientierter Programmierung erinnern. Aber ich greif Norberts Ansatz jenseits des "Aber das ist State of the Art" mal auf, wenn auch ein bischen anders, in ein paar Stichpunkten. Wenn man vor der Entscheidung steht, eine Sprache für eine Enterprise-Anwendung zu wählen, dann spielen andere Faktoren als bei einer einfachen 10.000-Zeilen-Webanwendung eine Rolle. 1 z.B. die Austauschbarkeit von Modulen/Komponenten Eine Sprache, die den Zugriff auf private Variablen schlicht nicht erlaubt, ist besser dafür geeignet, weil der Programmierer gezwungen wird, sauber zu kapseln. Das heisst aber nicht, dass eine Sprache mit ohne private Variablen nicht den gleichen Grad an Austauschbarkeit erreichen kann. Es heisst nur, dass hier ein zusätzlicher Kontrollaufwand existiert, der bei den Alternativen nicht anfällt. 2 z.B. die Verlässlichkeit der Zustände Bei einer Sprache, die mit fixen Typen arbeitet, kann man sich darauf verlassen, dass der falsche Inhalt nicht durch eine übersehene Umtypung durch die Sprachengine erzeugt wurde, sondern durch einen Input- oder Logikfehler. Will man das gleiche bei PHP erreichen, muss man zend_operators.c lesen und verstehen, und ab und zu mal === oder auch (int) verwenden, und das ganze nachkontrollieren. Vorrausgesetzt, es treten hinreichend Fehler durch eine nicht wahrgenommene Umtypung auf. ( Jeder, der eine Weile PHP programmiert, hat vermutlich schon einige derartige Fehler gefunden - ich selbst wohl ca. 20 ) 3 z.B. die Entwicklungseffizienz Wieviel Zeit benötigt man, um eine Funktionalität X in der Hand zu halten ? Dieser Faktor ist bei Enterprise- Anwendungen anders, weil hier mehr als 50 % der Zeit für Analyse, Planung, Design und Qualitätssicherung gebraucht werden. Wie in 1 und 2 beschrieben, sparen z.B. eine saubere Kapselung und eine starke Typisierung dabei Zeit. Auf der anderen Seite spart aber auch eine Lightweight-Sprache wie PHP Zeit: - man braucht keinen Definitions-Tanz aufzuführen, um auf eine Funktionalität zugreifen zu können - durch einen frühen Prototypen - der in PHP imho mit deutlich weniger Kosten als im Java-Umfeld zu realisieren ist - spart man nachträgliche Change-Requests und bekommt frühzeitig eine präzises Bild der Kundenanforderungen. - nachträgliche Erweiterungen und Änderungen von kleinem Umfang sind schnell umsetzbar - man bekommt recht preiswert eine felsenfest laufende Installation, ohne undokumentierte Compiler-Flags beim Sun-Support einkaufen zu müssen ;-) IMHO gibt es keine Boolean-Antwort auf die Frage nach der richtigen Sprache für Online-Enterprise-Anwendungen. Es hängt eher von der Kombination der Rahmenbedingungen ab, welche Sprache für weniger Geld das langfristig bessere Ergebnis liefert. So, sorry fürs Geschwafel, Johann
php::bar PHP Wiki - Listenarchive