phpbar.de logo

Mailinglisten-Archive

[php] php5 - OOP

[php] php5 - OOP

Johann-Peter Hartmann php_(at)_phpcenter.de
Tue, 30 Jul 2002 11:50:33 +0200


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