Здравствуйте, GlebZ, Вы писали:
AVK>>А можно реальный пример на форумах? Сдается мне что вы боретесь с ветряными мельницами. GZ>Такой пример найти легко. Просто нужно сделать поиск по слову Фаулер в Архитектуре. Фаулер башку многим сносит, а разум и стремление к простоте отключает.
Здравствуйте, VladD2, Вы писали:
VD>В общем, разговор с тобой постоянно превращается в театр абсурда. Мне это надоело. Или отвечай на вопросы котоыре тебе задаются без подмены тем и подмены собственных суждени, или можно вообще не начинать обсуждения.
я чего-то не понял про подмену тем. Тему этой подветки начал я, ее же и продолжаю. Пока я вижу попытки сбить с темы меня путем передергивания.
VD>Итак. Попробую еще раз вернусться к обсуждению твоей фразы вызвавшей несогласие АВК (и мое): VD>знание паттернов [b]ничуть не помогает в разработке архитектуры[/b] VD>Хочу получить кратки и прямой ответ. Признашь ли ты эти слова ошибочными, или подверждаешь их правоту.
Таких настырных еще поискать. Диктую большими буквами последний раз.
И я не НЕ СОБИРАЮСЬ отказываться от своих слов, т.к. действитльно уже дважды подмечал эту ситуацию. И во всей этой ветке, вроде бы, раскрыл свое мнение уже достаточно подробно, от которого тоже не собираюсь отказываться: знание одних только паттернов не гарантирует грамотный дизайн. (про который упомянул ты, ибо вся началась подветка с моего ответа на твой пост, конкретно в нем — насчет упомянутых "знаний грамотного дизайна").
Когда AVK спросил "Аргументы?", я ему вкратце обрисовал маленький пример из виденного. Короче вот все сразу:
V>>>> Для библиотеки — это важно, да, это — самоцель. Для функциональных требований бизнес-системы — нет. Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
AVK>>>Аргументы?
V>>Другой уровень проектирования является аргументом? Например, какой смысл применять фасадные паттерны в тех местах, относительно которых требования к функциональности еще не устаканились. Это называется ставить телегу впереди лошади.
AVK>Как это доказывает то, что "знание паттернов ничуть не помогает в разработке архитектуры"?
Могу уточнить, если кто не понял из контекста. Я утверждал, что зазубрить список паттернов недостаточно для грамотного проектирования. Более того, наблюдал примеры "тупого" применения паттернов не к месту, что и озвучил. Так с чем именно ты не согласен?
По сути, точку надо было поставить еще тогда, но куда там
--------
Если и сейчас тебе чего-то покажется мало, или ты элементарно поленишься сходить по приведенным ссылкам, то участвовать в этом, как ты правильно подметил, абсурде, я не собираюсь. Похоже, у AVK паттерны — больной мозоль. Иначе с какой стати внаглую передергивать оппонента по интересующей теме.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>А уж логику дикарей предсказать не берусь. Может "плоская" вылезла из какой-то ловушки, и все ей подражать начали
то были не дикари, а вполне даже "цивилизованные" европейцы. точнее, испанцы, если мне не изменяет память
Здравствуйте, eao197, Вы писали:
E>У кого-то, может быть у того же Ефремова, я читал опровержение как раз тех фактов, которые ты приводишь ниже.
я предпочитаю верить тому, что говорят историки. А не тому, что говорят некие писатели неизвестного качества.
E>-- это не прижилось, поэтому можно считать это всего лишь тупиковой мутацией. Правилом, всего лишь подтверждающем исключения.
а что прижилось то? сначала была одна "мутация", потом другая, потом третья — а где тот общий для всех идеал красоты, о котором шла речь? его просто нет и никогда не было
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[5]: Готовность системы к её последующим изменениям
Здравствуйте, AndrewVK, Вы писали:
AVK>>>А можно реальный пример на форумах? Сдается мне что вы боретесь с ветряными мельницами. GZ>>Такой пример найти легко. Просто нужно сделать поиск по слову Фаулер в Архитектуре. Фаулер башку многим сносит, а разум и стремление к простоте отключает. AVK>Ну вот и найди
Вот люди, совсем совесть потеряли. Ему хотелось, а я ищи. Ну да ладно, я не гордый. Лови Mapper
Из жизни могу случаев рассказать. И в том числе про себя. Сейчас наблюдаю один проект с проблемой излишней и ненужной функциональнотью(слава богу со стороны).
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Готовность системы к её последующим изменениям
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, AndrewVK, Вы писали:
AVK>>>>А можно реальный пример на форумах? Сдается мне что вы боретесь с ветряными мельницами. GZ>>>Такой пример найти легко. Просто нужно сделать поиск по слову Фаулер в Архитектуре. Фаулер башку многим сносит, а разум и стремление к простоте отключает. AVK>>Ну вот и найди GZ>Вот люди, совсем совесть потеряли. Ему хотелось, а я ищи. Ну да ладно, я не гордый. Лови
Или вот такой вопрос очень впечатляет Какие преимущества SOA перед Domain model?
Здравствуйте, AndrewVK, Вы писали:
V>>Не надо выдирать фразы из контекста и все будет прекрасно стыковаться.
AVK>Не было там никакого контекста.
-1 за игнорирование контекста
V>> Могу в энный раз уточнить/переформулировать, мне не лень: знание одних лишь только паттернов не достаточно для успешного проектирования
AVK>А что, кто то утверждал обратное? Видишь ли, меня покоробило другое, как весело ты перешагнут от "некоторые (пип) паттерны применяют не по делу" к "паттерны не только бесполезны, но еще и вредны к тому же".
Я даже плохо представляю, есть ли смысл отвечать подобным постам. Ссылку в студию на мой пост с выделенными словами. И конкретно то место, которое тебя покоробило, ok?
AVK>А вот я как раз не знаю. Потому и спросил.
Да, а вот мне кажется, что я знаю, что такое "анализ",и применительно к ПО в т.ч.
V>>На отсутствие единого формального процесса я указал еще 2 поста назад (могу, кстати, подкинуть мысль, почему дело обстоит именно так, и заметь, не только в ОО-анализе). Однако, общая схема одинакова — анализ предметной области, построение оптимальной статической и динамической модели.
AVK>Тогда поясни как мне интерпретировать твою фразу. AVK>
Т.е. я порицаю практику попыток применения паттернов взамен "обычного" ОО-анализа.
AVK>Я так и не понял взамен чего нельзя применять паттерны.
Взамен "обычного" процесса разработки (мне больше всего импонирует нисходящий, неплохо описан в RUP и наших 19.xx ГОСТ-ах). Процесс разработки — вещь итерактивная, в общем случае. Чем сложнее система, тем больше итераций, возвратов и уточнений, т.к. с каждой итерацией уточняются требования, модель разбивается на все большее количество взаимодействующих моделей нижнего уровня. Полученную общую модель необходимо трассировать на работоспособность и удовлетворение всех собранных на текущую итерацию требований.
Конкретно, что мне не нравилось в виденом не однажды цирке под названием, "проектирование с паттернами". Это в первую очередь отсутствие итерации и обогащения требованиями. Т.е. слепили систему из паттернов "в лоб". В принципе, ничего страшного для начального этапа. В процессе уточнения модели и выхода на нижне уровни вполне могли быть найдены все несоответствия. Ан нет, ничего этого не было, сразу приступили к реализации. Почему то был сделан следущий вывод: "раз у нас все тут состоит из паттернов, то оно заведомо хорошо спроектировано". В результате, недавно ребята из соседней фирмы приходили за советами по разруливанию. У них же я и интересовался, как они докатились до такой жизни.
V>>Мне казалось, что я выразился предельно ясно, а тебе, очевидно, поразвлекаться захотелось.
AVK>Знаешь, если ты по прежнему будешь пытаться перелатывать свои слова и искать проблемы во мне, то не стоит продолжать, мне на это свое время жалко.
Я тебе уже указал на выдирание из контекста. Не приписывай мне того, что я не говорил. И тем более не собираюсь обосновывать не свои слова. По своим отвечаю ниже.
V>> Без достаточной проработки самой модели и всех ее уровней с функциональной т.з. и с т.з. всевозможных ограничений, бросаться в конкретику паттернов, ИМХО, рановато.
AVK>Модели чего, конкретного приложения? Гут. Тогда расскажи мне — коль скоро мы отказываемся от паттернов - в каких терминах мы эту модель будем описывать? Ввиде UML? Красивых пассов руками? Самопальных схемок? Еще как то?
И как с тобой разговаривать? Я специально оставил свой абзац с прошлого поста. Тебе говорят о своевременности, ты же приписываешь мне выделенное.
-1
V>> Тем более, что сами паттерны GoF как раз относятся к статической части модели,
AVK>Что такое статическая часть модели
это сразу в гугль
AVK>и почему GoF применимы только к этой части?
Потому как даже условие каждой задачи в той книжке зачастую ставится вполне конкретно, а на эту конкретику надо выйти.
Да блин, возьмем тот же визитор. Как стоит исходная задача? Перебрать полиморфный список и для каждого вызвать "собственный" метод? Да фиг там. В реальной жизни задача стоит так — есть несколько сущностей, над ними нужно совершать однотипные семантически действия, но тем не менее, отличающиеся для каждой сущности. На эту потребность надо выйти на некоторой итерации. Если удастья выделить отдельную роль для исполнителя этих действий и ограничить СИСТЕМУ ТИПОВ известными на момент, грубо говоря, компиляции. Если в результате предыдущих итераций проектирования выясниться, что все упомянутые сущности известны системе на момент разработки (т.е. никаких там динамически подгружаемых плагинов в этой части) то уже только тут и будет стоять эта задача. К тому же, двойная диспечеризация в классическом виде — это трюк, применимый не во всех ОО-языках. Попробуй сделать тоже самое на JavaScript.
V>> а не обогощать модель лишней/ненужной функциональностью,
AVK>Какая связь между паттернами и лишней/ненужной функциональностью?
Там еще я про искуственно вводимые ограничения сказал. На примере того же визитора, мы не сможем расширять систему используемых сущностей в виде плагинов. Это уже ограничение. Иногда очень болезненное.
V>> Можно много сказать об итеративности и возвратах в процессе анализа проектирования по мере уточнения и развития модели. Сами эти моменты крайне важны, т.к. очень часто решения раннего этапа проектирования могут вполне огранично подменяться на более поздних итерациях, зачастую упрощаться, "склеиваться", вычленяться похожие части и т.д.
AVK>Круто. Осталось понять какое к этому отношение имеют паттерны.
Такое, что применение паттерна в общем случае происходит как решение частной задачи. Например у нас стоит требование: есть много разновидностей документов со своими бизнес-операциями, документы должны иметь собственные наборы состояний, документы должны транзакционно переходить из состояния в состояние по одному или же группами (в случае, если в одной бизнес-операции участвует несколько документов). Какой паттерн применить? Пока что неясно какой и речь об этом идти не может. Нужно выбрать модель представления и взаимодействия документов, т.е. выйти на определенный уровень детализации. Нужно выйти на условия конкретных задач, и в качестве готового решения можно будет брать подходящие условию задач паттерны либо проектировать свои.
V>>А я лично наблюдал недавно процесс разработки примерно в таком духе: "Ну, тут мы прилепим это, здесь то, а вот в этом месте нечто эдакое, я тут новый ультрасовременный паттерн недавно в и-нете нарыл, очень хочу попользовать прямо здесь и сейчас".
AVK>И виноват в этом конечно паттерн.
Виноваты в этом люди, которые считают, что сам факт применения паттернов чего-то гарантирует. Ты вообще, оппонента внимательно читаешь? Все это время я выступал против бездумного применения паттернов взамен процесса проектирования. Никто и не утверждает, что сами по себе паттерны — зло. Так что пока ты споришь сам с собой.
AVK>Я тут недавно багу во 2 фреймворке нашел — уроды так удачно написали парсер TDS, что при селекте из таблицы с блобом и 4+ точками в имени этот самый парсер валится. Следуя аналогичной логике можно это привести в качестве аргумента к заявлению о том, что все парсеры вредны.
опять -1
Ты тратишь зря свое и мое время. Все уже прекрасно поняли, с чем именно ты споришь, но при чем тут моя ветка?
V>>И вообще, если охота более конкретно порассуждать о тонкостях ОО-проектирования, ты не стесняйся, высказывайся, только уж пожалуйста, немного более предметно, ok?
AVK>Не мужик, я пока ничего тут не проповедую. Это тебе нужно подтверждать свои слова про вредность паттернов нормальными аргументами, а не ссылками на гипотетических идиотов.
-1
Короче, мужик, ты окончательно увлекся.
Речь шла, вообще-то, о реальных мммм... (не могу назвать идиотами, в принципе, не глупые ребята) не очень опытных дизайнерах, которые наизусть знают паттерны и еще до недавнего времени свято верили, что этого достаточно. Всвязи с тем, что я наблюдал подобное уже не первый раз, я сделал замечание о тенденции.
Паттернами активно пользуюсь сам (собрался скоро выложить настраиваемый SQL-генератор в исходники эрэсдээна, визитор-визитором, бридж-бриджем, фасад-фасадом и прочее-прочим погоняет), так что, никак не могу сказать, что "все паттерны вредны" (C) AVK
AVK>Где это у меня ты выводы нашел. Я пока что вопросы задаю. На которые ты лепишь отмазки ввиде ссылок на гугль.
каков вопрос, таков ответ
-----------
короче, все что мог и хотел, я уже ответил тебе и Владу. Охота дальше развлекаться — плиз без меня.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не знаю. Я не представляю как нужно извратить логику, чтобы трактовать его собственные фразы так как предлагается. Имхо это просто нежелание признаться в неправоте даже в мелочах.
Я уже давно признал, что выразился более сжато, чем стоило. И потратил время на несколько постов потом, чтобы лично тебе и Владу развернуть свою мысль. Вот тут последние ответы по этой теме: http://www.rsdn.ru/Forum/Message.aspx?mid=1482077&only=1
Маленькая такая поправочка. Паттерны это не только паттерны дизайна(GoF). Паттерны могут быть ох как разными, и паттерны дизайна, не совсем, точнее всего, совсем не подходят под использование в архитектуре. Для этого случая, существуют свои паттерны.
Честно говоря структура разности между хотелками и действительностью значительно глубже и не зависит от паттернов. На основании собственных умозаключений можно наворотить значительно хуже и больше.
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Готовность системы к её последующим изменениям
Здравствуйте, GlebZ, Вы писали:
GZ>Такой пример найти легко. Просто нужно сделать поиск по слову Фаулер в Архитектуре. Фаулер башку многим сносит, а разум и стремление к простоте отключает.
По-моему, Фаулер как раз очень разумный человек. А если у кого от него бошку сносит, то пусть и не употребляет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>я все боялся озвучить эту мысль... но я имею более резкое мнение насчет изучения паттернов новичками. Не с них надо учиться проектировать, не с них. Поимев некий опыт самостоятельного нахождения решений, те, кто уже не новички, совсем по другому впитают эти паттерны, так сказать с гораздо большей пользой. Толку от того, что вместо условий задач студентам давать сразу ответы. Надо именно приучать самостоятельно решать задачи. А после приобретения некого опыта — давать наиболее часто встречающиеся случаи, чтобы в реальной практике не изобретать велосипеды, заодно снабдить терминологической базой.
Вообще-то паттерны как раз и даются как типовая задача. Задача с решением. Никто не мешает при изучении паттернов не показывать решение, а сподвигнуть учеников к самостоятельному поиску решения.
Однако же идея бросать новичков на произвол судбьбы и заставлять их проходить все на своем животе крайне порочна. Так как таким путем зания будут получаться значительно медленее и не факт, что в конечном итоге они вообще появятся. Это все равно как при обучении математики вместо чередования теории с практикой предлагать ученикам сразу решать сложные задачи. Конечно кто-то из них может их решит...
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Нет. Ты по моему несколько некорректно прочитал его сообщение. Он высказал мнение о практике применении паттернов а не об их общей полезности(в чем существует множество аспектов). Правда он сделал несколько сумбурно ограничившись только паттернами дизайна.
Объясни мне, плиз, что можно не корректно понять в этой фразе:
Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, AndrewVK, Вы писали:
AVK>>Не знаю. Я не представляю как нужно извратить логику, чтобы трактовать его собственные фразы так как предлагается. Имхо это просто нежелание признаться в неправоте даже в мелочах.
V>Я уже давно признал, что выразился более сжато, чем стоило. И потратил время на несколько постов потом, чтобы лично тебе и Владу развернуть свою мысль. Вот тут последние ответы по этой теме: V>http://www.rsdn.ru/Forum/Message.aspx?mid=1482077&only=1
Возможно ты в очередной раз выразился очень сжато. Но вот что я вижу в твоем "рзборе полетов":
Своя цитата:
Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
И следом фраза:
И я не НЕ СОБИРАЮСЬ отказываться от своих слов, т.к. действитльно уже дважды подмечал эту ситуацию.
Собственно с этим я и похоже АВК и не согласны. Обоснований этому мнению ты не привел. На мой взгяд это суждение крайне алогично и как верно заметил АВК является призывом к забивинию на паттерны начинающими. По карйней мере ее легко понять так. Все же остальные твои слова — это увретки и ужимки чтобы просто не сказать "да я так думаю" или "извините я не верно выразился".
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
VD>>Ты еще учти, что во многих случаях компиляторы просто инлайнят методы. Так же учти промахи мимо кэша. В реальном приложении и на CRect/RECT разница будет стримиться к нулю. Причем зачастую от ссылок на таких структурах ты проиграшь, так как промахи мимо кэша участятся. Ведь ты передашь параметр для использования. А значит компилятор породит код читающй уже содержимое структуры. Если она объявлена перед вызовом метода, то не беда, а если она лежит очень далего?
E>А если она передается через длинную цепочку вызовов методов?
Длинная это сколько? Да и опять таки не беда. Данные опять же будут в кэше.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Было сказано "относится к разряду практик". Или же он имеет под собой теоретическое обоснование?
Кстати, "практик" — это такой мужик который что-то делает на практике. А практика во множественном числе вроде как не бывает. Но и без этого я тоже что-то тебя не понял.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>В ветке про паттерны ты бросил явно неостоножное высказывание и вместо того чтобы просто признать ее ошибочность и согласиться с АВК начал изворачиваться. Заметь с IT никто не спорит. Так что если ты с ним согласен, то должен понять, что никто не говорит "чтобы проектировать хорошие программы достаточно знать паттерны". Но обратное высказывание (твое, о котором идет речь) так же абсурдно.
Не смеши, насчет неосторожного высказывания. Сдается мне, ты так и не посетил тот мой пост, а свое это умозаключение сделал из постов АВК.
, который ты для себя видимо посчитал точкой отсчета, состоит целиком из домысливаний и беседы с самим собой.
"паттерны не только бесполезны, но еще и вредны к тому же" ...
"Тогда расскажи мне — коль скоро мы отказываемся от паттернов" ...
"заявлению о том, что все парсеры вредны" ...
"тебе нужно подтверждать свои слова про вредность паттернов" ...
Короче, я так и не понял, с кем он там беседовал, и тем более не понял, как мне на все это отвечать, если эти фразы я первый раз у него в посте обнаружил. С какой радости ты так же требуешь от меня ответы на эти глупости — непонятно?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, eao197, Вы писали:
PD>Я вот подумал — чего это адепты .Net так нас убеждают, что передавать по сылке и по значению — это все равно.
Очередная победа добра над разумом. Где ты увидил, что какие-то "адепты" "вас" умеждают "что передавать по сылке и по значению — это все равно"? Зачем подменять чужие фразы и на этом делать далеко идущие выводы?
Тебе просто заметили, что передача небольших POD-типов, т.е. структур не имеющих сложных кострукторов и деструкторов по ссылке смысла не имеет. Более того, даже вредна, так как могут начаться проблемы третьего порядка (вроде промахов мимо кэша). Вот и все.
PD> У меня две идеи, взаимоисключающие , правда, есть.
PD>1. Они так и не поняли. что такое конструктор копирования и где он вызывается .
Ага. Тупые. С++ правда знают не хуже некоторых, но его религиозным духом не прониклись.
PD> В C#, Java и т.д. его же нет вообще.
Вот и задумайся на досуге почему это так. Я вот думал и пришел, к выводу, что этот отказ не случаен, т.е. — это осознанное архитектурное решение.
PD> Там то, что называется передачей по ссылке и по значению — в любом случае есть передача ссылки на объект, поскольку к самим объектам доступа нет.
Вообще-то на сегодны это не так. И передача по значению есть передача по значению. Но ты практически уловил одну из предпосылок архитекторов управляемых сред. Такое решение позволяет в будущем делать очень некислые оптимизации. Да и на сегодня оно позволяет, например, копировать содержимое массива аналогами memmove (что нельзя в общем случае делать с массивами С++-объектов). Другой предпосылкой было серьезное упращение семантики языков. Били и другие предпосылки, но это уже нужно отдельную статью писать.
PD> Вот если бы там от них потребовали при входе в функцию немедленно делать deep copy любого входного объекта — они бы иначе запели
Это может потребовать только прикладной алгоритм. И когда он того требует, то делается и глубокое копирование графа объектов. Например, в R# копирование AST-веток именно что глубокое. Иначе ветки разных AST начинают пересекаться, что недопустимо.
PD>2. Они все поняли, но заявляют это с далеко идущими целями. Вдруг кто-то из начинающих C++ программистов с ними согласится и начнет везде по значению передавать ? Тогда они смогут доказать без всякого труда, то, что им упорно хочется доказать — что С# быстрее, чем C++
Ага. Ну, прям заговор. А C# и так бысрее С++ если он в умелых руках, а С++ в руках начинающих или горе-оптимизаторов. Так что все ОК.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну если мы начнем двойки друг другу ставить — боюсь, давно уже друг друга бы отчислили PD>По существу — естественоо, я имел в виду классы, а не структуры.
Классы в дотнете и Яве невозможно передавать по значению.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В абсурд ударились вы оба. Короче, вот то самое сообщение http://www.rsdn.ru/Forum/Message.aspx?mid=1467257&only=1
(yes! yes! yes! he did it!!!)