[php] voordelen OOP

[Verwijderd]

Ik heb redelijke programmeer-ervaring in PHP, maar ik vraag mij af of ik mijn werkwijze niet beter wat kan aanpassen. Ik hoor graag jullie mening hierover.
Mijn sites zet ik eigenlijk altijd als volgt op:
- een content.inc.php die een header() en footer()-functie bevatten, waarin de HTML voor de header en footer staan
- een functies.inc.php waarin alle algemene functies staan
- evt. een specifieke_functies.inc.php waarin specifieke functies staan voor een bepaald onderdeel
- lijst met aparte scripts, bijv. nieuws.php, user.php

De gebruiker bezoekt bijv. een nieuws.php, die de functies header() en footer() aanroept om de belangrijkste HTML toe te voegen. Verder is het een mix van HTML en functies die aangeroepen worden.

Ik moet zeggen dat dit eigenlijk altijd erg prettig werkt. Nadeel is dat scripts ook delen HTML bevatten, waardoor een nieuwe vormgeving redelijk wat werk betekent.

Nu weet ik dat zaken als OOP en MVC dit makkelijker zouden moeten maken, maar ik heb daar zelf helemaal geen kaas van gegeten. Wat zou jullie advies hierin zijn? Heeft OOP bijvoorbeeld beduidend voordelen tov mijn werkwijze?

[mithras]

De modulariteit zorgt ervoor dat delen beter te onderhouden zijn. Ook is het makkelijker om DRY code te schrijven.

Met functionele code waar html, php en sql queries in verwerkt zijn is het al gauw een zooitje. De ontwikkelaar snapt het zelf soms nog wel, anderen komen er geen wijs uit. Door de gestandaardiseerde principes als OOP, MVC en dergelijke te gebruiken is het voor anderen makkelijker te begrijpen en gaat (dus) het onderhoud ook een stuk beter.

Zie verder de search trouwens, er is al heel vaak dezelfde vraag gesteld: [search=oop]

[ Voor 8% gewijzigd door mithras op 05-10-2010 14:53 ]

[TJHeuvel]

Als dit voor jou werkt moet je het gewoon laten, pas als je tegen meer restricties aanloopt pas kijken naar andere aanpakken zoals OO en MVC.

Wat je zou kunnen doen is ipv een header functie je hele header gewoon in een apart bestand plaatsen, en hetzelfde met je footer. Wat je dan krijgt is HTML met af en toe wat PHP er tussen.

[Webgnome]

met oop is het ook heel goed om rommel te maken die de eerste programmeur begrijpt en verder niemand. Een van de voordelen van oop is , dat als je het goed opzet, de diverse onderdelen goed gescheiden zijn.

Hierdoor kun je makkelijk stukken code vervangen zonder dat je in de hele applicatie van alles en nog wat moet aanpassen ( wat bijvoorbeeld als ipv html er xml uitgepoept moet worden? Nu heb je een probeem met standaard header/footer etc etc, in oop is het een object overloaden die xml uitpoept ipv html en de rest van je systeem werkt gewoon nog door.

[NMe]

Het grootste nadeel van jouw werkwijze is dat je niet eenvoudig even een nieuw template over je site heen kan gooien, want dan moet je alle PHP-code ineens gaan aanpassen. Heeft overigens niks te maken met al dan niet OOP gebruiken, dat heeft weer allerlei voordelen van zichzelf, maar die kun je natuurlijk ook gewoon zelf opzoeken: Wikipedia: Object-oriented programming. Die voordelen zijn namelijk niet taalafhankelijk.

[Verwijderd]

Als ik voor elk onderdeel een aparte specifieke_functies.inc.php maak, dan is het toch net zo overzichtelijk als met classes in OOP?
Je zet dan alle functies voor het inloggen in inlog_functies.inc.php, ipv dat je een inlog-class maakt. Dit kan uiteraard bij alle onderdelen. En in login.php en logout.php roep ik vervolgens de functies uit inlog_functies.inc.php aan.

Is dit daadwerkelijk minder overzichtelijk dan bij OOP?

[Verwijderd]

NMe schreef op dinsdag 05 oktober 2010 @ 14:56:
Het grootste nadeel van jouw werkwijze is dat je niet eenvoudig even een nieuw template over je site heen kan gooien, want dan moet je alle PHP-code ineens gaan aanpassen.

Ja, klopt. Eigenlijk zou ik het moeten combineren met werken met templates (op één of andere manier...)

[NMe]

Verwijderd schreef op dinsdag 05 oktober 2010 @ 15:00:
Als ik voor elk onderdeel een aparte specifieke_functies.inc.php maak, dan is het toch net zo overzichtelijk als met classes in OOP?
Je zet dan alle functies voor het inloggen in inlog_functies.inc.php, ipv dat je een inlog-class maakt. Dit kan uiteraard bij alle onderdelen. En in login.php en logout.php roep ik vervolgens de functies uit inlog_functies.inc.php aan.

Is dit daadwerkelijk minder overzichtelijk dan bij OOP?

Je maakt niet een "inlogclass". Je maakt een SecurityContext-class die methods heeft voor inloggen, uitloggen, checken van rechten ongeacht of je al dan niet ingelogd bent, en die bovendien een method biedt voor persistentie gedurende de sessie. Daarnaast zou je daar een parentcontext aan kunnen hangen zodat je in de securitycontext van Pietje kan werken met jouw eigen context als parent, oftewel: impersonatie.

Dit kun je allemaal ook zonder OOP wel schrijven maar dan wordt het meteen een heel stuk onoverzichtelijker en lastiger te onderhouden.

[Janoz]

Mwah, ik zou in eerste instantie nog niet beginnen met het compleet omzetten naar OOP. Ik denk dat er op de korte termijn meer winst te halen is door te beginnen met het toevoegen van lagen. Het scheiden van je presentatie logica van de rest van je code. Uiteindelijk moet er dan een duidelijke scheiding zijn tussen code die iets met je html doet en code die daar helemaal niks mee doet. Al je functies leveren dus OF data op, OF hebben data als input en transformeren dat enkel naar html.

Het stukje OOP waar je hier simultaan beperkt zou kunnen toepassen is voor je domein objecten. Gewoon de entiteiten die je in je domein hebt modeleren als een class met enkel properties (een nieuwsitem heeft een title, publicationdate, author en body). Eigenlijk is dat niet meer dan structs uit C. Ga asjeblieft niet beginnen met het heen en weer sturen van arrays (tenzij het daadwerkelijk over een lijst van newsitems gaat).

[NMe]

Janoz schreef op dinsdag 05 oktober 2010 @ 15:36:
Mwah, ik zou in eerste instantie nog niet beginnen met het compleet omzetten naar OOP. Ik denk dat er op de korte termijn meer winst te halen is door te beginnen met het toevoegen van lagen.

Uiteraard. Voor zover mijn post hierboven de indruk wekte dat je over moest stappen op OOP: dat was dus niet mijn intentie. Ik probeerde de meerwaarde van OOP boven functioneel programmeren uit te leggen. Of dat al dan niet relevant en nodig is mag je voor jezelf bepalen.

[Hydra]

Verwijderd schreef op dinsdag 05 oktober 2010 @ 15:00:
Als ik voor elk onderdeel een aparte specifieke_functies.inc.php maak, dan is het toch net zo overzichtelijk als met classes in OOP?
Je zet dan alle functies voor het inloggen in inlog_functies.inc.php, ipv dat je een inlog-class maakt. Dit kan uiteraard bij alle onderdelen. En in login.php en logout.php roep ik vervolgens de functies uit inlog_functies.inc.php aan.

Is dit daadwerkelijk minder overzichtelijk dan bij OOP?

Je hebt het over een heel specifiek voorbeeld. Het voordeel van OOP is dat je de logica die bij een object hoort ook bij dat object hebt zitten. Dus een user heeft een id, daarvoor heb je een getId() functie. Waar die ID dan daadwerkelijk vandaan komt is alleen de zorg van de user, de rest van de objecten daaromheen hoeft dat niet te weten. Doordat je die functionaliteit op die manier scheidt maak je je code overzichtelijker. Dat is niet zo'n issue bij een simpel nieuwssysteem maar gaat bij grotere projecten wel meespelen. Jij scheidt je functionaliteiten op een andere manier, OOP is als je het doorhebt gewoon een heel logische scheiding.

[YopY]

Verwijderd schreef op dinsdag 05 oktober 2010 @ 15:00:
Als ik voor elk onderdeel een aparte specifieke_functies.inc.php maak, dan is het toch net zo overzichtelijk als met classes in OOP?
Je zet dan alle functies voor het inloggen in inlog_functies.inc.php, ipv dat je een inlog-class maakt. Dit kan uiteraard bij alle onderdelen. En in login.php en logout.php roep ik vervolgens de functies uit inlog_functies.inc.php aan.

Is dit daadwerkelijk minder overzichtelijk dan bij OOP?

Dit is een veel voorkomende misconceptie bij mensen die beginnen met OO (in PHP) (mijzelf incluis), dat ze OO zien als een soort veredelde namespaces - dwz functies die bij elkaar horen in één class zetten. Echter het werkt iets anders met 'echt' oop.

Verder geen zin om dat allemaal uit te leggen, dat mogen jullie allemaal zelf doen .