Из рабочего проекта ничего показать не могу - заругают. Но что бы представление имели, покажу из школы модуль консультации.

Модуль или модель, кому как нравится. Важно, что этот класс самодостаточен и может использоваться сколь угодно много раз. У меня вызывается в 4 местах. Техподдержка, консультация и то же самое в админ-панели. Кроме того, если заменить обертки прототипами или добавить пару файлов (с теми же обертками, языковой и пару шаблонов) можно влепить куда угодно или вообще поставить отдельно. Чего нельзя сделать ни с одной вашей моделью. К вопросу о многоразовом использовании.

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

И не говорите мне, что там говнокод и невозможно разобраться. Если уж в этом разобраться трудно, мне будет нечего добавить.

Если вы считаете, что сие легко повторить на фреймворке, было бы прилюбопытно.

В действии просто так к сожалению посмотреть негде, только из программы школы. Но я могу и отдельно поставить, время только нужно.

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

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

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

Бедный дизайнер который будет копаться в классе : (
Мой напарник по работе дизайнер послал бы меня на 3 веселых буквы, если бы я ему сказал лезть в класс, чтобы подправить Вид.

Хотелось бы услышать пояснения на эти вопросы:.

if($GET['mod'] === 'edit' && $GET['id'] === $row['id'])

А если такого ключа нету ($GET['mod'])? Или где-то в конфигах уже в ручную вбита проверка?

return @mysql_result($res, 0); 

Почему игнорируется ошибка?

Я бы устал писать это в каждом файле.

if(!defined('IRB_KEY')) 
{ 
  header("HTTP/1.1 404 Not Found");       
  exit(file_get_contents('../404.html')); 
}

_____________
Заработок для веб-разработчиков: CodeCanyon
Мое Портфолио

Дизайнеру нехрен делать в классе. Менять внешний вид нужно посредством CSS. Картинки тоже отдельно. А остальное менять не нужно, если ты не понял.

Насчет $GET - это инициализированный $_GET, там этот ключ есть обязательно.

Ошибка? А зачем она мне там? Функция mysql_result() генерирует фатальную ошибку если запрос вернул фигу. Мне ошибка не нужна, мне нужно FALSE. И собачка - самый рациональный способ его получить.

Честно говоря кричат кричат на ООП, тёмный лес сырые дрова.
Но ведь то же самое и с функциями да же если их определить в модульность, сделать архитектурой MVC. Что хаять методику другую если функциональная показала себя так же не с лучшей стороны.
Только не нужно бить в грудь и кричать что на функциях меньше кода, враньё, дублирования мама не горюй встречается. ООП то же не пряник. Но как с первым так и со вторым нужно пользоваться уметь.
Кстати twin если в команде вырисовываются правила, методы, функции это то же фреймворк )
Смысл обгаживать машины если сел в Таврию и по ней судить. Тот же принцип можно и к функциям приложить: "E.... вашу мать кто писал эту хрень на функциях, куча продублированного и связного кода", смысл обгаживать велосипеды если сел на Китайское барахло.

Я бы конечно генерацию html вынес бы,не важно куда. Просто если это модель, пусть её знания остаются о работе с данными и не распространяются на html. Возможно класс helper который можно всегда заменить. Да и повторное использование кода затруднено, хотя опять же какого. Если класс будет повторно использоваться только как операции с данными, тогда имеет избыточный код и методы, что говорит само по себе что нужно вынести в отдельный класс например class Question{public function createQuestions(new Question_Model;); private function _createViewLine()}
Повторное использование и заменяемость уже выше.

Где скорее всего происходит дублирование механизма аплоада и перемещения файлов, то же возможно как компонент для повторного использования. Да есть специфические данные, но это же всё настраивается при инициализации.
Мне всё таки класс берёт на себя много ответственности, абстракции: работа с файлами, рендеринг, работа с БД. Инкапсуляция нескольких абстракций один класс это не модульность.

Ведь вынесли пагинатор в отдельный класс )))

Простой пример хрупкости класса. Происходит замена запроса к данным на файловые, приходится дорабатывать метод createQuestions и адаптировать запросы под его уже существующие вставляемые данные в html, конечно не говоря о смене БД любого формата.

Сложно тестировать, createQuestions, если поставить на модульный тест, что потребуется проверять? Правильный html код? Корректную выборку данных из таблицы? Корректную выборку для пагинатора? Возвращает метод только html. Его не потестируешь, получается остальные части кода этого метода не покрыты тестами и могут являть собой опасные участки для ошибок.

Не ругайте сильно, это чисто моё мнение )))

Хороший API для класса например newLine
Метод тестируется на корректное добавление записи и всё. Так же несколько тестов с не правильными данными. Метод обеспечивает единую операцию. Лёгок в поддержке, в замещении, в тестировании.

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

И я не становлюсь заложником чужого кода. Чуть раньше приводил пример про пробелы и друпал. Наверняка те, кто пользуется фреймворками, могут привести таких примеров массу. Я не пользуюсь, только слышу.

А самое главное - нет у меня никакой унификации. Ну или самый минимум. Приходится дополнять возможности PHP. Если допустим htmlspecialchars() не работает с массивами, можно её научить. Работала бы - не возникло бы вопросов.

Я про то, что код пишется снизу вверх, а не наоборот. Проблемы решаются по мере их поступления. Я не понимаю, почему это считается плохо. Почему нужно сначала спроектировать большую монолитную структуру, а потом её реализовывать. А ошибки в этой архитектуре как?

У нас проще все. Есть библиотека самодостаточных классов. Почта, постраничка и так далее. Есть сторонние возможности, в этом модуле допустим потребовалась PCLZIP.
Бери и пользуйся. Не нужно привязываться к ядру, где все это есть, нужно или нет. И не нужно искать, где и как это подключается и вызывается. И даже доку не нужно зубрить. Код то, повторюсь, практически процедурный.

А можно использовать свои решения или вообще не пользоваться нашими наработками. Главное что бы код был максимально прозрачным и ремонтопригодным. И самодостаточным кстати. Чего нельзя сказать о том, что написан на фреймворке.

Вот интересно... Я допустим работаю в конторе, которая юзает симфони. Проработал 3 года, накопил кучу интересных решений, сложил аккуратненько в репозиторий. А завтра контора обанкротилась. Я устраиваюсь в другую, а там кохана. И что? Всё, что жил, то зря.

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

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