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

[jahson]

Автор оригинала: StUV
тему бы продолжить в другом месте, тем более, что здесь

Объясняю для альтернативно одарённых. Имелось в виду то, что с точки зрения математики с объектами всё сложно, в то время как в процедурном царстве всё более радужно. Хотя процедуры, обсуждаемые здесь, вовсе не обязательно идентичны математическому понятию функции. И уж тем более пхп - не язык функционального программирования. Если ты хочешь здесь каким-то образом поднять математику - давай. Пока же я не увидел ничего более-менее похожего на математику.

 

[AmdY]

Автор оригинала: fixxxer
кстати тут нигде объекты не мешают =)

в случае с бд она(ORM) связывает руки и не даёт насладиться мощью sql, кстати, работал с ORM написанной в процедурном подходе - съедобно.
решение с nginx помогает отвязаться от front controller и его порождений (спорно, но эффективно), то же самое с анализом разнородных данных, которые сложно свести к единому объекту. тогда попытка решить задачу с помощью ООП приводит не только к потере скорости, но и увеличению времени разработки-поддержки из-за ветвистого дерева зависимостей.
Но и не пользоваться ООП только чтобы не пользоваться ООП - глупость.
Юзаю ООП подход везде где могу, но знаю где остановиться.

 

[Lightning]

у вас изначально негативный подход к процедурному программированию как таковому

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

 

[svetasmirnova]

AmdY
> в случае с бд она связывает руки и не даёт насладиться мощью sql

А она - это кто?

 

[AmdY]

svetasmirnova
ксожалению, столь любимая мною объектно-реляционная проекция (ORM), вернее попытка спроецировать.
спасибо, исправил.

 

[StUV]

svetasmirnova

Эээх, по теме добавить-то к п.1 из
http://phpclub.ru/talk/showthread.p...4428#post844428 нечего

а что добавлять ?
достаточно древние тесты на примитивных примерах дают прирост производительности при "оо->func" в ~10-15% (оптимизация конкретного решения уменьшает разницу)
соответственно, в сравнении с затратами на логику - эта разница стремится к 0.

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

т.е. при очевидных затратах на преобразования вида "матрица<->дерево", выработать правильные критерии определения узлов, в которых эти преобразования критичны

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

как-то так

 

[whirlwind]

Автор оригинала: StUV
и все 10-ки тыс на ооп ВО_ВСЕХ_УЗЛАХ_СИСТЕМЫ - ?

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

$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);

То есть ответа на мой вопрос нет?

И эта, а без "тайп хинтинг, эксепшены, паттерны, TDD" объектный код тоже, что ли, нельзя писать?

Хватит повторяться. Перечитайте топ - я ни разу не сказал что нельзя. Вы этим владеете? Ну так show me the code.

 

[StUV]

для себя "на уровне кода" я примерно так определился:

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

2. поправки к конкретным технологиям/решениям - т.е. подход всегда в некоторой степени определяется затратностью/производительностью конкретной реализации конкретной задачи

 

[cDLEON]

cDLEON

Это ты назывешь ООП? А какой изначально обьектно орентированный язык ты изучал? Модули - это не ООП.

А что в твоём понимании ООП?
В любом случае любой "объект" получается как модуль, со своей логикой внутри.
И если тебе не нравится слово "модуль", можешь придумать себе любое другое, лишь бы нравилась.
StUV

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

Я вот не совсем понял к чему ты этим ответом ведёшь.
Если к тому, что стоимость БОЛЬШЕ, и можно жертвовать удобством - то пожалуйсто - C++ в руки. Твоё веб-творение будет летать.

 

[StUV]

whirlwind
т.е. начиная с

$front->run($env);

сплошной ооп-в-пхп - ?

ну и что... у меня тоже, вплоть до уровня абстракции
представления данных в бд - оно ТОЖЕ объектное (как следствие требований "конвейерной универсальности") - т.е. динамический pl/sql в большинстве случаев гоняет табличные представления в иерархические структуры и обратно, оптимизация живет отдельно в кешах разного уровня

но!
затратность на разработку/поддержку, стоимость кадров, обучение, время вхождения, разного рода риски... - именно эти проблемы - _рабочие_проблемы_ - поднимают вопросы целесообразности, а не теоретические вопросы ценности различных подходов как таковых в конкретных реализациях

-~{}~ 16.03.09 22:20:

cDLEON

Я вот не совсем понял к чему ты этим ответом ведёшь.
Если к тому, что стоимость БОЛЬШЕ, и можно жертвовать удобством - то пожалуйсто - C++ в руки. Твоё веб-творение будет летать.

я ни к чему не веду
если мне надо, я жертвую удобством и пишу на php

 

[whirlwind]

Автор оригинала: StUV
но!
затратность на разработку/поддержку, стоимость кадров, обучение, время вхождения, разного рода риски... - именно эти проблемы - _рабочие_проблемы_ - поднимают вопросы целесообразности, а не теоретические вопросы ценности различных подходов как таковых в конкретных реализациях

Я не понимаю о чем ты говоришь? Какие теоретические вопросы? Ты думаешь я тут специально для неверующих примеры на коленке собираю? Весь код из рабочих проектов.

root@PLUTO:~/work/MPS/tests# phpunit MPS
PHPUnit 3.3.14 by Sebastian Bergmann.

............................................................  60 / 874
............................................................ 120 / 874
..........I................................................. 180 / 874
............................................................ 240 / 874
............................................................ 300 / 874
............................................................ 360 / 874
............................................................ 420 / 874
............................................................ 480 / 874
.......I.................................II................. 540 / 874
....................................II.............I.....I.. 600 / 874
..............I............................................. 660 / 874
......................I..................................... 720 / 874
............................................................ 780 / 874
.....I...........................................I.......... 840 / 874
..................................

Time: 9 seconds

OK, but incomplete or skipped tests!
Tests: 874, Assertions: 3765, Incomplete: 12.

Стартанули в начале декабря 2008, 2 субпроекта, 254 ревизии (шаблоны в т.ч.) из которых только 1 багофикс, остальное - рефакторинги и расширение функционала. Прокачали с 6 нулями. Риски потерь сведены к минимуму, заказчик счастлив, разработчик не задрачивается поиском багов. Какие еще цифры нужно что бы это превратилось из теории в практику?

 

[pilot911]

Автор оригинала: whirlwind

$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);

сколько времени надо потратить на то, чтобы разобраться в этом коде.. ?

уже не говоря о том, что еще больше потребуется времени на то, чтобы повторить хотя бы часть из написанного для своих нужд ?


имхо, такой код "для себя любимого"

 

[whirlwind]

pilot911 не позорься лучше

 

[pilot911]

Автор оригинала: whirlwind
pilot911 не позорься лучше

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

каждому свое, но пинатели мозгов всегда есть среди нас

например:

$env = new MPS_Environment(
                   new MPS_Vars($_REQUEST),
                   new MPS_Vars($_SERVER));

почему не просто

$env = new MPS_Environment(
                   $_REQUEST,
                   $_SERVER);

и так далее..

 

[cDLEON]

если мне надо, я жертвую удобством и пишу на php

процедурами забыл добавить.

 

[whirlwind]

Автор оригинала: pilot911

и так далее..

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

 

[StUV]

whirlwind

Какие еще цифры нужно что бы это превратилось из теории в практику?

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

если ты перечитаешь топ, то выше уже обсуждался вопрос целесообразности реализации "логики той что на php" с применением ood/tdd(tfd) - очень хорошо что у вас оно работает и очень жаль, что в наших условиях это не так

соответственно и практика у нас разная - и если ты "суслика не видишь", это еще не значит, что он не существует

-~{}~ 16.03.09 23:17:

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

Стартанули в начале декабря 2008, 2 субпроекта, 254 ревизии (шаблоны в т.ч.) из которых только 1 багофикс, остальное - рефакторинги и расширение функционала.

краткосрочный проект
код ядра бизнес-логики писался с нуля или был готовый toolkit покрытого тестами собственного ядра, частично ориентированного на сервисы реализуемого проекта?
%% наличия средств для реализации необходимых сервисов от реализованного функционала?
%% временных затрат от написания тестов к функционалу?

Прокачали с 6 нулями.

в чем качали?

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

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

разработчик не задрачивается поиском багов.

кто такой этот разработчик?
т.е. вам не нужно поддерживать проект после выпуска? или?

Какие еще цифры нужно что бы это превратилось из теории в практику?

решения по отказоустойчивости/масштабированию/стоимости - примерный объем решения в железках, используемые технологии, степень использования готового oss - ?


--
там где тайна - так и пиши, я пойму =)

 

[fisher]

Lightning, я хочу кое-что специально пояснить - по-моему, я писал уже об этом - в-общем, есть такой закон: бытие определяет сознание. Можно не соглашаться, конечно - для кого-то не определяет. Но вообще-то для многих определяет. Это интересный вопрос - в интеллектуальной деятельности можно говорить и обратно: сознание определяет бытие. Вот в научной традиции есть много вещей - кросс-дисциплинарных - которые изучают именно эту связь, обычно это психология. И есть например вот какое направление - на стыке филологии и философии изучают, как язык вляет на сознание, вернее, как язык отражает сознание, и как разные языки отражают сознание разных культур (это что-то типа герменевтики - но я не большой специалист). Так вот я хотел бы подчеркнуть, что проблемы, которые я вижу - их нужно рассматривать исключительно с этих позиций. Готовы программисты к этому или нет - это второй вопрос.

Вот Вы пишете - "это не проблемы ООП". Конечно, это на самом деле проблемы человеческие, наши с вами. Но это "проблема ООП" в том же смысле в каком язык Эллочки Людоедки определяет её культурный уровень. вот чтобы далеко не ходить - берём PHP - вот позволили в PHP две вещи: мешать код и HTML, и "инклюд". Удобно? Ну, наверное, да. А к чему это приводит?

Вот Вы пишете - психологически инкапсуляция ни к чему не приводит плохому - всё это у значит у меня субъективно. Тогда я также могу написать: Ах, на PHP пишут ламеры? Как это субъективно! Для того, кто знает PHP по-настоящему не составит туда писать "правильный" код. Понятно, в чём ошибка подобных рассуждений, да?

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

 

[StUV]

Вот я утверждаю, что объектно-ориентированные языки провоцируют этот сдвиг сознания

и выше решение

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

только вот... подвох в

объектно-ориентированные языки провоцируют

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

 

[svetasmirnova]

StUV
Я ничего не поняла

pilot911
> имхо, такой код "для себя любимого"

В общем случае тоже самое можно сказать про любой, вырванный из контекста, кусок. Внезависимости от его объектности.

whirlwind
Ну Вы как бы сказали, что это типа круто и если человек проникнется крутизной этих красивостей, он и будет ООП использовать. А ООП и сам по себе красив.

Я не писала ничего, кроме тестов и вспомогательных утилит для работы, последние 3 года. Поэтому чего-то нового приличного в объектном стиле сейчас под рукой нет. Можно я сферического контроллера в вакууме постить не буду? Код есть мой тут где-то в недрах форума.