nicht angemeldet
Moin!
Ich habe da nun eine generelle Frage zur Philosophie. Es gibt in vielen Modulen ja immer die Qual, dass man sowohl Funktionalitäten für das Frontend, als auch Administrationsfunktionen für das Backend bereitstellen muss.
Wie trennt Ihr das? Gefordert ist, dass die Funktionen alle in einem Modul (einer Klasse) zusammengefasst werden, mit Ausnahme natürlich von Darstellungs-, Datenhaltungs-, oder Berechtigungsaufgaben, usw., die sich selbstverständlich in anderen Klassen befinden.
Das mit "ein Modul === eine Klasse" ist Bullshit. Wer sowas fordert, hat von OOP noch weniger Ahnung, als du. ;)
Klassen bzw. Objekte baut man ja genau deshalb, damit man die Aufgabe bestmöglich abstrahieren kann. Wenn man sämtliche Funktionen nun in genau eine Klasse integrieren muss, kann man nicht mehr gut abstrahieren, sondern muss im Prinzip prozedural programmieren - nur etwas besser abgeschottet innerhalb eben dieser Klasse.
Ich möchte nicht immer den gesamten Klotz laden lassen, obwohl doch meistens nur die Userfunktionen benötigt werden.
Autoloading hast du dir angeschaut? Unbedingt implementieren, dazu gibts auch einen PHP-Standard namens "PSR-0". Dadurch sparst du dir zum einen das andauernde require_once überall (was auch nicht so wahnsinnig performance-fördernd ist), zum anderen reduziert sich der Memory-Footprint der Applikation ohne dein Zutun schon mal signifikant, weil nur noch die tatsächlich benutzten Klassen-Deklarationen geladen werden. Und wenn man die Klassen hinreichend klein gestaltet...
Auf der anderen Seite sind Performance-Argumente irrelevant, solange ein Performance-Problem noch nicht wahrgenommen werden kann. Selbst wenn diese Modul-Klasse "groß" ist, so lagert sie eben doch insgesamt im Opcode-Cache und ist schnell verfügbar.
- Sven Rautenberg