?> эту хрень не нужно в конце использовать. От неё одни проблемы. Это кстати рекомендация в основных стилях.

Скобку ИМХО удобнее открывать под методом. Остальные дело вкуса но именно эти рекомендуется писать в стиле Алемена.

    public function __construct($param, $var)
    {
        if (isset($var)){
            return echo "Class sozdan";
        }			
    }

Конструктор кстати ничего вернуть не может, тем более echo ничего не возвращает, это конструкция. А посему пример некорректен для учебника. :)

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

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

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

Оцените регистрацию, в том числе, безопастность: http://razzwan.tk/
reg_code = 111, 222, 333 ... и т.д.

_____________
Youtube канал WebDeveloper->Run()
Сайт для души
Gitter

if (isset($var)){

Аутентифицировался чтобы сказать. Есть PSR, используйте их как свой code-style. Объяснять смысла нет, читайте сайт, смотрите участников.

Врядли ты знаешь ооп, скорее только синтаксис. Я объясню в кратце. Наследование это плохо. Article наследуется от DB_Connect. Это жесткое связывание. Будут проблемы с мигрованием из mysql на другую субд. Нужно будет править все файлы, которые наследуются от DB_Connect. Здесь нужно использовать Dependency Injection. В Article нужно передавать объект класса Db_Connect, сам Db_Connect должен реализовывать интерфейс, тогда для описанного интерфейса можно будет написать любой Db_Connect под любую базу данных и быстро переключить проект с одной бд на другую.

Еще пример, сессии. Многие в коде пишут session_start() или $_SESSION['data']. Будут проблемы. Бекенд не всегда обслуживается одним сервером, а в этом случае аутентификация будет слетать, так как каждый запрос пользователя может быть обслужен разными серверами и каждый из них ничего не знает о php-сессиях другого сервера, только о своих собственных. Поэтому нужно использовать другое хранилище, например redis, но так как в коде везде явно писалось $_SESSION['data'], то опять придется править все зависимые файлы. Решается тоже через dependency injection. Нужно два класса, для работы с php-сессиями и для работы через redis, которые реализуют единый интерфейс, во все классы которые работают с сессиями нужно внедрять один из экземпляров этих классов. Тогда всё будет переключаться 1 строкой в конфиге.

Ладно, пора закруглятся, всё равно врядли что-то будет понятно и невозможно объяснить коротко и ясно в рамках форумного поста. Я лишь хотел сказать, что знание синтаксиса ООП, это вовсе не знание самого ООП. Многие паттерны, в том числе и Dependency Injection появились, чтобы решать различные повседневные задачи, но twin тебе написал, что паттерны это "быть как все" не слушай вообще таких людей, паттерны помогают не писать говнокод. Паттерны используют, потому что это быстрый способ решить конкретную проблему. ООП без паттернов - это не ООП, а говно.

Спасибо.

Ух ты!
Santehnick

посмотри PSR стандарты) это ответит на все вопросы и без велосипедов

Santehnick
Я имел ввиду этот топик) Здесь я такого не советовал. Потому что тут не было повода. ТС нигде не написал, что будет разрабатываться фреймворк. Даже наоборот, он указал, что будет разрабатываться конкретный проект.

Все, что вы с таким пылом описали, годно только для фреймворка. Ибо никто и никогда в трезвом уме и при памяти не меняет СУБД у действующего приложения. Такое можно представить только в страшном сне.

Другое дело, если планируется универсальное приложение. Последнее время повальное увлечение фреймворками привело к тому, что многие (это я и имел ввиду, когда писал про всех) стали во главу угла ставить именно универсальность, а это обратно пропорционально производительности и прозрачности кода.

Универсальность нужна тогда, когда нужен вал. Когда приложения пекутся как пирожки на конвеере. Тогда да, паттерны позволяют добиться глубочайшего уровня абстракции. Соответственно скорости разработки. Только для чего она нужна в штучном проекте?

С той же базой. Есть в репозитории несколько легких классов для работы с конкретными СУБД, на кой писать универсального монстра, если те же модели все равно пишутся под конкретику? Не будут запросы для Postgre работать в SQLite и так далее. Значит при переходе с одной СУБД на другую мало универсального класса. Либо нужно кастрировать модели, оставив только то, что работает на пересечении. Это ахилесова пята всяческих ORM. Либо изменять их, что сводит на нет все усилия по "унификации".

С той же стратегией. А кто сказал, что нужно "допиливать код"? Вы просто не знаете, как можно сделать иначе, так как мыслите только шаблонами. Мне никто не запретит так же написать статические классы под каждую сеть, которые будут выдавать определенный набор данных и соединить их где то в одном месте. Можете это назвать стратегией, дело хозяйское, однако такой подход не вписывается в вашу доктрину.

А все, что не вписывается, вы тут же объявляете говнокодом. Еще раз говорю, таких холиваров полно. И толку от них нет, так как дальше теоретических выкладок обычно дело не заходит. Вот сейчас появилась возможность сравнить на практике, ждем.

Вы всегда говорите - шаблоны, это бэст практикс, потому что так делают все. Только не всегда это оправдано. В данном случае я считаю - нет. Не оправдано. Учиться программировать и учиться шаблонно мыслить - совершенно разные, если даже не полярные вещи.

Вот если бы тема называлась как-нибудь "Пилим свой фреймворк", я бы смиренно молчал.

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

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

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

Бла бла бла, твин опять одна вода и твое устарелое имхо

кому нужен будет программист с велосипедами который не может уже устоявшиеся практики использовать, да никому 99% проблем решено уже, а остальной 1 появляется очень редко

Знаешь смена БД вполне возможна даже в крупных компаниях, вон газпром на одной из дочек решил отказаться от Oracle в пользу постгреса, из-за возможных экономических проблем в виде санкций и тд

Инструментом пользуются пока он выполняет свои задачи, а когда не может выполнить его меняют, БД такой же инструмент, сегодня MySQL потом миграция на постгрес или оракл или кассандру или какойнибудь ОРМ, при правильном проектировании и если надеются на будущее у проекта тогда делают нормально, а не придумывают велосипед от которого потом будут вешаться сами же, ты тут миллион раз не прав, и ниодного довода ты не приведешь к тому что архитектуру делать нужно не верно

Я в который раз говорю - нет смысла воевать с мельницами. Я не Дон Кихот.

Я предложил практическое сравнение (вернее даже не я, я с энтузиазмом поддержал), вот там можно ломать копья. Мой образец готов два месяца назад, оппонентов ждем. А пока бла бла только с вашей стороны.

Вот ты уходишь от темы, да это тоже программист и то что ты назвал сборщиком

Ни в коем разе. Программист пишет программы, те, которые ты обозначил как