1. В Symfony есть существует «класс для пользователей», только он не класс, а интерфейс: «Symfony\Component\Security\Core\User\UserInterface» (собственно класс тоже есть, но он не для того).
2. Грешно писать интерфейсы привязанные к реализации, тем более привязанные к «хранящей прослойке»:
«Likeable» должен содержать человеческие названия методов, например «like(Like)», «unlike(Like)», «getLikes()», а уж как конкретно хранить и привязывать эти лайки лучше оставить на совесть пользователя.
3. «Как хранить, где, почему, как привязывать, куда, зачем и т.д.» — об этом думать должен пользователь, ваша задача предоставить адекватный интерфейс взаимодействия. Взгляните на досуге на реализацию «FOSUserBundle», он не требует специфичного хранилища, ему глубоко без разницы как вы будете хранить пользователей, будь то реляционная БД, ОО БД или просто файл. Сделайте таким же образом «Model\StorageAgnostic\Like» и наследуйте конкретные привязки!
Почему бы не сделать класс TableView с конструктором от данных поумолчанию и набор методов для манипуляций над деревом, в числе которых и разнообразные настройки отображения?
лучше использовать константу STDIN;
обязательно заменить "#!/usr/local/bin/php" на "#!/usr/bin/env php" (у большинства, ИМХО, php лежит в "/usr/bin", а у некоторых даже в "/opt".
swiftmailer умеет собирать абсолютно все данные о сообщении (в том числе содержание, тему, всех получателей, заголовки, форматирование), а вы можете их сохранить в любом удобном для вас формате.
Уж простите за глупый вопрос, но: А почему бы просто сразу не использовать swiftmailer? Он, помимо прочего, умеет в dummymailer со всеми вытекающими возможностями для тестирования и отлова сообщений.
Таким подходом нарушается принцип единственной обязанности. Помимо этого получаются очень грустные зависимости, например, «пользователь» зависит от базы данных. А что ещё хуже объект уже зависим от некоторого абстрактного хранилища («жадность» налицо), а ведь значительно лучше когда объект зависит только от того, что он использует, а за сохранение\загрузку\удаление из абстрактного хранилища отвечает само это хранилище.
Про чистый РНР не знаю, но для symfony2 (ИМХО идеальный framework для тех, кто пришёл с java или собирается на неё уходить) есть вот эта замечательная вещь — github.com/hwi/HWIOAuthBundle.
Про DI: далеко не во всех реализациях под РНР есть понятие «scope», без которого в таком режиме оно просто не будет адекватно работать, например, абсолютно любой сервис зависящий от «request» должен пересоздаваться при новых запросах, но это поведение не реализовано практически ни в одном из популярных DI-framwork-ов.
Даже в тяжеловесном symfony di-container нет этого функционала из коробки, да там есть «scope», но совсем не для этого.
Тем не менее, прирост такого рода статей за последнее время не может не радовать.
Идея внедрения через конструктор не должна портить производительность, разве что на этапе загрузки скрипта, на этапе инстанциации и использования проблем возникать не должно + этот код специально был написан так, чтобы минимизировать кол-во «специального» синтаксиса и позволяет проводить внедрение только тогда, когда это действительно нужно и не влияет на уже созданные классы и не принуждает проводить внедрение для наследования, если такое потребуется.
2. Грешно писать интерфейсы привязанные к реализации, тем более привязанные к «хранящей прослойке»:
«Likeable» должен содержать человеческие названия методов, например «like(Like)», «unlike(Like)», «getLikes()», а уж как конкретно хранить и привязывать эти лайки лучше оставить на совесть пользователя.
3. «Как хранить, где, почему, как привязывать, куда, зачем и т.д.» — об этом думать должен пользователь, ваша задача предоставить адекватный интерфейс взаимодействия. Взгляните на досуге на реализацию «FOSUserBundle», он не требует специфичного хранилища, ему глубоко без разницы как вы будете хранить пользователей, будь то реляционная БД, ОО БД или просто файл. Сделайте таким же образом «Model\StorageAgnostic\Like» и наследуйте конкретные привязки!
Почему бы не сделать класс TableView с конструктором от данных поумолчанию и набор методов для манипуляций над деревом, в числе которых и разнообразные настройки отображения?
Если уж хочется абстракций, то уж лучше так: gist.github.com/saksmt/68c39037ccabadbbd987
лучше использовать константу STDIN;
обязательно заменить "#!/usr/local/bin/php" на "#!/usr/bin/env php" (у большинства, ИМХО, php лежит в "/usr/bin", а у некоторых даже в "/opt".
Даже в тяжеловесном symfony di-container нет этого функционала из коробки, да там есть «scope», но совсем не для этого.
Тем не менее, прирост такого рода статей за последнее время не может не радовать.