современная трактовка ООП это те же процедуры обернутые в классы
Имхо, вы тут где-то пропустили слово "мудаками", и зря по этому поводу волнуетесь.
Вам чем-то мешают дилетанты? Они же делают благородное дело - создают мусорный фон, на котором так удобно выглядеть "весь в белом".
Антон Р., "какие-то" данные или конкретные данные?
Юзер может выдавать вам строки Имя и Телефон, может - массив, в котором есть поля Name и Phone, может - объект с такими полями, может - обобщенный объект Контакты, у которого неизвестные вызывающему данные скрыты за методом Вывести, а он уже сам знает, как именно...
Юзер может даже принимать объект вывода и отдавать ему свои данные с нужным форматированием самостоятельно.
Вариантов-то много.
Главное - чтобы при следующем изменении вы с первого взгляда вспомнили логику взаимодействия классов и не были вынуждены бегать по всему коду, исправляя ее.
Антон Р., знание, что у Юзера есть Имя и Телефон, уже может быть излишним. Зависит от прочей логики, конечно.
Ну, и однажды вам может понадобиться Юзер, у которого, кроме того, есть сайт, который нужно вывести, потому что на самом деле это организация, а код уже предполагает юзера...
В общем, ООП заходит не тогда, когда мучительно переписываешь процедуры в классы. А когда приходится поддерживать и развивать то и другое.
люди ведутся на моду, видят в этом серебрянную полю
ООП - это, конечно, не серебряная пуля. Но это неплохие вилы для разгребания того навоза, который получается без их использования в том же пыхе, например.
То, что особо одаренные пытаются использовать вилы вместо лопаты и грабель, ничуть не портит сам инструмент.
Антон Р., лучше "Объявление - вызывает Автора - запрашивает у него контактные данные".
Так вместо конкретного Юзера (физ. лица) объявление сможет подать и агентство, и администрация, и фейковый тестовый объект, проверяющий работу этого механизма. Старайтесь, чтобы одни классы ничего не знали о других сверх необходимости.
Дмитрий, между прочим, логика данных и архитектура имеют много общего. Представьте себе, что каждое свойство класса - это столбец в таблице БД с данными его экземпляров. Поле $role все еще кажется хорошей идеей? А JSON-поле для представления массива?
Антон Р., да не хулится ваше доброе! Продолжайте в том же духе, не обращая внимания на старперов, посмеивающихся над нубской нелепостью. И это пройдет ;)
Антон Р., я не про логику системы. Заборов-то вы можете понаставить. Речь про логику программиста, который с этим кодом работает. Для него пользователь - это данные. Не суперкласс, который в одно лицо умеет пол-админки, а данные.
Антон Р., в том плане, что если у вас Юзер умеет сам организовывать свою регистрацию, то вы можете сделать это в любом месте, где используете этот класс. Это правда то, что вам нужно?
Хотя бы представьте, что каждый раз, когда вы в IDE вызываете автодополнение по методам класса, вам первым делом лезет под руку этот самый метод регистрации. По-прежнему нужный только в одном-единственном месте сайта.
Антон Р., дополню одним практическим нюансом для лучшего понимания.
Вы же будете много где использовать этот самый класс Юзер. На хрена по всем этим дорогам таскать за ним регистрацию, которая нужна строго в одном месте сайта?
partisan42, "теперь" - это после перезагрузки или после изменения прав по этой инструкции?
В любом случае, это же Линукс. Загрузитесь в режиме восстановления или с внешнего носителя и разберитесь с правами на файлы.
WSGR, почитайте внимательнее описание этих уязвимостей - и последнее предложение в моем ответе.
Кстати, если вдруг найдете информацию об уязвимости, позволяющей кому бы то ни было при каких бы то ни было условиях вскрыть мой tc-контейнер с флешки, которая всегда у меня в кармане - буду очень благодарен за эту информацию. Пока что я не знаю ни одного способа сделать это, кроме ректального криптоанализа.
anikavoi, дело в том, что вы пытаетесь установить пакет, собранный не под ту систему, на которую вы его ставите. Отсюда и проблемы с зависимостями. Так что, если вам действительно без него никак - проще взять исходники и собрать, чем шаманить с зависимостями и, возможно, поломать их у других пакетов.
И если вы собираетесь всерьез заниматься администрированием - стоит понимать, что на каждом следующем сервере никаких фаров из коробки не будет...
