[PHP] - Conditioneel een class "extended"

[gvanh]

Kernvraag: is het mogelijk om een class alleen te extenden als voldaan is aan bepaalde voorwaarde?

Mijn CMS bestaat uit modules. Iedere module is een class die een basale class "extend":

PHP:

Class Module extends Module_Common {
}

Nu is het zo dat Module_Common een hele grote class is. Dat maakt het enerzijds moeilijk om hem te onderhouden, anderzijds zorgt hij vermoedelijk voor flink wat overhead. De functies in Module_Common kunnen grofweg worden ingedeeld in:

1. algemene (database) functies die altijd nodig zijn (zowel in de CMS omgeving als in de website zelf)
2. functies die alleen nodig zijn in de CMS-backend

Ik zou dus graag de Module_Common verdelen in Module_DB en Module_CMS, waarbij Module_DB alleen Module_CMS extend op het moment dat de CMS omgeving actief is en niet wanneer de website-omgeving actief is.

Wat ik zou kunnen doen is twee versies van Module_CMS maken, waarbij de ene versie de gevulde class is en de andere versie een lege class met alleen de class-naam. De ene versie laad ik dan wanneer de CMS-omgeving actief is en de andere wanneer de website actief is.

Ik zou het alleen een mooiere oplossing vinden (en het scheelt weer een include) als ik de "extension" kan laten afhangen van een bepaalde voorwaarde.

Of heb ik hier wellicht sowieso een hele kromme benadering van de werkelijkheid?

[SchizoDuckie]

De grootste vraag is volgens mij of je wel je 'backend code' en je frontend code door elkaar heen wil laten draaien.

Alleen al om te voorkomen dat er überhaupt mee geklooid *kan* gaan worden staat dat bij mij allemaal los van elkaar en sharen ze helemaal *niets*

Wat je gewoon zou kunnen doen is op het moment dat jij in je backend zit een andere versie van je module_common class inladen ?

[ Voor 19% gewijzigd door SchizoDuckie op 08-02-2008 10:41 ]

[orf]

Inderdaad, waarom extenden als je ook gewoon een object in je class kunt aanroepen.
Een CMS class moet je niet een DB class laten extenden; die DB class kun je waarschijnlijk veel beter gebruiken als singleton binnen je CMS class.

[gvanh]

Dat heb ik ook bedacht. Maar feit is dat veel functies toch echt voor beide omgevingen gebruikt worden. Het gaat dan voornamelijk om database functies, zoals een "getFamily()" functie die een subtree van objecten uit de database haalt. Door het systeem van rechten die in alle functies afgedwongen worden, wordt er sowieso nooit iets uitgevoerd dat niet mag. Juist door het "stapelen" van functies komen alle database acties uiteindelijk uit bij een klein aantal heel basale functies, waar nog een keer extra op rechten wordt gecontroleerd. Daar maak ik me dus geen zorgen om.

Als ik twee versies van de Common class zou gaan onderhouden, dan moet ik alle wijzigingen die ik in de één maak ook doorvoeren in de ander (als het om een gedeelde functie gaat). Ik kan op m'n vingers natellen dat ik dát een keer ga vergeten.

die DB class kun je waarschijnlijk veel beter gebruiken als singleton binnen je CMS class

Nee, dat gaat niet werken. De functies in de DB-class zijn namelijk afhankelijk van de context van de module waarin ze worden gebruikt. Alle modules an sich worden overigens gebruikt als singletons.

[ Voor 16% gewijzigd door gvanh op 08-02-2008 10:53 ]

[SchizoDuckie]

Het klinkt mij nu al alsof je een paar verkeerde keuzes gemaakt hebt al heel vroeg in het project waardoor je nu met allerlei koppelingen zit die je niet wil.

Wat nou als ineens blijkt dat je een gigantisch lek op de een of andere manier in je frontend hebt zitten waardoor iemand die hele backend code aanzwengelt? Ik zou je echt *ten sterkste* adviseren om die netjes te scheiden ookal kost dat misschien wat werk. Geeft je gelijk een mogelijkheid om nog eens na te denken over hoe je dit simpel kunt opzetten Je kunt bijv. alleen je data model sharen tussen die 2 applicaties, of het zo maken dat zelfs de backend op een compleet andere machine of domeinnaam kan draaien (wat bij mij überhaupt altijd al zo is, en das prettig )

[Johnny]

Zoals ik het nu begrijp gebruik je de class Module nu voor zowel je front-end als je back-end, wat de scheiding er tussen natuurlijk moeilijk maakt. Je zou natuurlijk de code kunnen uitlezen en dan vervolgens klassen toevoegen die moeten worden ge-extend. In PHP 5 kun je namelijk gebruik maken van multiple inheritance waarbij je meer dan 1 klasse kan extenden.

Vervolgens kun je de aangepaste code uitvoeren doormiddel van de functie eval(). Het gebruik hiervan is in de meeste gevallen niet aan te raden en duidt meestal op een slecht ontwerp.

Ik denk dat je het gewoon het beste kan laten zoals het nu is. Je argumentatie om het te veranderen is namelijk niet erg onderbouwd:

zorgt hij vermoedelijk voor flink wat overhead

Het lijkt vaak alsof veel code zorgt voor veel overhead, maar in de praktijk is dat bijna nooit het geval. Als je echt problemen met de performance ervaart kun je beter eens kijken naar de queries in je database en andere stukken code gaan 'profilen' om er achter te komen waar de bottleneck zit.

[gvanh]

Het klinkt mij nu al alsof je een paar verkeerde keuzes gemaakt hebt al heel vroeg in het project waardoor je nu met allerlei koppelingen zit die je niet wil.

Ik had bij het starten van dit topic al zo'n vermoeden dat er zo'n conclusie zou worden getrokken. Ik gebruik de huidige opzet al zo'n 4 jaar op veel uiteenlopende projecten en het is alleen maar erg flexibel en robuust gebleken. Dat jij andere prioriteiten voor jouw systeem hebt gelegd snap ik heel goed.

Het lijkt vaak alsof veel code zorgt voor veel overhead, maar in de praktijk is dat bijna nooit het geval. Als je echt problemen met de performance ervaart kun je beter eens kijken naar de queries in je database en andere stukken code gaan 'profilen' om er achter te komen waar de bottleneck zit.

Zie hierover ook dit topic.

Ik ben juist erg aan het profilen geslagen, en daaruit komt naar voren dat een groot deel van de executie-tijd per pagina nu gaat zitten in het "includen" van de benodigde bestanden. Bij hoge belasting levert dat blijkbaar een bottleneck op. Door selectiever te zijn met includen en onderdelen alleen te laden wanneer ze werkelijk nodig zijn, heb ik al een hoop winst geboekt. Ook door een lichtere versie van mijn database-abstractie library te gebruiken een hoop winst.

Nu wil ik dus kijken of ik op deze manier nog wat winst kan pakken. De Module_Common is op dit moment ongeveer 103KB en met het strippen van de CMS-specifieke functies kan ik dat ongeveer tot de helft terugbrengen. Dat scheelt bovendien waarschijnlijk een hoop geheugen bij het laden van de functies.

[ Voor 17% gewijzigd door gvanh op 08-02-2008 11:34 ]