проблемы объектного сознания

[whirlwind]

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

мы не пытаемся доказать. мы хотим узнать

Автор оригинала: HraKK
по пунктам, какие проблемы порождает ООП и которые отсутствуют в процедурном подходе.

если это непонятно, то ну я совсем не понимаю что вы мне пытаетесь доказать

 

[StUV]

john.brown
э...
1. где я сказал, что "ооп - зло, давайте фигачить процедурщину" (ссылки на пост достаточно) ?

2. с чего я начал: http://phpclub.ru/talk/showthread.php?postid=844536#post844536

3. стоило заметить
>> у вас изначально негативный подход к процедурному программированию как таковому
как сразу вписали в "ненавистники ооп" (представляю как забавляет отдельных личностей, неявно здесь присутствующих, как по детцки меня тролли развели)

4.

продлжить заниматься делом

продолжаю
но не хочу это делать ремесленно "по накатанной"
пытаюсь совершенствовать себя и окружение

что и приводит нас к этому

совершенствуя гибкость мышления и способность находить верные решения. Делая, при этом, естественно, какие то ошибки...

и к этому

http://phpclub.ru/talk/showthread.php?postid=844351#post844351

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

-~{}~ 17.03.09 19:40:

ну и... ответ на

по пунктам, какие проблемы порождает ООП и которые отсутствуют в процедурном подходе

очевидно есть в
http://phpclub.ru/talk/showthread.php?postid=844575#post844575

м.б. все-таки внимательнее тред читать будем ?
или 3 страницы никак ниасилить ?

 

[whirlwind]

слив засчитан

 

[john.brown]

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

мне суть проблемы представляется в виде "попарного противостояния (A vs. B)" в терминах проблем:

производительность кода
производительность труда
уровень (стоимость) кадров
выбор средства/подхода

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

 

[pilot911]

Автор оригинала: john.brown
было хорошим, но не оч имеющим отношение к теме. Это скорее о квалификации проектировщиков/архитекторов/менеджеров, а не об ооп, как способе "запутывать новичков", "порождать слепость", "создавать илюзорный мир"... А ведь топикстартер именно об этом... Т.е. демонизация ооп, и придание его анафеме

тут хотели конкретные примеры (просьба не ссылаться на оффтоп, как пару страниц назад)

имхо, вот такое ооп и есть зло:

$dbh = Creole::getConnection(MPS_DATASOURCE);
$dmr = new MPS_DataMapper_SQL_Registry($dbh);
$env = new MPS_Environment(new MPS_Vars($_REQUEST),
                           new MPS_Vars($_SERVER));
$env->setView(new MPS_XI_View());
$env->getRequest()->setVar('xml',file_get_contents('php://input'));
$env->setDataMapperRegistry($dmr);

$front = new MPS_UI_X_FrontController(new MPS_UI_Auth(),
                                      new MPS_Factory('MPS_UI_X','MPS/UI/X'));
$front->run($env);

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

такого надо избегать просто потому, что голова пойдет кругом у вновь пришедших в проект программистов

 

[jahson]

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

 

[whirlwind]

Автор оригинала: pilot911
тут хотели конкретные примеры (просьба не ссылаться на оффтоп, как пару страниц назад)

блин я же просил... иди помолись на свой софтверный лоадбалансер неандерталец.

 

[svetasmirnova]

x-yuri
> whirlwind вот второй минус: http://www.phppatterns.com/docs/des...rld_in_patterns

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

 

[pilot911]

Автор оригинала: whirlwind
блин я же просил... иди помолись на свой софтверный лоадбалансер неандерталец.

а по сути.. ? зачем глобалсы оборачивать объектом ?

 

[Long]

Господи, да оставьте их. пусть _сами_ прострелят себе ногу. Пусть кладут 10 слоев абстракций между запросом юзверя и бд. В свое время HabaHaba отлично сформулировал суть веб-программирования - "реально пишешь код только один раз, когда пишешь свой первый форум. дальше - тот же форум, только с вариациями". Если кому-то приятно осознавать что для того чтобы показать сообщение с id=12343 "сработал контроллер страницы, который запустил фабрику, которая ....." - пусть тешатся.
Есть две области в веб-разработках в которых без ооп очень сложно будет - тонкий клиент для коммерческого продукта (банки и т.п.), а вторую область пока писал - забыл Эта полезность заключается в том, что поддержка такого продукта будет проста (если конечно повезло с архитектором).
В остальных случаях ооп практически бесполезен, ибо состояния между запросами не сохраняются.

 

[whirlwind]

Автор оригинала: pilot911
а по сути.. ? зачем глобалсы оборачивать объектом ?

что бы избавиться от глобалсов. намекаю - какбе на пехапе можно не только для веба писать... дальше сложнее

 

[john.brown]

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

 

[pilot911]

Автор оригинала: whirlwind
что бы избавиться от глобалсов. намекаю - какбе на пехапе можно не только для веба писать... дальше сложнее

объект, хранящий в себе глобалс и интерфейсы - упростит нам жизнь из-под CLI ?

 

[john.brown]

Long
pure phtml for ever? Так тебя надо понимать?

 

[pilot911]

Автор оригинала: john.brown
pilot911
Представь себе, это очень удобно Я, например, так делаю потому, что в некоторых случаях использую их значения не напрямую, а после некоторой трансформации, и весь код, который этим занимаеться, находится в одном месте, и за всегда можно легко расширить/изменить/отследить. Так же оч удобно устраивать проверку валидности значений в глобалсах... Не вызывая какую то функцию проверки при старте скрипта, или явно перед обращением к глобалсу, а автоматически, получая значение поля объекта...

спасибо, пояснил, однако не совсем понял, что значит "некоторая трансформация" глобалсов, например, $SERVER

обычно присутствует взгляд на глобалсы как на константы, нет ?

пс.

для извлечения данных из глобалсов (в том числе и в CLI) я использую ::getIndpEnv($getEnvName), которая выдает значения независимо от подтекста - веб или CLI

городить для таких вещей огород из создания нового объекта по-моему крайность

 

[whirlwind]

Да дофига почему. Просто 3 строчками этого не объяснишь. Из-за этого все непонятки. А в основе всех этих мелочей лежат возможности ООП. Ну тупо навскидку что в голову лезет конкретно по этому примеру:

1. Реализация сессий. Там передачей аргумента не получится, потому что будет копирование массива.
2. Контроль над содержимым. Класс выбросит исключение, если отсутствует какое то значение. Массив тихо промолчит.
3. Изоляция багов. Найденный баг в классе переменных никак не затрагивает код использующий этот класс.
4. Можно изменить поведение переменных в реальном времени (декорировать объект).
5. Тестирование...

etc

Конечно сходу можно возразить: а почему не сделать $env->getRequestVar() etc... Отвечаю на ваш ответ - посчитайте сколько кода будет продублировано? вот оно где code-reuse а не в мифических других проектах. впрочем я повторяюсь

-~{}~ 17.03.09 20:25:

Автор оригинала: pilot911
объект, хранящий в себе глобалс и интерфейсы - упростит нам жизнь из-под CLI ?

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

 

[pilot911]

Автор оригинала: whirlwind
Да дофига почему. Просто 3 строчками этого не объяснишь. Из-за этого все непонятки. А в основе всех этих мелочей лежат возможности ООП. Ну тупо навскидку что в голову лезет конкретно по этому примеру:

1. Реализация сессий. Там передачей аргумента не получится, потому что будет копирование массива.
2. Контроль над содержимым. Класс выбросит исключение, если отсутствует какое то значение. Массив тихо промолчит.
3. Изоляция багов. Найденный баг в классе переменных никак не затрагивает код использующий этот класс.
4. Можно изменить поведение переменных в реальном времени (декорировать объект).
5. Тестирование...

etc

Конечно сходу можно возразить: а почему не сделать $env->getRequestVar() etc... Отвечаю на ваш ответ - посчитайте сколько кода будет продублировано? вот оно где code-reuse а не в мифических других проектах. впрочем я повторяюсь

ясно... аргументация достойная, но вызывает вопросы:

2. увидеть бы, как родитель использует исключение вот этого объекта

new MPS_Vars($_REQUEST)

при обращении к несуществующему ключу ( не проще ли isset() вызвать ? )

4. что можно изменить в поведении $SERVER или $REQUEST ?

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

в вопросе было про интерфейсы в том числе

 

[john.brown]

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

П.С. какие интерфейсы в объектах? Ткни, плз, где оно?

 

[StUV]

john.brown

А ведь топикстартер именно об этом...

о чем _именно_ топикстартер - я хз, остается только догадываться

просто в

ооп, как способе "запутывать новичков", "порождать слепость", "создавать илюзорный мир"

я вижу немного

скорее о квалификации проектировщиков/архитекторов/менеджеров

и никаким боком

демонизация ооп, и придание его анафеме

ибо далек от категоричности любого рода...

 

[pilot911]

Автор оригинала: john.brown
pilot911
Константы, это константы, а глобалсы, это глобалсы. И не надо путать Из одного значения элемента глобалса можно иногда извлеч пару тройку полезных значений. И, в случае объектной обертки, это делаеш токмо один раз, в одном месте... Ну и плюс все то, что whirlwind написал...

ясно