Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Блоги > e4xu

Всякие разные штуки сомнительной полезности сделанные в свободное от работы время.
Рейтинг: 4.75. Голосов: 4.

Критика Presentation Model

Запись от wvxvw размещена 18.02.2012 в 18:18
Обновил(-а) wvxvw 18.02.2012 в 19:26

Эта статья была написана по мотивам недавнего собеседования по приему на работу, где меня попоросили высказаться о presentation model и Parsley.


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

Но цель этой статьи не в критике всех существующих фреймворков, а конкретного направления, с которым мне пришлось работать. Речь пойдет о Parsley и о presentation model, но этот фреймворк будет использован только как иллюстрация. Я надеюсь, что существующие недостатки и проблемы были логическим следствием проблем в теории, и никакая улучшенная реализация не спасет ситуацию, т.как теория в корне плохая.

В первую очередь, первоисточник: http://martinfowler.com/eaaDev/PresentationModel.html Martin Fowler - человек, с легкой руки которого мы сегодня используем термин presentation model, описал основные принципы работы в этой статье. К сожалению из документации к Parsley не понятно как именно нужно использовать эту библиотеку и большинство примеров в ней находятся на за гранью здравого смысла, но лучшего источника нет. Это так, отчасти, еще и потому, что Parsley одновременно еще и делает dependency injection - абсолютно лишнюю в AS3 вещь, и это во многом затрудняет понимание происходящего.

Для начала, если вам лень читать Мартина Фаулера, в двух словах о том, что из себя представляет presentation model. Это одновременно две разные вещи: название механизма взаимодействия между элементами интерфейса пользователя и логикой программы вцелом, и конкретной части механизма, отвественной за сохранение состояния элементов интерфейса пользователя. В дальнейшем я буду использовать presentation model (pm), понимая под этим конкретный класс, реализующий взаимодействие.
Концепция взаимодействия заключается в том, что компонент интерфейса централизовано сохраняет свое состояние в pm, и так же централизовано его оттуда восстанавливает. Это можно представить на примере чекбокса: когда вы над ним нажимаете клавишу мышки, чекбокс вызывает метод у pm, передавая ему сообщение о нажатии и ожидает от pm, что тот обработает нажатие и задаст новое значение.

Проблемы, которые возникают при детальном рассмотрении нашего примера:


Что случится, когда кроме одной возможной операции (нажатия мыши) компонент будет реагировать на другие события?

Следуя статье Фаулера - нам нужна одна функция для обновления всех значений во всех изменяемых частях компонента. Это значит, что если в нашем компоненте есть два чекбокса, при нажатии на один из них, значение для второго будет обновлятся точно так же, как и для первого, хотя это абсолютно не требовалось. Фаулер говорит в статье о разных уровнях детализации (или специфичности) обновления (coarse granularity vs fine granularity), понимая, что проблема существует, но не предлагая никакого решения. Не понятно зачем создавать проблему на пустом месте.

Кто должен зависеть от кого, или, перефразируя, кто должен знать о ком - pm о компоненте, или компонента о pm?

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

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

Описание концепции не дает никакого ответа. Parsley предлагает для этого использовать dependency injection - т.е. неявным образом создавать глобальные переменные, и так же неявно передавать их дочерним компонентам. Естественно, такой подход превращает проект в монолитный блок кода не поддающегося тестированию, который нет возможности использовать повторно или обновлять по частям. Что еще хуже, найти то место где же действительно создаются те самые глобальные переменные, задаются очень важные настройки становится очень тяжело. Ситуация более типичная для монументальных продуктов написаных на Яве, с изобретенными по ходу написания настройками, распихаными по разным XML файлам в произвольных частях программы.
Если не использовать DI, то возможны два варианта: можно передать ссылку на дочерний pm дочерней компоненте в родительской компоненте, или спроектировать родительский pm так, чтобы он передал ссылку на дочерний компонент дочернему pm'у. Ни первый ни второй варианты не достаточно гибкие для того, чтобы позволить независимое тестирование родительской и дочерней компонент. В первом случае тестирование родительской компоненты, при наличие дочерней компоненты, не возможно без дочернего pm. Аналогично, во втором случае, нет возможности тестировать pm'ы без компонент.
На практике это выливается в то, что код просто никогда не тестируется. Вернее, он доводится до состояния, когда "вроде" работает и в этом состоянии доживает до момента, когда его полностью, со всеми потрохами, выбрасывают и пишут заново.

Реализация связывания между pm и компонентой - однообразный, механический труд. Человеку не хочется заниматься такими вещами, соответсвенно, напрашивается автоматизация. Автоматизация, очень часто, дело очень полезное, но не тогда, когда возможны исключения, и не тогда, когда автоматически сгенерированный код создает новые зависимости. На практике же, связывание (binding) создает зависимость к Flex Framework. Да и Parsley - это не генератор вашего кода, это библиотека (набор библиотек), которые вы подключаете к своему проекту, увеличивая общий размер, потребление памяти, количество окольных путей от одной точки интереса к другой (indirection layers); уменьшая при этом скорость работы.
Я думаю, что это очевидно, что альтернатива использованию presentation model и Parsley, или похожих библиотек, заключается в осознании того, что архитектурных фреймворков не бывает. Архитектура, это то, как вы строите вашу программу, и это не возможно импортировать в виде готового кода написаного другими людьми. Верить в то, что использовав архитектурный фреймворк ваш код вензапно превратится в логически правильно выстроенную, модульную, удобную в поддержке программу так же наивно, как и надеятся на то, что использовав те же краски, которыми пользовался ван Гог, ваши картины отправятся прямиком в известнейшие музеи мира
Всего комментариев 82

Комментарии

Старый 30.09.2012 00:46 artcraft вне форума
artcraft
 
Аватар для artcraft
Цитата:
Месяц или два назад я был на собеседовании с человеком, адептом ДИ.
IMHO дело в том что DI не нужно использовать абсолютно везде, он нужен для разделения модулей между собой, а вот классы в пределах одного модуля вполне себе могут быть намертво переплетены
Старый 30.09.2012 00:53 expl вне форума
expl
Цитата:
можно пользоваться DI и даже не знать что это такое...
Я имел в виду DI фреймворк (с рефлексией и конфигурированием). Сам принцип сомнений не вызывает
Старый 30.09.2012 01:10 artcraft вне форума
artcraft
 
Аватар для artcraft
конкретный способ реализации принципа это уже дело вкуса
Старый 30.09.2012 01:36 incvizitor вне форума
incvizitor
 
Аватар для incvizitor
Допустим есть ситуация:
У пользователя есть домик, в домике стоит юнит, юниту нужно знать, что то о юзере. Как это делается через ДИ (ну или мне так объясняли):

Так как написав простое:

Код AS3:
[Inject]
public var userModel:UserModel;
Мы не знаем, что нам скормят (того юзера которому принадлежит юнит, или нет). В силу этого мы делаем так:

Код AS3:
[Inject]
public var repository:Repository;
 
var userModel:UserModel = repository.getUserByUnit(this);
Трешачок, не правда ли?
Старый 30.09.2012 01:42 ramshteks вне форума
ramshteks
 
Аватар для ramshteks
я бы в ситуации с юнитом и домиком, лучше при создании самого юнита передавал бы ему "хозяина", или выставлял в какой то из моментов рантайма.

А Ваш пример, это пример из...а(ну вы поняли) использования фреймворка там где то и не нужно ИМХО конечно
Старый 30.09.2012 01:50 incvizitor вне форума
incvizitor
 
Аватар для incvizitor
Ну а если стоит дуб, под дубом ящик, в ящике заяц, в зайце утка, в утке яйцо, в яйце смерть кощея. А объект "смерть кощея" должен знать, о дубе. Так вот как бэ и "красота" ДИ в том, что оно помогает неявно прокидывать ссылки до определенного объекта. Или Вы предлагаете передавать ссылку через 10 объектов, лишь, что бы последний получил её? ДИ по ходу и существует, для того, что бы такого не происходило, но в классической её реализации явные недостатки.
Старый 30.09.2012 02:43 artcraft вне форума
artcraft
 
Аватар для artcraft
Цитата:
Допустим есть ситуация:
У пользователя есть домик, в домике стоит юнит, юниту нужно знать, что то о юзере. Как это делается через ДИ (ну или мне так объясняли):
при создании конкретного юнита ему нужно впрыснуть ссылку на конкретного пользователя, т.е. инжект должен зависеть от контекста, вуаля

Цитата:
Ну а если стоит дуб, под дубом ящик, в ящике заяц, в зайце утка, в утке яйцо, в яйце смерть кощея. А объект "смерть кощея" должен знать, о дубе.
но зачем смерти знать о дубе, неудачный пример.

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

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

например, в SwiftsuSpenders можно унаследоваться от DependencyProvider и поемстить туда логику связанную с контекстом
p.s. я не навязываю вам именно эту библиотеку, у неё есть свои недостатки, но я просто знаком с ней лучше чем с остальными
Старый 30.09.2012 03:10 wvxvw вне форума
wvxvw
 
Аватар для wvxvw
Я думаю, что меня больше всего в не устраивает методология ДИ. В том смысле, что код всегда пишется постепенно, и должен быть способ, как перейти от прототипа к готовому изделию. И желательно это сделать как можно безболезненнее. Например, компиляция в С: сначала имеет код обвешенный типами и инструкциями компилятора (своего рода прототип), и компилятор его механически превращает в код без всякой мишуры. При этом мы можем продолжать работать над "прототипом" и параллельно наблюдать как и во что он превратится.
Когда используют ДИ, то изза огромного количества служебного кода нужного для реализации возникает ситуация, когда переделывать уже сделанное совсем не хочется, а инструментов, которые бы это сделали механически - нет.
Кроме того, ДИ заставляет заранее принимать решения, которые, возможно, нельзя правильно оценить на текущий момент. Нужно попробовать, посмотреть как будет работать и скорее всего с первого раза работать не будет! Как правило тривиальный код работает у меня с раза 3-4-го, а нетривиальный может потребовать и 30-40 циклов на попытку-тест-переделку.
ДИ не позволяет разрабатывать код от маленького к большому: ну вот представте, если вы спланировали ваш класс домика так, что вам обязательно в нем нужна модель... пользователя? Ну трындец же, еще и всю модель сейчас писать... а может этот домик вообще не нужен?
Старый 30.09.2012 03:43 incvizitor вне форума
incvizitor
 
Аватар для incvizitor
Видимо, плохо я умею объяснять

Допустим у нас есть нейкий объект которому, нужна какая либо модель. Но протягивать ссылку очень долго (вообще я не вижу других мотивов использования ДИ). Если использовать ДИ, то можно получить нужную ссылку так:

Код AS3:
[Inject]
public var someModel:SomeModel;
Где гарантия того, что SomeModel которым проинжектают наш объект - это именно тот его инстанс, который нам нужен? А еще учитывая что продебажить процесс инжекта невозможно довольно трудоемко, то радости от такого подхода вообще мало.
Старый 30.09.2012 03:50 artcraft вне форума
artcraft
 
Аватар для artcraft
Цитата:
DI не позволяет разрабатывать код от маленького к большому
а чем разработка отдельных модулей, кирпичиков из которых можно собрать целое, это не разработка от частного к целому?

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

Цитата:
...огромного количества служебного кода...
Первое: не надо фанатизма, не надо рубить приложение в винегрет, достаточно распилить его на ограниченное количество максимально независимых модулей.
Второе: Простейший DI это совсем не много кода, просто вынести сборку конструктора в за пределы знаний деталей, не позволять кирпичиками самим решать что в конечном итоге получится.
Третье: Да спагетти код будет работать быстрее и его быстрее писать, но вот как раз когда понадобится расширять, особенно расширять в тех местах где этого не планировалось изначально, вот тут и будет видна выгода.

DI и Модульность тесно связанные вещи, ругая DI вы выступаете против модульности
Обновил(-а) artcraft 30.09.2012 в 05:58
Старый 30.09.2012 04:01 artcraft вне форума
artcraft
 
Аватар для artcraft
Цитата:
Где гарантия того, что SomeModel которым проинжектают наш объект - это именно тот его инстанс, который нам нужен? А еще учитывая что продебажить процесс инжекта невозможно довольно трудоемко, то радости от такого подхода вообще мало.
1. вы уверены что именно в этом месте вам нужен отделять модули друг от друга?
2. мне кажется вы так и не поняли что я говорил о инжекте зависящем от контекста (у меня возникает подозрение что возможно вы пользуетесь библиотекой которая не способна на такое... ) предоставлением нужной ссылки занимается некто находящийся вне модуля, тот кто собирает коструктор
3. Что именно мешает дебажить? Я не вижу никаких преград.
Обновил(-а) artcraft 30.09.2012 в 05:16
Старый 30.09.2012 04:11 incvizitor вне форума
incvizitor
 
Аватар для incvizitor
1. Я уверен, что в данном месте мне нужен SomeModel, так как мне нужны данные из него.
2. Вот это?
Цитата:
но суть в том что от изменения контекста изменяется то что будет впрыснуто
И как указать контекст?
3.
Код AS3:
[Inject]
public var someModel:SomeModel;
где брейкпоинт ставить?
Можно конечно и так:
Код AS3:
[Inject]
public function set someModel(value:SomeModel):void{
...
}
В таком случае найти баг возможно, но придется довольно долго гулять по стектрейсу.
Старый 30.09.2012 04:37 artcraft вне форума
artcraft
 
Аватар для artcraft
Цитата:
Я уверен, что в данном месте мне нужен SomeModel, так как мне нужны данные из него.
я понимаю, но вы уверены что SomeModel и тот объект должны быть разнесены в независимые модули, или они могут быть намертво спаянными частями одного модуля?
Цитата:
И как указать контекст?
контекстом занимается тот кто создаёт инстанс
Цитата:
Можно конечно и так
именно так
Цитата:
гулять по стектрейсу
меньшее из зол
Старый 30.09.2012 04:52 incvizitor вне форума
incvizitor
 
Аватар для incvizitor
1. В практике встречались оба случая.
2. Почитал твою статью об инверсии контроля. Да, в фреймворке, который я юзал, это было бы довольно геморно. Я так понимаю, оно протянет и все вышестоящие контексты?
3. Ну в swiz, это редко могло помочь, о SwiftSuspenders говорить не буду (не юзал).

Вообще такой подход как в SwiftSuspenders мне нравится больше, чес в swiz. Однако в сулчае SwiftSuspenders всплывает то, что говорит wvxvw - на практике придется писать много обслуживающего кода.
Старый 30.09.2012 05:12 artcraft вне форума
artcraft
 
Аватар для artcraft
я сейчас говорю не о конкретном DI фрэймворке а о инверсии контроля в принципе

Цитата:
Я так понимаю, оно протянет и все вышестоящие контексты?
всё зависит от того где вы захотите сделать "стыки", что вы решите выносить в отдельные модули а что нет

Цитата:
не юзал
а я не юзал swiz... у нас тут разговор слепого с глухим, но я повторю, я не про конкретную реализацию, я про принцип

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

Я против серебряных пуль, но я не согласен когда говорят что "полезное в некоторых ситуациях" - "вредно всегда"
Старый 30.09.2012 18:03 wvxvw вне форума
wvxvw
 
Аватар для wvxvw
Цитата:
а чем разработка отдельных модулей, кирпичиков из которых можно собрать целое, это не разработка от частного к целому?
Ну, так как раз это и не получится, т.как ДИ предполагает, что компоненты не самодостаточны, изначально, при создании компоненты нужно включать в нее "инжектнутый" другой объект, которы, мало того, что может еще не существовать, а вообще, по логике вещей должен писаться в последную очередь. В человеческом мышлении абстракция строится по принципу: есть много разрозненных примеров -> они анализируйтся -> находится в следствии сопоставлений и мутаций общая составляющая -> общая составляющая становится правилом для создания, или нахождения похожих элементов.
В редких случаях человеческое мышелние может работать от абстракции к конкретной реализации: например, человек может сначала выучить правила дорожного движения, а потом используя правила, научится водить машину. Но второй способ для человека трудный и не естесственный (к сожалению), да и на самом деле, не используется так в чистом виде никогда (все равно человек будет водить машину какое-то время под присмотром более опытного водителя).
Строить программу изначально расписывая абстракции (модель), и потом придумывать к этим абстракциям конкретные реализации - это все равно, что прочитать правила дорожного движения, и тут же сесть за руль...
Старый 30.09.2012 20:45 artcraft вне форума
artcraft
 
Аватар для artcraft
Цитата:
В человеческом мышлении абстракция строится по принципу
я не стал бы так однозначно насчёт человеческого мышления. На мой взгляд для понимания абстракции человеку удобно пользоваться метафорой. Если представить себе что модули в приложении это
1. кубики лего которые можно соединять
2. или кусочки пазла, которые можно сложить в картинку
3. или набор девайсов с разъёмами которые можно соединять проводами
то абстракции такого рода перестают пугать

Цитата:
Строить программу изначально расписывая абстракции (модель), и потом придумывать к этим абстракциям конкретные реализации
никто не обязывает делать именно в этом порядке
можно сперва собрать всё воедино, а потом делить на модули в тех местах где нужны стыки. Важно просто отдавать себе отчёт в том что отделено а что нет, и каким образом может быть реализовано разделение целого на части.

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



нужно уметь заметить первые признаки грядущей беды и начать пилить вовремя...
Старый 01.10.2012 20:59 incvizitor вне форума
incvizitor
 
Аватар для incvizitor
Мне всё же сложно понять, какое отношение имеет ДИ через контейнер к модульности.

Вариант 1:
Код AS3:
public function set engine(value:IEngine):void{
...
}
Вариант 2:
Код AS3:
[Inject]
public function set engine(value:IEngine):void{
...
}
По моему гибкость обоих вариантов идентична. В вариант номер 2 можно точно так же передать значение "вручную".

Разница скорее в кол-ве и качестве внешнего кода, который раздает ссылки. Ну и в том что ДИ через контейнер с рефлекшеном более автоматизированое, но менее дебагабельное (и в случае флеша не особо быстрое).
Старый 01.10.2012 21:56 artcraft вне форума
artcraft
 
Аватар для artcraft
Цитата:
Мне всё же сложно понять, какое отношение имеет ДИ через контейнер к модульности
к модульности отношение имеет инверсия контроля вцелом, а не исключительно IoC-контейнеры.

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

Цитата:
и в случае флеша не особо быстрое
вот это совсем не критично, несколько миллисекунд на инициализацию 5-20 модулей, один раз при запуске, мне лично совсем не жалко
Старый 01.10.2012 22:38 incvizitor вне форума
incvizitor
 
Аватар для incvizitor
artcraft, лично я понял что в статье критикуется ДИ через контейнер с фреймоворком, рефлексией и т.п. Об надобности инверсии контроля вопрос вроде бы как и не поднимался.

Цитата:
несколько миллисекунд на инициализацию 5-20 модулей
ну у меня Sprite гдето 4 мс дескрайб тайпится. Допустим мы загрузили внешнюю свф, в которой будет куча ДО которые нужно проинжектать - может и на секунду тормознуть. Ну это конечно не конец света, но все равно не приятно.
Старый 02.10.2012 00:36 artcraft вне форума
artcraft
 
Аватар для artcraft
В статье критикуется парслей вместе со встроенным в него инжектором. Конкретно по поводу парслея ничего не могу сказать.

Цитата:
Об надобности инверсии контроля вопрос вроде бы как и не поднимался.
Мне показалось что поднимался.

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

Я не согласен только с заявлениями о том что DI это плохо.

Я настаиваю на том что DI (не конкретные библиотеки, а как частный случай инверсии контроля) это хорошо, и что следует знать о нём и понимать, и использовать его без фанатизма.
Обновил(-а) artcraft 02.10.2012 в 00:54
Старый 02.10.2012 01:02 incvizitor вне форума
incvizitor
 
Аватар для incvizitor
Ну очень многие люди, в мире флеша, юзают фреймворки с ИоК контейнером во всех проектах, и пропагандируют его как излечение кода от всех болезней. Хотя на самом деле это может вести и к деградации кода. Допустим у есть объект - синглтон. Скорее всего к нему будут обращатся явно, он же глобальный ёпт . То же самое с ИоК контейнером, промапил - значит везде где нужно будем юзать.
Так и получается, что в коде менеджера какого ни будь действия мы встретим код типа:

Код AS3:
gameResourceManager.processTransaction(...);
Просто потому что инжектнуть можно - значит инжектнем и будем явно юзать. И похер, что можно было сделать

Код AS3:
var transaction:ICommand = gameResourceManager.generateTransaction(...);
//а внутри менеджера
successCommand.execute();
Если ссылку на что то получить легко - её будут получать, не смотря на то - нужна она вообще или нет.
Старый 02.10.2012 02:43 Котяра вне форума
Котяра
 
Аватар для Котяра
Цитата:
если ссылку на что то получить легко - её будут получать
А я не вижу в этом ничего плохого.
Если
Код AS3:
gameResourceManager.processTransaction
или вернее
Код AS3:
gameResourceManager
конфигурируемый на уровне application, то пусть.
У меня правило - инжектировать только контроллеры и-или классы к ним относящиеся (сервисы, команды, корректоры)
Модель - она всегда модель - просто VO c диспатчингом изменений.
Во вьюшки передаётся только модель. Инжектирование внутрь вьшки PM - пробовал - получается фигня какая-то.
Старый 02.10.2012 15:44 incvizitor вне форума
incvizitor
 
Аватар для incvizitor
Котяра, может быть уберем private, protected и internal? Что значит "конфигурируемый на уровне application"? Я так понимаю у тебя синглтонный сервис локатор, и ты через него всё забираешь?

А такой подход (с явным gameResourceManager) плох тем - что код не переиспользуешь даже в рамках проекта.
Старый 03.10.2012 07:06 artcraft вне форума
artcraft
 
Аватар для artcraft
я согласен с Котярой, прямой доступ это не так страшо как некоторым кажется, и мало того, гораздо лучше чем изворачиваться через события или команды, когда возможно просто взять и организовать "прямой доступ извне"

события нужны когда "один ко многим"
команды когда "многие к одному"
а когда "один на один" то прямой доступ (предоставленный извне) идеально
Старый 03.10.2012 07:16 artcraft вне форума
artcraft
 
Аватар для artcraft
никакой фрэймворк, из тех что мне попадались, не обеспечивает защиту от дурака, ближе всех был РureMVC он именно призван не давать делать иначе (правда, ценой лишней писанины), но я имел честь работать с пацанами которые взяли и допилили его так как им было удобно, чем нарушили всю идею, и свели всю чситстоту на ноль
Старый 03.10.2012 08:38 TanaTiX вне форума
TanaTiX
 
Аватар для TanaTiX
Цитата:
а когда "один на один" то прямой доступ (предоставленный извне) идеально
В случае глобального синглтона (наверное правильней выразиться "глобально доступного объекта") это явно не один на один.
Старый 03.10.2012 17:11 wvxvw вне форума
wvxvw
 
Аватар для wvxvw
По поводу пазла - очень хорошо в этом плане помогает осознать проблему попытка реализовать градиентнтый спуск (алгоритм). Для справки - алгоритм используется для формирования абстракции в ИИ. Это целая серия алгоритмов по оптимизации / вычленению полезной информации из собранных данных.
Так вот, к чему я его вспомнил: в тривиальной ситуации, когда входных параметров немного, ну до 2-3 (мы можем это смело называть свойствами класса, при условии, что эти свойства являются примитивами), то человек это еще как-то может себе представить. Но, в реальной жизненной ситуации, свойств гораздо больше. Уже даже 4 свойствa - чтобы представить себе взаимодействие объекта у которого есть 4 свойствa, с другими объектами нам нужно будет представить себе что-то вроде гипер-куба. (т.е. кубика существующего в четырех измерениях), когда счет идет на десятки - ни о каком пазле, или "рациональном" подходе по складыванию кусочков нет, да и быть не может речи. Мы бы затрачивали неимоверное количество времени на нахождение подходящих кусочков в многомерном пространстве.
Человек руководствуется интуицией когда создает такие многомерные системы, и нет особо никакого другого хорошего подхода, кроме как написал - проверил - исправил - проверил еще раз - и так пока не выявлено большинство ошибок. Конечно, не все так примитивно, и человек может запоминать шаблоны, по которым он мог бы воспроизвести те же действия, если в прошлом какая-то стратегия была удачной, и т.п. Но, по большому счету, принцип всегда один и тот же: попробовал-проверил-повторил.
Я вижу ДИ как попытку рационализировать там, где это технически не возможно. Своего рода попытку составить сценарий на случай встречи с инопланетянами, или, еще лучше - правила техники безопасности при передвижении со скоростью больше скорости света... ДИ не способствует (и может препядствовать) построению от маленького к большому, потому что предписывает определенную стратегию разработки, и заставляет сначала проектировать то, что нельзя хорошо спроектировать изначально. Нельзя придумать хорошую модель, пока на руках нет, как минимум 70% достоверных данных о том, как работают конкретные экземпяры, которые эта модель должна воплощать. 70 - это, конечно, цифра с потолка, но, опять же, если мы вернемся к изучению закономерностей, то для формирования приемлимой гипотизы на основании всех доступных фактов, нам, для первичного обучения нужно выделить около 2/3, а лучше - больше под обучаемое множество.
Если мы пойдем по пути: сначала выдвинуть гипотезу, а потом ее подтверждать - то, за исключением самых тривиальных ситуаций, мы практически гарантировано ошибемся.
Старый 03.10.2012 22:17 expl вне форума
expl
Если резюмировать:
- есть такое свойство системы: "Система, построенная с нуля, не может быть рабочей. Рабочая система строиться не с нуля, а на базе менее сложной рабочей" (это факт и спроить с этим сложно)
Отсюда вытекает итеративный принцип разработки с работоспособным кодом на каждом этапе
- IoC-фреймворк заставляет много делать сразу, препятствует итерациям (а вот тут объяснения не такие чёткие как хотелось бы - позиционируется фреймворк такого плана ведь, _наоборот_, как средство облегчения правок)
У меня более приземистые возражения против IoC-фреймворков.
Есть только одно чёткое соображение в пользу этого "высокого" тезиса:
использование этого рефлексивного чуда инженерии ослабляет проверку кода компилятором - а это прямо сказывается на надёжности рефакторинга - а это прямо осложняет итеративную разработку (работает? - не лезь, а то поотломаешь только рефакторингом своим)
Старый 03.10.2012 22:55 dimarik вне форума
dimarik
 
Аватар для dimarik
Олег, это ты мошно задвинул!

Я бы дополнил тем, что из всех программистов, решивших, что они овладели ООП, 70 процентов ошибаются в этом. 70% с потолка, естессна. Вероятно, я в большинстве )
Старый 05.10.2012 00:59 Котяра вне форума
Котяра
 
Аватар для Котяра
На самом деле статья называется - критика PM. А слезли на инжекты. Сама идеология PM - довольно удобна.
Тот же MVVM в шарпе - вид сбоку. Разница, по-сути, в том, кто кого содержит и порождает. В RobotLegs медиаторы - это PM, но они держат ссылку на вью, а не наоборот. Инверсируем и впрыскиваем во вью медиатор - получаем фаулеровский Presentation Model.
Старый 05.10.2012 09:26 Virtual Toy вне форума
Virtual Toy
 
Аватар для Virtual Toy
Ну, в начале сказано, что "попросили высказаться о pm и Parsley", так что инжекты в тему. А еще о том, что есть проблема бездумного копирования популярных или раскрученных идей. То, что попытались скопировать из джавы в экшнскрипт, да еще после этого использовать, получилось хреново, потому что кроме втыкания на клевые буквы IoC, DI, PM, SOLID, MVC и т.п. надо еще писать и поддерживать реальные проекты в реальном мире.
 

 


Часовой пояс GMT +4, время: 21:02.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.