twin, все таки хочется что бы вы не оперировали сущностями в коде, не важно что это действия. Вам можно использовать классы, я этого не запрещаю, да и стандартные функции, которые выдают объекты вам тоже можно использовать, так же не запрещаю русурсы использовать. Но если вы будете использовать объекты в коде, смысл вообще теряется.

class Auth
{
    static protected $someVar;
    static public function enter()
    {
          return self::$someVar;
    }
}

Ох, еще на счет сроков, хотелось бы знать временные рамки.

А также может заведем для проектов публичные репозитории? Я предпочитаю mercurial, потому бы выбрал bitbucket.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Не, ребят. Так не пойдет. Это кто сказал, что в императивном программировании нельзя пользоваться экземплярами классов? Да даже и объектами?

Это у вас рамки. Объектное программирование ориентировано на объекты. Вот и будьте добры. А я буду пользоваться всеми доступными в PHP инструментами. Императив рамок не накладывает. Если для обработки инструкции мне потребуется объект, будьте уверены, я его создам. К примеру было бы глупо писать почтовик, если есть PhpMailer. У меня шаблонизатор сделан с $this->, мне выкинуть его? Новый писать?

Я могу торжественно обещать, что всё, что можно сделать статикой, я сделаю. Даже если это не совсем удобно. И ни разу не воспользуюсь вашими плюшками типа абстракций и интерфейсов. Но полностью отказываться от конструкции new, это поддаться на ваши "слабо".

Вы мне еще паттерны запретите. Что хочу, что мне удобнее, то и буду юзать. Императивом это не запрещено.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Invis1ble

Сходил в википедию. Вот про ООП

эээ, стопэ! так о чем спор тогда? раз ОО является подмножеством, значит это тоже императив
сравниваем императив с императивом? очень интересно

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Invis1ble
Разница в том, что ООП накладывает рамки. Вот когда сделаем - сравним.

Я не знаю, какая будет у chee архитектура, но один из вариантов, если свято придерживаться парадигмы, должны быть класс "user", "category", "pages" и "comments". Ну как то так. Это сущности, и они должны между собой взаимодействовать через контекст (общую часть программы). Там не знаю как, это уже не важно. К примеру контроллер (или лучше модель) должны создать объект, который заточен на решение своих узких задач, а он уже должен сам как то отреагировать. Передать/запросить данные у другой сущности, либо вернуть в контекст результат. Впрочем это зависит от архитектуры.

У меня будет примерно так. Классы "select", "add", "auth". Причем по заявкам телезрителей сделаю их статическими. Между собой они взаимодействовать никак не будут. Если мне нужен список категорий, я в классе "select" сделаю запрос на выборку нужной таблицы и в контексте обработаю результат. Ну во вьюшке в моем случае. Если понадобится узнать роль конкретного юзера, я дам команду классу "auth" её узнать. Не в сущности "юзер", а там, где хранятся эти роли. На основании данных, которые я в эту инструкцию передам.

Вот в чем сакраментальная разница.

Я могу делать инструкции процедурными, статичискими или объектными. Мое дело. Главное, что программа должна опираться только на данные и на основании их принимать решение о действиях. Без создания взамодействующих объектов, как сущностей.

Кроме того, к вопросу о наследовании. Тоже философия. В ООП объект наследуется для того, чтобы научить потомка тому, что не умел родитель.

У меня классы по сути не наследуются. А расширяются. В них добавляются недостающие инструкции. Не может унаследоваться навык рисования, если не родить ребенка. Я могу допустим сам научиться еще и играть на скрипке. Но это в пределах моего эго, это не то, что у меня родился сын, который умеет все что я, но еще и играть в хоккей.

К примеру тот же шаблонизатор. Можно конечно просто обратиться к классу и обработать результат в контексте. Но интереснее его расширить. И работать в этом локальном участке. Это больше похоже на обычный include

Впрочем давайте не торопить события. Сравним и увидим разницу.




_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Да, спор каким то неинтересным получается)
Все сведется к тому, что один напишет

class User {
    public function auth() {

   }
}

А другой, что-то наподоби

class Auth {
    public function registration(user) {

   }
}

Вроде не про это спор был. Просто разные подходы к построению самой архитектуры , рассходу памяти и тд.

SoMeOnE

Все сведется к тому, что один напишет 

Один сделает классы, другой сделает такие же классы, только наследованные от интерфейса :D

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

class User {
    public function auth() {

   }
}

class Auth {
    public function registration(user) {

   }
}