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

whirlwind · 19 Мар 2009

Давай. Накидать 1000 контроллеров, которые не используют массивы а используют класс Vars ? Куда кидать?

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

PHP:

require_once 'MPS/Core/Component.php';
require_once 'MPS/Decorator/ViewTemplateIdModifier.php';

class MPS_UI_J_Component_InjectTemplateIdModifier extends MPS_Component {
    
    function run(MPS_Environment $env)
    {
        $modifier = new MPS_Decorator_ViewTemplateIdModifier($env->getView(),
            '/' . $env->getServer()->getVar('merchant')->getJoinTemplate());
        $env->setView($modifier);
    }
    
}

Вот так двумя строчками прикручиваем скины. getServer и getView это все классы переменных. Ну и таких примеров много. Надеюсь ты все же не потребуешь всю тыщу тут постить

svetasmirnova · 19 Мар 2009

fixxxer

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

Вот +1

Простите за бессодержательный комментарий

fisher · 19 Мар 2009

PHP:
Автор оригинала: whirlwind
Давай. Накидать 1000 контроллеров, которые не используют массивы а используют класс Vars ? Куда кидать?

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

PHP:

require_once 'MPS/Core/Component.php'; require_once 'MPS/Decorator/ViewTemplateIdModifier.php'; class MPS_UI_J_Component_InjectTemplateIdModifier extends MPS_Component { function run(MPS_Environment $env) { $modifier = new MPS_Decorator_ViewTemplateIdModifier($env->getView(), '/' . $env->getServer()->getVar('merchant')->getJoinTemplate()); $env->setView($modifier); } }

Вот так двумя строчками прикручиваем скины. getServer и getView это все классы переменных. Ну и таких примеров много. Надеюсь ты все же не потребуешь всю тыщу тут постить

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

PHP:

        $modifier = new MPS_Decorator_ViewTemplateIdModifier($env->getView(),
            '/' . $env->getServer()->getVar('merchant')->getJoinTemplate());

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

AnToXa · 19 Мар 2009

насчет ассоциативных массивов / объектов кидающих эксепшены небольшая ремарка.

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

получается оба правы

массивы, как key/value pairs весьма удобно использовать во внешних взаимодействиях между "компонентами", тогда как внутри компонентов уже нужен контроль и всякие преобразования.

john.brown · 19 Мар 2009

fisher
У whirlwind, конечно, несколько своеобразное имяобразование (

), но вот с этим коментом

Вот так двумя строчками прикручиваем скины.

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

StUV · 19 Мар 2009

общая проблема увлечения процессом забывая о цели

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

whirlwind · 19 Мар 2009

Автор оригинала: john.brown
несколько своеобразное имяобразование

Ну да, сам наверное знаешь, тут уже приходится руководствоваться не 2 критериями

Пожалуй для меня это одна из проблемных частей реализации ООП в php. Жаль неймспейсы нормальные загубили

-~{}~ 19.03.09 20:29:

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

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

О том и речь. Потратить полчаса на класс, что бы потом сэкономить дни на отладке. Для меня тут и думать не о чем.

-~{}~ 19.03.09 20:33:

Автор оригинала: fisher
впрочем, если я начну спрашивать, что она делает, мы уйдем в глубокий оффтоп

PHP:

class MPS_Decorator_ViewTemplateIdModifier extends MPS_Decorator_View {
    protected $prefix = '';
    
    function __construct(MPS_View $view,$prefix='')
    {
        parent::__construct($view);
        $this->prefix = $prefix;
    }
    
    function getPrefix()
    {
        return $this->prefix;
    }
    
    function setPrefix($prefix)
    {
        $this->prefix = $prefix;
    }
    
    function display($templateId)
    {
        $this->view->display($this->prefix . $templateId);
    }
    
}

а так понятнее?

AnToXa · 19 Мар 2009

О том и речь. Потратить полчаса на класс, что бы потом сэкономить дни на отладке. Для меня тут и думать не о чем.

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

atv · 19 Мар 2009

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

Так это и есть OOD, и это никак не вяжется с

>>Я всё-таки не понимаю, о чём речь, об Объектно-Ориентированном >>Проектировании (OOD), или об Объектно-Ориентированном Программировании (OOP)
обо всём. ещё раз - любое "оо" - оно должно быть только про кодинг, про компоненты. и это всё вторично.

Похоже, весь сыр бор из-за формулировок, как это часто бывает.

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

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

А какие критерии оценки ты используешь? Где заканчивается красота, и начинается перерасход ресурсов? И учитываешь ли ты в минимуме затрат затраты на сопровождение?

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

Закон мироздания, это то, что всё УЖЕ сложно. А искусство программиста, УПРОСТИТЬ эту сложность, до возможности её реализации. А упрощение достигается путём использования АБСТРАКЦИЙ, суть - выделение наиболее важных аспектов предметной области от не имеющих значения, В КОНТЕКСТЕ ПОСТАВЛЕННОЙ ЦЕЛИ.

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

whirlwind · 19 Мар 2009

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

это из разряда - 42

StUV · 19 Мар 2009

whirlwind
оффтоп
несколько "покоробило"

$env->getServer()->getVar('merchant')

в контексте таких-то наворотов

whirlwind · 19 Мар 2009

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

PHP:

class MPS_UI_J_Component_InjectTemplateIdModifierTest
    extends PHPUnit_Framework_TestCase
{
    function testRun()
    {
        $ctrl = new MPS_UI_J_Component_InjectTemplateIdModifier();
        $merch = new MPS_Model_Merchant();
        $merch->setJoinTemplate('gray_template');
        $env = new MPS_Environment();
        $env->getServer()->setVar('merchant',$merch);

        $ctrl->run($env);

        $view = $env->getView();
        $this->assertType('MPS_Decorator_ViewTemplateIdModifier',$view);
        $this->assertEquals('/gray_template',$view->getPrefix());
    }
}

вот вам и документация (прикрыл голову руками)

fisher · 19 Мар 2009

Автор оригинала: whirlwind
а так понятнее?

так - да
единственное что непонятно - названия ViewTemplateIdModifier (изменятель идентификатора вью-темплейтера?) и ещё какой-то декоратор

-~{}~ 19.03.09 21:48:

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

PHP:

ViewFactory::setTheme('gray');

внутри - скин это ж просто часть пути.
всё. нафига

PHP:

        $modifier = new MPS_Decorator_ViewTemplateIdModifier($env->getView(),
            '/' . $env->getServer()->getVar('merchant')->getJoinTemplate());
        $env->setView($modifier);

-~{}~ 19.03.09 22:02:

Автор оригинала: atv
Так это и есть OOD, и это никак не вяжется с

Похоже, весь сыр бор из-за формулировок, как это часто бывает.

нет, это не OOD. это данные и че с ними происходит

Автор оригинала: atv
Или говоря о "прозрачности аналитической модели", ты не подразумеваешь объектную декомпозицию задачи, а только алгоритмическую? Интересно тогда узнать как такое может быть.

это юз кейсы, варианты использования - но снова до "ОО" - с описательно позиции пользователя и что происходит с данными

Автор оригинала: atv
А какие критерии оценки ты используешь? Где заканчивается красота, и начинается перерасход ресурсов? И учитываешь ли ты в минимуме затрат затраты на сопровождение?

это я не понял

Автор оригинала: atv
Закон мироздания, это то, что всё УЖЕ сложно. А искусство программиста, УПРОСТИТЬ эту сложность, до возможности её реализации. А упрощение достигается путём использования АБСТРАКЦИЙ, суть - выделение наиболее важных аспектов предметной области от не имеющих значения, В КОНТЕКСТЕ ПОСТАВЛЕННОЙ ЦЕЛИ.

ну мне казалось искусство программиста - не сколько упрощать, а 1) понять или помочь доработать бизнес-модель 2) построить модель "данных", 3) сделать, что нужно, и 4) в срок

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

StUV · 19 Мар 2009

fisher

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

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

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

--
часто слышал (до "кризиса"

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

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

возможно - "творчества" интуитивно дешевле чем текучка+обучение и явно менее рискованно переключений между технологиями

вот.

-~{}~ 19.03.09 22:32:

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

- Самое обидное, когда кто-то из нач. тех. отделов начинает внедрять какую-то очередную автоматизацию и вот б%$#ть именно на МОЕМ ПРОЕКТЕ!

pilot911 · 20 Мар 2009

PHP:

class MPS_UI_J_Component_InjectTemplateIdModifier

class MPS_Decorator_ViewTemplateIdModifier

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

atv · 20 Мар 2009

это я не понял

Т.е. просто вот так, да? не понял и всё. Тоже вариант... ухода от ответа.

не сколько упрощать, а 1) понять или помочь доработать бизнес-модель 2) построить модель "данных", 3) сделать, что нужно, и 4) в срок

Для этого нужно сначала упростить. Или ты не понимаешь значение абстракций в программировании?

-~{}~ 20.03.09 00:32:

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

автокомплит рулит...

Lightning · 20 Мар 2009

Автор оригинала: fisher
я не писал что у меня не работает.

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

Автор оригинала: fisher
и я знаю что делать чтобы работало.

Вот и поделись с нами. А то пишешь теоретические выкладки, оторванные от контекста. Естественно тебе ответят "А у меня все работает".

fisher · 20 Мар 2009

Автор оригинала: atv
Или ты не понимаешь значение абстракций в программировании?

в игнор за храком

-~{}~ 20.03.09 15:32:

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

Вот и поделись с нами. А то пишешь теоретические выкладки, оторванные от контекста. Естественно тебе ответят "А у меня все работает".

да я теперь уже не вижу никакого смысла
вы чуваки просто просрали пхпклаб
у вас два состояния "согласен на все 100%!" и "а ну-ка ну-ка покажи-ка нам да, такой умный тут выискался!"
пионеры, идите в жопу

Lightning · 20 Мар 2009

fisher
Вот Фиксер написал полезные вещи http://phpclub.ru/talk/showthread.php?postid=844428#post844428
А ты уже сколько килобайт теорем тут понаписал?

идите в жопу

Если это относится ко мне, то я отвечу:
Взаимно.

Духовность™ · 20 Мар 2009

пионеры, идите в жопу

ТАК!!

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

TDD infected, paranoid

маленький монстрик

накатила суть

prodigy-одаренный ребенок

просто кулибин

Rotaredom

TDD infected, paranoid

prodigy-одаренный ребенок

Новичок

TDD infected, paranoid

Rotaredom

TDD infected, paranoid

накатила суть

Rotaredom

Новичок

Новичок

Трудоголик

накатила суть

Трудоголик

Продвинутый новичок