Практически у каждого класса в блоголёте есть метод Install и симметричный ему Uninstall - они вызываются при установки блоголёта. Uninstall практически никогда не вызывается - правила хорошего тона требуют обязательного наличия этого метода. Эти методы актуальны для плагинов - при установки и деинсталляции плагина. Методы вызываются всего один раз, все остальное лежат мертвым грузом в исходнике. Я когда то думал вынести Install/Uninstall в отдельные файлы - то ли класс, то ли еще как, но отказался от этого потому, что так легче следить и редактировать класс - если вносишь изменение в класс, то тут же в случае чего можно поправить и эти методы. Иначе бы пришлось лезть и искать соответствующую инсталляцию в другом файле, возникает ошибка разногласия в разных версиях классов - ну это если все классы собрать вместе в одном файле.

Сегодня я ощутил, что необходимо внести новый метод - проверка (валидация) целостности данных, и симметричный ему метод исправления данных, в случае их повреждения. Скорее всего просто один метод с параметром - исправлять ли ошибки. Например для постов это будет пройтись по списку постов и проверить существование файлов для каждого поста, потом загрузить пост и вызвать проверку целостности поста, который бы сам себя проверил.

Сейчас возникла следующая идея: для каждого класса (практически каждый класс находится в своем собственном файле) создавать файл сателлит, например перед.php ставить ..service или .install - для постов это будет например postclass.install.php В файле-спутнике будут находится три метода - Install/Uninstall/Validate а сами методы будет вызвать например базовый класс TDataClass в методе __call. Чтобы не порождать слишком много лишних случаев можно сделать модель двоякой - по старому можно внутри самого класса реализовывать эти методы, так и во внешнем файле-спутнике.

Для файла-спутника тоже надо придумать механизм включения методов, так как просто объявить function Install нельзя, так как будет ошибка- такая функция уже существует. Либо можно придумать трюк - слить имена класса и метода, например - TPostsInstall.

Про валидацию данных я думал еще в самом начале разработки блоголёта, но не стал реализовывать из за громоздкости самих методов валидации, так еще потому, что структура данных еще не была зафиксирована. Валидацию данных и их исправление буду однозначно делать.

Можно, конечно, положить файлы-спутники рядом с классом, но из за этого количество файлов будет просто удвоено, тем самым замусорив папку мало значащими файлами. Есть идея добавить новую папку install в которой будут находится файлы спутники. Еще возникает проблема выбора - если в классе уже есть метод Install и есть такой же метод в файле спутнике, то что делать? Думаю что однозначный приоритет за Install внутри класса, который в свою очередь, если надо, может вызвать цепочку предков parent::Install а уже если цепочка вызовов дойдя до базового класса TdataClass, то он может загрузить методы из файла-спутника.

Архитектура практически спланирована, осталось мне только вспомнить, либо пошуршать докой, как происходит внедрение (добавление) методов без создание нового класса, а что называется на лету, чтобы внутри функций из файлов-спутников можно было пользоваться переменой $this вызвать parent:: и так далее. Вот такой интересный сюжет получается у блоголёта.