Guest
Так покажи уже код, наконец-то. Без кода ты букашка, а с кодом - человек

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

У меня при чтении некоторых участников форума возникает такое же чувство, когда я вижу котиков. Глумиться нехорошо, но в тоже время так забавно, что сил никаких нету.

Потому что, если это CRUD приложение, то такой сайт быстрее сделать на RAD фреймворке, потому что там много готового, оттестировано, поддерживается и точно работает, чем писать с нуля опираясь на библиотеки. Это вполне логично, внушительная экономия времени.

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

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

Есть участки программ, где нужно учесть возможность менять поведение. В процедурном коде мы должны будем плодить управляющие конструкции:

function (...) {
  if (...) {
    //поведение 1
  } elseif (...) {
    //поведение 2
  } else {
    //поведение 3
  }
}

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

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

То есть уже есть кое-какой профит от ооп. Дальше я рассказывать не буду, что в крупных приложениях часто делают архитектуру в 4 слоя, с однонаправленным потоком данных и что это дает. Потому что об ооп архитектуре пишут целые книги и в одном посте это всё невозможно объяснить, чтобы показать еще более значительный профит от ооп.

Кстати забыл упомянуть, что фреймворк никак не ограничивает разработчика в реализации любых его фантазий на экране любого девайса. А то некоторые думают иначе.

Guest, не спорь с twin по поводу ООП, это бесполезное занятие, в конце ты придешь лишь к тому выводу, что Коля слишком сильно погряз в болоте простых сайтиков. Ему не нужно ООП - в силу отсутствия большого количества кода, а кода у него мало потому, что проекты которые он реализует не сложны по своей сути. Мои слова подверждены его же словами. Например, было такое сообщение, где он писал, что переписывает код проекта через каждые n лет практически полностью. Так как я работаю с весьма сложной системой, то скажу, что я бы никогда бы не стал переписывать ту систему с которой я работаю.


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