Moin!
Ich muss versuchen, die Neuerungen so gut es geht nach MVC-Pattern zu bauen, ohne dass es ausartet. Und die neuen Klassen müssen äußerst unkompliziert dann später durch Andere verwendbar sein.
Nein, das ist keine gute Taktik.
Entweder baust du das neue Modul nach modernen Erkenntnissen eigenständig neu "daneben" und fügst es über geeignete Ähnlichkeit in den URLs nach außen hin nahtlos ein. Dann wäre es allerdings Wahnsinn, dafür KEIN existierendes Framework zu nehmen.
Alternativ baust du mit möglichst minimalem Aufwand ein Modul zum existierenden Code dazu - dann aber solltest du dich bestmöglich an die existierenden Paradigmen des existierenden Codes halten, damit derjenige, der dann irgendwann mal das Update des Gesamtsystems machen will, nur genau EINE alte Methodik zu analysieren und neu umzusetzen hat, anstelle dass er pro Modul, wohlmöglich pro aufrufbarer URL, jeweils die individuelle Denkweise des jeweiligen Programmierers nachvollziehen muss.
Es kann natürlich sein, dass auch das existierende System sich schon durch maximale Heterogenität auszeichnet. In diesem Fall wär's vermutlich egal.
"Autoload" war da schon das richtige Stichwort. Ich muss jetzt nur möglichst sinnvoll entscheiden, wann tatsächlich Vererbung und wann nur Nutzung von anderen Klassen richtig ist.
Mit Pech hast du kein Autoload, auf dem du aufsetzen kannst. Und Hände weg von __autoload(), korrekt nutzt mal spl_autoload_register() - nur falls existierender Code das schon falsch macht, kommt es gern zu unschönen Konflikten, die man erst lösen muss.
- Sven Rautenberg