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

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

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

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

Как прав был Стерлинг Хьюз, хотя сказал это очень давно:

У меня такое чувство, что всё ООП состоит из превращения уже имеющихся задач в новые. И уже только потом дело доходит до их решения. 

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

На самом деле совсем не обязательно одевать глубоководный скафандр для того, чтобы перейти вброд ручей.

Правда в скафандре смотрится наверное круче :)

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

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

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

Меня тоже иногда страшо бесит то, что блогадаря ООП код сильно раздувается и порой думаеш "да эти 3 класса можно в 12 строчках линейного кода уложить". Особенно больно когда времени нет этим раздуванием заниматся. Но блогадоря именно этому раздуванию его можно тестировать, расширять не изменяя старый код, заменять его части и возможно многократно использовать, то это раздувание становится вполне оправданным.


_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

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

Иногда доходит до абсурда. Код, призванный сделать доброе дело, начинает делать все в точности до наоборот.

Приведу пример.

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

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

Что мы имеем. Фактически тоже самое, что и получение данных юзера непосредственно в модели (наследник) плюс еще целый класс User, где все продублировано. Плюс какой-нибудь интерфейс, дабы нерадивый прогер не напортачил чего-нибудь. Да синглтон сунуть - нафиг нам несколько экземпляров, ведь в таком бардаке немудрено заблудиться. И пошло-поехало. гектары кода вместо одного запроса в модели. Да, пусть их 40 штук. Пусть придется 40 раз нажать Ctrl+v. Но как часто это бывает, что данные нужно менять везде? На моей практике такие случаи можно пересчитать по пальцам левой ноги. А вот в конкретном месте, на конкретной странице, в конкретной модели - очень часто. И получается, что вроде как для упрощения сделан класс User. а он все многократно усложняет.

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

Проблемы индейцев шерифа не...

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

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

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

Да понятно это. Просто каждый раз переписывая модели для каждого конкретного случая, я задаюсь одним и тем же вопросом - нахрена?

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

Беда в том, что это мало кто делает. Задумывается всмысле. Привыкли писать по учебнику. Раз данные от юзера - бац класс. И хорошо. А то, что от него проблемы, дык это же все в угоду многократному использованию, расширяемости и чего там еще... тестируемости. А оно надо?

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

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

Или ему разбирать 2000 строк, или 20000000. Причем по большей части мертвого кода, состоящего из сеттеров, гетеров, ексепшенов, интерфейсов и прочих заплаток.

Я понимаю, если работаешь в девелоперской компании, приходится соблюдать корпоративные законы. Но не так же фанатично, что даже новичкам на форумах советовать использовать для инициализации языковых переменных отдельный класс и запрещать global. Кстати, а где этот языковой класс должен находится? Дай угадаю))) В папке language, в файле ru.php

Ну и на кой нужна эта обертка в виде класса, все ведь так и так в одинаковом месте. Только ради того, что какой-то недоумок где-то в недрах скрипта с великого бодуна инициализирует или изменит переменную с префиксом $LANG_?

Ужос...

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

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

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