Здравствуйте, vdimas, Вы писали:

V>Не надо выдирать фразы из контекста и все будет прекрасно стыковаться.

Не было там никакого контекста.

V> Могу в энный раз уточнить/переформулировать, мне не лень: знание одних лишь только паттернов не достаточно для успешного проектирования

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

AVK>>Т.е. что это такое ты не знаешь. Что и требовалось доказать.

V>А ты знаешь?

А вот я как раз не знаю. Потому и спросил.

V>На отсутствие единого формального процесса я указал еще 2 поста назад (могу, кстати, подкинуть мысль, почему дело обстоит именно так, и заметь, не только в ОО-анализе). Однако, общая схема одинакова — анализ предметной области, построение оптимальной статической и динамической модели.

Тогда поясни как мне интерпретировать твою фразу.

Т.е. я порицаю практику попыток применения паттернов взамен "обычного" ОО-анализа.

Я так и не понял взамен чего нельзя применять паттерны.

V>Мне казалось, что я выразился предельно ясно, а тебе, очевидно, поразвлекаться захотелось.

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

V> Без достаточной проработки самой модели и всех ее уровней с функциональной т.з. и с т.з. всевозможных ограничений, бросаться в конкретику паттернов, ИМХО, рановато.

Модели чего, конкретного приложения? Гут. Тогда расскажи мне — коль скоро мы отказываемся от паттернов — в каких терминах мы эту модель будем описывать? Ввиде UML? Красивых пассов руками? Самопальных схемок? Еще как то?

V> Тем более, что сами паттерны GoF как раз относятся к статической части модели,

Что такое статическая часть модели и почему GoF применимы только к этой части?

V>Применение паттернов должно являться СЛЕДСТВИЕМ анализа (или, учитывая итеративность, можно уточнить так: следствием очередной итерации анализа),

Какого анализа? Этого самого "обычного ОО-анализа"? Тогда, пока я не услышу от тебя, что ты под ним понимаешь, смысл этой фразы мне будет непонятен.

V> а не обогощать модель лишней/ненужной функциональностью,

Какая связь между паттернами и лишней/ненужной функциональностью?

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

Очень интересно. Можно пример?

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

Круто. Осталось понять какое к этому отношение имеют паттерны.

V>А я лично наблюдал недавно процесс разработки примерно в таком духе: "Ну, тут мы прилепим это, здесь то, а вот в этом месте нечто эдакое, я тут новый ультрасовременный паттерн недавно в и-нете нарыл, очень хочу попользовать прямо здесь и сейчас".

И виноват в этом конечно паттерн.
Я тут недавно багу во 2 фреймворке нашел — уроды так удачно написали парсер TDS, что при селекте из таблицы с блобом и 4+ точками в имени этот самый парсер валится. Следуя аналогичной логике можно это привести в качестве аргумента к заявлению о том, что все парсеры вредны.

V>И вообще, если охота более конкретно порассуждать о тонкостях ОО-проектирования, ты не стесняйся, высказывайся, только уж пожалуйста, немного более предметно, ok?

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

V> А то разговор с тобой какой-то односторонний получается. И что не вывод у тебя — так пальцем в небо

Где это у меня ты выводы нашел. Я пока что вопросы задаю. На которые ты лепишь отмазки ввиде ссылок на гугль.

Здравствуйте, GlebZ, Вы писали:

GZ>А по мне существует только один паттерн который называется Low Coupling/High Cohesion.

Это не паттерн, это оценочный критерий. Паттерн это конкретное архитектурное решение.

Здравствуйте, AndrewVK, Вы писали:

GZ>>А по мне существует только один паттерн который называется Low Coupling/High Cohesion.

AVK>Это не паттерн, это оценочный критерий.
Многие с тобой не согласятся. Насколько я помню в GRASP это было описано как паттерн(или как два паттерна). Ну или вот wikipedia. А то что метрики ОО систем построены в том числе на измерении этих параметров, то это отношения не имеет. Просто увеличивает ценность.
AVK>Паттерн это конкретное архитектурное решение.
Не-а. И "конкретное" не всегда. И "архитектурное" тоже. Паттерн — это некоторое приблизительное решение описанное в некотором формализованном виде.

С уважением, Gleb.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>"Не красивые самолёты не летают". Красота это, в первую очередь, мерило функциональности.

птеродактили вот тоже летали, хотя с виду — сущие уродцы
или твое правило относится только к самолетам?

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

как ловко ты перешел от "функциональности" к "скорости работы". А ничего, что это понятия абсолютно ортогональные?

Здравствуйте, FR, Вы писали:

FR>Во вторых среднее время жизни игровых приставок пять лет, и все эти пять лет более мощного оборудования просто не будет.(Хотя для приставок игра не прошедшая требования по быстродействию просто не будет издана).

на приставках свет клином не сошелся

Здравствуйте, eugen1001, Вы писали:

E>Выводов два:
E>1. В каждом отдельном случае нужно отдельно изучать ситуацию, по возможности точно контролировать в какой момент времени и почему тормозит.
E>В нашем случае показано, что бывают ситуации, когда работа по одному байту или блоками особой роли не играет, а бывает, когда очень даже играет.

E>2. Прежде, чем что-то оптимизировать, да еще с серьезными переделками, нужно провести оценку: соизмерим ли ожидаемый выйгрыш по времени с затратами на оптимизацию.

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

ЗЫ

Разжевывание :

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

И вот, как раз, заявления вроде того, что "запись в файл по байтно тормоза и вообще лам" — как раз и является таким вот предположением, а следствием, зачастую, является как раз угроханный код с пятидесятипроцентной вероятностью того, что толк от оптимизации или отсутствует вообще, или мизерный. Обратное предположение тоже не верно. Но разумно предполагать по умолчанию, что библиотеки написаны более менее оптимально. Ведь на не делание оптимизации усилий обычно не тратится. Да и ее никогда не поздно сделать. Ну, и естественно это не может повредить качеству кода. А вот на деланье...

Простой пример. В дотнете файловые потоки кэшируют вод/вывод и единственное что можно выиграть от записи большими блоками — это избавиться от виртуальных и иных вызовов. Это конечно может дать выигрыш если файл уже читается из кэша ОС (иначе заметить что-то на фоне обращения к физическим дискам просто невозможно), но выигрыш будет в два раза максимум и на фоне других операций с данными будет попросту незаметен. Зато блочное чтение может значительно ухудшить код. Создание же промежуточной абстракции скорее всего обойдется не дешево (с точки зрения трудозатрат), и мало что даст.

Ну, и последнее. Скорость понятие относительное. Одна и та же операция может оказаться дико медленной в одних условиях и незаметной в другой. Зависит все от двух факторов:
1. Объема сопутствующей нагрузки. Например, глупо оптимизировать проверки в for-ах занимающие микросекунды если внутри них идет обращение к БД занимающие от миллисекунд, до секунд.
2. Объема вычислений. Ведь вряд ли что-то даст оптимизация чтения 10 байт.

У меня вот недавно был замечательный случай. Вызов функции SelectObject(hFont) практически ничего не стоила при отрисовке (как для самой отрисовки, так и для расчета размеров строк), но становилась узким местом при расчете переносов строк (для расчета их длинны) в больших текстовых файлах. Понятно, что если бы у меня не стояло второй задачи, то оптимизация в этой области была бы глупостью и вредительством, но при наличии второй задачи она уже более чем оправданна, ведь скорость считывания закэшированных файлов, при этом, возрастает в 3 раза.

Здравствуйте, vdimas, Вы писали:

V>А вот он и камень преткновения. Многие тут говорили о том, что даже эти банальные правила зачастую не соблюдаются при кодировании. Процесс переписывания подобных участков кода "потом", ИМХО, является оптимизацией. Но она из разряда "ее могло и не быть".

Возможно, но тогда спор терминалогический.

V>Мне, например, не хватает что-то типа оператора with из VB. Приходится ручками заводить локальные переменные. Если кому-то это делать лень, то в случае нетривиального кода свойств можно получить серьезные тормоза на ровном месте. И таких примеров предостаточно.

А это очередной пример предположенческой оптимизации. И вообще, такие вещи должен оптимизировать компилятор.

Да и with от "ручками заводить локальные переменные" мало чем отличается. Разве что на одну строчку короче.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Cyberax, Вы писали:

C>>Кстати о птичках. Мы тестировали что эффективнее передавать — ссылку на
C>>CSize (те же 8 байт) или сам CSize по значению. Оказалось, что разницы
C>>нет. Точнее, на одних процессорах (Intel Pentium M) был быстрее
C>>указатель, а на других (AMD не-помню-какой) было выгодно передавать по
C>>значению.

E>А CRect?

Ты еще учти, что во многих случаях компиляторы просто инлайнят методы. Так же учти промахи мимо кэша. В реальном приложении и на CRect/RECT разница будет стримиться к нулю. Причем зачастую от ссылок на таких структурах ты проиграшь, так как промахи мимо кэша участятся. Ведь ты передашь параметр для использования. А значит компилятор породит код читающй уже содержимое структуры. Если она объявлена перед вызовом метода, то не беда, а если она лежит очень далего?

Здравствуйте, vdimas, Вы писали:

Поясную свою оценку...

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

Читая это мне почему-то постоянно приходил на ум один анекдот:

В курилке одной конторы:
— Наш начальниг полного говно!
Вдруг входит тот самый начальник...
— Ну, я в хорошем смысле этого слова.

Здравствуйте, vdimas, Вы писали:

V>Без достаточной проработки самой модели и всех ее уровней с функциональной т.з. и с т.з. всевозможных ограничений, бросаться в конкретику паттернов, ИМХО, рановато.

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

Здравствуйте, VladD2, Вы писали:

VD>Ты еще учти, что во многих случаях компиляторы просто инлайнят методы. Так же учти промахи мимо кэша. В реальном приложении и на CRect/RECT разница будет стримиться к нулю. Причем зачастую от ссылок на таких структурах ты проиграшь, так как промахи мимо кэша участятся. Ведь ты передашь параметр для использования. А значит компилятор породит код читающй уже содержимое структуры. Если она объявлена перед вызовом метода, то не беда, а если она лежит очень далего?

А если она передается через длинную цепочку вызовов методов?

Здравствуйте, AndrewVK, Вы писали:

AVK>Т.е. что это такое ты не знаешь. Что и требовалось доказать.

Интересно, а какой смысл вести дискуссию цель которой доказать, что твой собеседник чего-то там не знает? Какая в этом польза для сообщества?

Здравствуйте, Дарней, Вы писали:

ANS>>"Не красивые самолёты не летают". Красота это, в первую очередь, мерило функциональности.

Д>птеродактили вот тоже летали, хотя с виду — сущие уродцы

а что, есть абсолютная уверенность, что они летали?

Д>или твое правило относится только к самолетам?

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

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

Д>как ловко ты перешел от "функциональности" к "скорости работы". А ничего, что это понятия абсолютно ортогональные?

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

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Pavel Dvorkin, Вы писали:

GZ>Тут ошибочка у вас Павел вышла. Сам недавно на такое наткнулся. В этом случае Петцольд был прав. Зря студент пострадал.
GZ>Начиная с Пентиумов шина 64 битная. То есть за раз, она забирает 8 байт. И не меньше. В результате если значение не в массиве, то разницы между 4 байтами и 8 байтами нет.

Вполне возможно. Кстати, студент вовсе не пострадал
Еще раз — не в POINT дело. Его вполне можно и по значению передать. Дело в принципе — незачем большие структуры по значению передавать.

Здравствуйте, eugals, Вы писали:

E>В том-то и дело, что в приведенном мною примере разница есть. Передача по значению оказалась эффективнее.
E>И таких примеров тысячи.

Неужели ?

В конце концов, sizeof(double) тоже > sizeof(void *), но вряд ли будет разумно и его везде по ссылке передавать. ТщательнЕЕ надо...

+1.

Здравствуйте, eao197, Вы писали:

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

1. Они так и не поняли. что такое конструктор копирования и где он вызывается . В C#, Java и т.д. его же нет вообще. Там то, что называется передачей по ссылке и по значению — в любом случае есть передача ссылки на объект, поскольку к самим объектам доступа нет. Вот если бы там от них потребовали при входе в функцию немедленно делать deep copy любого входного объекта — они бы иначе запели

2. Они все поняли, но заявляют это с далеко идущими целями. Вдруг кто-то из начинающих C++ программистов с ними согласится и начнет везде по значению передавать ? Тогда они смогут доказать без всякого труда, то, что им упорно хочется доказать — что С# быстрее, чем C++

Если второе верно — не дождетесь ! Мы на страже и этот номер не пройдет

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>См. выше. Я просто не смог сходу подобрать более лучшего слова чем "функциональность". Читай "интегральная оценка". А проблема в том, что довольно часто можно видеть высказывание типа "я написал красиво, а потом занялся оптимизацией и программа стала уродцем".

Вот, кстати пример

Автор: Sinclair
Дата: 10.11.05

:

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

То есть, система как-бы плохая, но читаем дальше:

Зато внутри у него все круче, чем у БМВ под капотом.

Внимание вопрос, как бы автор поста писал подобную систему, если он считает, что внутри всё круче, чем варенные яйца?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD> Там то, что называется передачей по ссылке и по значению — в любом случае есть передача ссылки на объект, поскольку к самим объектам доступа нет.
Опять двойка. Читать про value-типы.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Внимание вопрос, как бы автор поста писал подобную систему, если он считает, что внутри всё круче, чем варенные яйца?

Не знаю

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

Конечно, как два путника, вышедших друг другу навстречу из пунктов A и B, они непременно встретятся. Если будут идти достаточно упорно.
А если не будут, то одни останутся со всеобъемлющей, но абсолютно бесполезной платформой, а другие — с нерасширяемым негибким решением некоторого подмножества требований пользователя. Потому как у первых не хватит терпения дописать нужные плагины, а у вторых — не хватит сил добавлять фичи.

Обе среды — и Idea и Eclipse — зашли достаточно далеко по своим путям, чтобы их можно было считать успешными. Тем не менее, недостатки в них вполне логично следуют из различия подходов. К моменту, когда они все же встретятся, различия сотрутся.

Sinclair,

PD>> Там то, что называется передачей по ссылке и по значению — в любом случае есть передача ссылки на объект, поскольку к самим объектам доступа нет.
S>Опять двойка. Читать про value-типы.

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

Значение value-типа можно назвать "объектом" лишь натянув понятие "объект" на них.

int x = 10;
x.???(???); // где у "x" поведение?