[Erledigt] Php4 vs php5

Hi,

habe zuvor auch mal die Suche benutzt, aber nicht wirklich was passendes gefunden.
Ich bin primär auf der Suche nach Contra Argumenten für den Einsatz von PHP5

Beziehungsweise die Mühen eines Umstieges und Anpassung einer stehenden Applikation auf Objektorientierung.

Reine Feature-Listen zu PHP5 findet man ja reichlich
z.b.
http://www.devshed.com/c/a/PHP/Whats-New-in-PHP-5/ ff.

Aber das hilft mir nicht wirklich. Ich brauch eine gut begründete und nachvollziehbare Argumentation die gegen den Umstieg bzw. den kompletten Rework hin zu OO-P steht.

Jmd hilfreiche Links o.ä ?
Oder direkte Argumente ?


EDIT:
--
ein reiner OOP-ansatz ist ja auch ohne PHP5 machbar wie ich grad sehe:
http://www.phppatterns.com/docs/desi..._pattern?s=mvc
aber...siehe oben

Gruss
fidel_

Hi,

Ich brauch eine gut begründete und nachvollziehbare Argumentation die gegen den Umstieg bzw. den kompletten Rework hin zu OO-P steht.

Das sind aber 2 verschiedene paar Schuhe!

Gegen den Umstieg spricht meiner Ansicht nach überhaupt nichts. Wenn Dein Code vorher halbwegs sauber war, wirds wohl außer einigen kleinen Mickerfehlern keinen Ärger geben. Dazu kannst Du die Vorteile von PHP5 nutzen. Hab jetzt keine UnitTests gemacht, aber die Zend-Engine soll ja schneller sein.

Zum OOP:
Du kannst auch in PHP5 Deinen Spaghetticode beibehalten.
Gegen einen Umstieg spricht eigentlich nur:
Du könntest etwas neues lernen
Dein Code könnte übersichtlicher werden
Dein neuer Code könnte Objekte besser abbilden als Deine Funktionsbibliothek und wartbarer werden.

Also steig bloß nicht um! :wink:
Ok, Klassenstrukturen sind minimal langsamer als linearer Code. Das wird aber durch die obigen "Nachteile" locker wett gemacht!

Gruß
MarkusHausB

[Waq]

Wenn man so fragt, lohnt es sich wohl nicht.

Denn wenn man so fragt, hat man keine Ahnung von OOP.
Wenn man keine Ahnung von OOP hat, ist die Anpassung auf OOP vor vornherein zum Scheitern verurteilt.
Mit OOP muss man klein Anfangen, also kleine Umstellungen machen, neue Sachen in OOP machen, ne grossangelegte OOP-Umstellung als Einstiegsprojekt ist Unsinn.

mir sind die Vorteile von OOP schon bewusst
(teilweise will ja nicht allwissend rüberkommen, was ich nicht bin)

ABER:
- ich habe eine quasi fertige applikation (php4 & non-oop),
- einen eingeschränkten Zeitrahmen für das Projekt

und daher seh ich den Mehrwert aktuell nicht.
daher ergibt sich auch obige Fragestellung / Formulierung

ich hoffe jetzt wird es klarer.


mfg
fidel_

Hi,

Wenn die Applikation fertig ist, und ich mal nicht annehme, daß der Kunde die Portierung bezahlen würde, dann teste Sie wenigstens in der aktuellen Form unter PHP5. Ich nehme an, es wird dort performanter laufen.

Gruß
MarkusHausB

ok, ich habe mich wohl ersthaft falsch ausgedrückt.

es geht hier weniger um den Umstieg von:
--> php4.x auf php5

sondern vielmehr um den Umsteig von:
--> Spaghetticode auf OO-Sytle

den ich Argumentativ im Bezug auf Zeit & Aufwand erschlagen will

[robo47]

Tja der umstieg auf "OO-Style" kann dir unter umständen den Vorteil bringen, dass du Teile von dem ganzen Projekt auch beim nächsten Kunden einfach einsetzen kannst und du nicht immer alles doppelt und 3fach codest.

mfg
robo47

[Basti]

Hallo.

Ich denke, es ist schwer, da eine Aussage zu treffen, wenn man das Projekt nicht kennt. Prinzipiell ist es nicht tragbar, kurz vor Projektabschluß den Entwurf nochal komplett umzuschmeißen, es sei denn, du stößt an die Grenzen des bisherigen Entwurfes. Letztlich ist es doch gegen Ende eines jeden Projektes, mit dem man selbst Neuland betritt, so, dass man eben erst dann sieht, wie man hätte anfangen müssen, oder nicht?

Deshalb ist es wahrscheinlich angebracht, das Ding jetzt zu Ende zu bringen und in der nächsten Ausgabe an ein Refactoring zu denken. Vielleicht macht es auch Sinn, nur ein paar Schnittstellen jetzt schonmal umzubauen - das hängt eben ganz vom Projekt ab. Ist es darauf ausgelegt, eine solide Basis für eine Anwendung zu sein, die in den nächsten Jahren kontinuierlich erweitert werden soll, dann würde ich mir schon überlegen, alles nochmal umzuschmeißen. Geht es aber um eine Anwendung, die erstmal ein paar Monate ohne größere Veränderungen laufen soll und dann vielleicht in 1, 2 Jahren nochmal in einem größeren Schritt um zahlreiche Features erweitert werden soll etc., dann würde ich den Umbau auf dorthin verschieben und jetzt erstal die eine Sache zu Ende bringen. Bis dahin habt ihr auch genug Komponenten gesammelt oder ein euch zusagendes Framework gefunden/entwickelt, dass der Umbau dann viel schneller von statten geht.

Etwas anderes ist es natürlich eben, wenn schon jetzt keiner mehr durchsteigt und jede Fehlerbehebung oder Änderung der Anforderungen unnötig viel Zeit oder gar größere Umstrukturierungen in Anspruch nimmt.

Basti

hello,

also meiner meinung nach sollte man auf jeden fall php5 verwenden (vollkommen egal ob oop oder nicht).

zitat php.net (http://www.php.net/manual/en/migration5.php): " PHP 5 and the integrated Zend Engine 2 have greatly improved PHP's performance and capabilities!"

php5 ist so gut wie 100% abwärts kompatibel und ich hab noch nie auch nur geringste probleme gehabt oder irgendetwas umschreiben müssen. hier eine komplette liste der änderungen (nur 13 minimale functions änderungen und so): http://www.php.net/manual/en/migrati...compatible.php

dadruch hat man die möglichkeit nachher oop zu programieren wenn man will... oder einfach teilweiße ...

mfg

[Basti]

es geht hier weniger um den Umstieg von:
--> php4.x auf php5

sondern vielmehr um den Umsteig von:
--> Spaghetticode auf OO-Sytle

[imported_Ben]

Ich denke, es ist schwer, da eine Aussage zu treffen, wenn man das Projekt nicht kennt. Prinzipiell ist es nicht tragbar, kurz vor Projektabschluß den Entwurf nochal komplett umzuschmeißen, es sei denn, du stößt an die Grenzen des bisherigen Entwurfes. Letztlich ist es doch gegen Ende eines jeden Projektes, mit dem man selbst Neuland betritt, so, dass man eben erst dann sieht, wie man hätte anfangen müssen, oder nicht?

Deshalb ist es wahrscheinlich angebracht, das Ding jetzt zu Ende zu bringen und in der nächsten Ausgabe an ein Refactoring zu denken.

Uneingeschränkte Zustimmung.