GET, помимо лирики и взаимных инсинуаций, высказанная идея по поводу разделения на методы является даже не моей, а Роберта Мартина. А может быть и более великих людей из GoF, например. Там говориться об избегании излишнего ветвления, засчет вынесения в отдельные методы. Где-то там же проходит идея что метод не должен превышать 10 строк. В манифесте что ли, черт, не помню, да это и не важно, можно найти если кому особо интересно.

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

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

Ron
Не знаю как ещё объяснить. Я не говорю, что нельзя сделать через методы, но какая разница - логика вычислений никуда не денется. Ну будет красиво в коде стоять что-то типа

$SQL=query::sql(true);  

и весь бой происходить будет там - в query, а если там еще и будет клубок переменных и методов с наследованием - то через год, другой человек за***ся эту логику разгребать, тем более она будет общей для всех запросов, или придется еще наварачивать внутри кучу условий.

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

Когда всё это укладывается в одном скрипте, для одного скрипта и в правильной последовательности.

twin, правильно заметил что истина где-то посередине, уже сделал 4 блока по 4 запроса с общей логикой - всё просто, быстро и понятно.

Ладно, вопрос снят.

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

Любой queryBuilder помог бы улучшить 1-ый вариант.

_____________
There never was a struggle in the soul of a good man that was not hard

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

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

Так вот. Я в очередной раз убедился, что это все на самом деле кодерские понты.

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

То, что написано пять лет назад, прекрасно работает. Изменились требования к проекту, соответственно я решил "привести все в порядок". Как в анекдоте. Пока я был холостой, у меня всё валялось по порядку. Как женился, стало аккуратно лежать где попало.

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

А то, что вменяется толстым контроллерам, как зло, за пять лет использования системы ни разу не навредило. Даже наоборот.

Про всякие ORM, queryBuilder, герераторы кода и иже с ними вообще даже говорить не хочу. Они не нужны там, где проект не универсален. А универсаьны только фреймворки. Даже приложения (всё, что на этих фреймворках написано), даже там это нафиг не нужно. Потому что и технологии, и требования к продукту меняются сейчас очень быстро. Не успеешь оглянуться, как вся эта мишура устареет и отправится на помойку.

Грамотная архитектура? Забудьте это, как страшный сон. Она является грамотной только до того момента, как изменятся хотелки заказчика. Потом начнутся костыли, либо глобальное её изменение. Не говоря уже о рефакторинге, которого код требует уже после первого же теста. (Это не я сказал).

Остается одно, код должен быть максимально прозрачным, дабы все подряд могли его понять с полтыка. В очередной раз - а для чего??? Какая цель этого?

Для чего писать код, ориентируясь на кодеров из двух, прямо противоположных групп? Одна из них - низкоквалифицированные и бестолковые кодеры, котрым нужно все по полочкам, вторая наоборот - люди с завышенным ЧСВ, для которых не важен результат, а важно "качество" кода. В кавычках, потому что это качество чаще всего сводится к банальному "смотри как я умею".

Если программист не умеет читать чужой код, или читает его через силу, приправляя слюнобрызганьем "говокодеры!", то пусть ищет другое место работы. Слава Богу, полно фреймворков, CMS и прочей лабуды, где это приветствуется и поощряется.

Если работник не может ориентироваться в любом коде, хочет мягкой постельки - это его проблема. Либо читай выше, либо учись. Я не обязан думать за него, подтирать сопли всякими паттернами и убаюкивать колыбельными принципами ООП методологий. Чай не детский сад. Про пет-проекты вообще говорить не стоит.

А что касается