Здравствуйте, FDSC, Вы писали:
FDS>Когда классы объединяются в иерархию всегда выбирается такая точка зрения, с которой различия приводятся к "похожестям", иначе что же это за иерархия?
Вот примеры иерархий, сделанные опытными программистами, где различия не устранены (== выбрана неверная точка зрения):
Пример 3
FDS>Вот-вот. Поэтому я и говорю, что ваши советы абстрактны. Не рассмотрены вот эти самые варианты "для чего" и соотв. объединения. Не рассмотрено как раз то, что вызывает трудности. Не рассмотрены конкретные советы КАК объединять, а общий совет обычно или очевиден, или настолько закопан, что о нём никто не вспомнит. FDS>Т.е. практическую ценность ваш совет бы обрёл, когда вы бы посоветовали на нескольких сложных примерах, как выделять общее зерно классов, а ещё лучше, дали бы какой-то алгоритм, структуру, по которой это можно было бы делать формально.
На мой взгляд, конкретный совет дан. Нужно не рассуждать о том, как объединить разнородные объекты и свести их к единому интерфейсу, а следует нелениво написать:
"Объект такой-то я получаю для того, чтобы сделать с ним то-то". И описать, как это действие предполагается выполнять.
"Объект другой я получаю для того, чтобы сделать с ним другое действие". И описать, как будет выполняться и это действие.
И т.д. — до тех пор, пока так не будут описаны все разнородные объекты, которые нужно сгруппировать.
После этого решение проявится само собой.
Если действия над объектами будут разными, то, вполне вероятно, что и группировать объекты будет не надо. Если же действия будут одинаковые, то общее в объектах Вы сможете найти. Но в том-то и дело, что нам не нужно общее ради общности. А нужно общее только в рамках некоторого действия. Поэтому ключ для группировки — это нахождение общего действия.
По-моему, звучит вполне конкретно.
КЛ>>Об учете сущности информации говорится здесь, здесь и голосом .
FDS>Об этом там не говорится. Там не говорится, что делать, если не получается сгруппировать все обратные связи в однотипный массив. Там даже не говорится, по какой формуле вы сами обрабатываете информацию, как учитываете различия в семантике получаемых вещественных значений. Куда они затем идут.
В том-то и дело, что получается. Это потому, что я смотрю на разнородные объекты с точки зрения действия, которое собираюсь далее над ними выполнять. А правилу:
"Если у тебя этого мало, то предпочти этот power-up" —
на самом деле безразлично, что это за вес — количество набранных очков, процент здоровья или нечто другое.
FDS>Вы даже не показали ваше решение полно. Я его искал, но даже в конце, на страницах "Выбор направления движения" ничего не сказано о том, как вы обрабатываете разнотипную инфомацию. Такое впечатление что это очень очевидно и легко, хотя это не так, если задача хоть чуть-чуть сложная.
У меня в презентации не было задачи рассказывать о решении целиком. Сведя различные параметры к весам, я дальше работаю с ними, как с весами. Точно так же я работаю и с объектами на трассе (как с некоторыми объектами, имеющими свой центр, радиус и тип в виде флага). В том-то и дело, что коду AI не нужны различия между ними. Он выбирает тот объект, который набирает нужный вес. А вес рассчитывается, исходя из полезности или вредности данного объекта в данный момент. А данный момент характеризуется значениями таких параметров, как количество набранных очков и здоровье.
Но поверьте, что это сходство между разными объектами видится уже после того, как задача решена. Когда же к решению этой задачи только-только приступали, все эти объекты — автомобили, power-up'ы и мины казались разнородными.
КЛ>>Было 2 иерархии. Осталось 2 класса. Что непонятного?
FDS>Вот именно. Здесь у вас осталось два класса, а вот тут http://www.triz-ri.ru/themes/kri_2007_lebedev-30.asp# у вас снова появилась иерархия, просто с дополнительным абстрактным слоем. Т.е. 27-ой слайд неправильно показывает сущность свёртки как внесения абстрактного слоя. Ничего мы в те два класса не выносим, мы только делаем этими двумя классами новый интерфейс.
30-й слайд показывает ситуацию после свертывания на уровне интерфейсов. Т.е. интерфейсы оказываются одинаковыми, а реализации — разными. Соответственно, когда мы вводим общий интерфейс, то и появляется промежуточный слой. Далее происходит свертывание на уровне реализаций, слои схлопываются, множество реализаций заменяется одной реализацией. Это и продемонстрировано на слайде 35.
Просто Вам показана картина в развитии.
КЛ>>Почему такая же? Сверху изображена иерархия классов. Снизу — один класс. К тому же, он имеет другое название. И не помечен, как абстрактный. А интерфейс у него и не должен был поменяться, т.к. изменения происходят на уровне реализации. Интерфейс-то остается тем же.
FDS>Вот и возникает вопрос, как это согласуется с 30-ым слайдом. Реализацию-то вы оставили в тех классах, которые были, вы же её не впихнули в один класс. А если впихнули, то: 1. 30-ый слайд неправилен,
Реализацию я поместил в один класс, который раньше был базовым. Но 30-й слайд тоже правильный. После слайда 27 идет небольшое методическое отступление, которое подводит итоги нескольких предыдущих слайдов. В этом отступлении говорится об этапах свертывания (на уровне интерфейсов, на уровне реализаций) и о том, что различия нужно продвигать вниз. Для иллюстрации этой мысли приводится пример из слайда 25. Т.е. для того, чтобы произвести свертывание на уровне реализаций, надо сначала продвинуть различия вниз.
FDS>2. каким образом это приводит к уменьшению сложности непонятно, ведь этот класс должен включать все методы классов, которые он заменил, т.е. нужно расписать, что вы сделали с этими классами
Как я уже упоминал в другом сообщении, сложность устраняется на уровне какого-то слоя. В данном примере, 4 класса заменяются одним, а массив "датчиков" и вовсе удаляется. Это продемонстрировано на слайде 44.
FDS>Но, как же всё-таки быть, когда мне нужно в алгоритме учесть разнородные параметры. Скажем, мне нужно обработать не только целевые факторы, но и возможность их достижения, которая описывается, скажем, массивом матриц 4х4? Что мне делать, если у меня появится ещё одна группа параметров, но это будет уже, скажем, массив матриц 3х3 или, скажем, массив массивов? Как мне объединить эти группы разнородных параметров в один?
Для этого и нужно конкретизировать:
1) В массиве матриц 4 на 4 содержатся параметры, которые характеризуют... Я их далее использую для того-то и того-то. Делаю я это так-то и так-то.
2) В массиве матриц 3 на 3 содержатся параметры, которые характеризуют... Я их далее использую для того-то и того-то. Делаю я это так-то и так-то.
В отсутствии конкретной задачи унификация разнородных объектов невозможна.
FDS>Мммм. Ну, значит, такие вопросы там задают студенты первого курса . FDS>Тут тоже вопрос, для каких людей вы писали эту презентацию. Если для студентов, тогда ладно. Причём для довольно слабых студентов.
Мне непонятна Ваша ирония? Какую задачу Вы решаете? Действительно разобраться в материале, который Вам непонятен? Или самоутвердиться за счет обсмеивания работы собеседника? Последняя задача подходит скорее для прыщавого подростка, но не для инженера с опытом работы.
Что касается Вашего утверждения, будто серьезные ошибки при проектировании делают только студенты, то это не так. Выше я уже привел примеры ошибок, совершенных опытными программистами.
Дак что в итоге. В итоге вы начали мне приводить методику того, КАК нужно выявлять схожесть объектов. Однако в своей презентации вы этого не сделали. А ведь вы понимаете, что ошибки-то именно на этом участке.
Если вы действительно чего-то добились, дак и рассказывайте о том, чего вы добились. А то получается, может вы супер классный архитектор, но я не могу понять, КАК вы это делаете. Такие вещи показываются не на одном примере, а на многих примерах. Вы выбрали сразу неправильный подход к подаче материала.
Пример, всё-таки, сам не такой уж и сложный.
Короче говоря, вы не рассказали КАК надо делать то, что вы сделали, вы привели только 1 (один) несложный пример того, что вы сделали лично.
Т.е. моя претензия остаётся в силе, вы не даёте той информации, которая действительно нужна. Вы её затушёвываете. Из-за этого и все обвинения в абстрактности. Нужно это давать сухо и строго. Или наоборот, на многих примерах, эмоционально и убедительно. Но не на одном
Re[9]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, VladD2, Вы писали:
КЛ>>>Я же предлагаю ориентироваться не на объекты, а на действия. И проектировать структуры данных, модули под эти действия. Т.е. операция, функция (пользовательская) — первична, а объект — вторичен.
V>>Поздравляю, вы открыли для себя структурное программирование
VD>Ну, или почти открыл функциональное .
Нет, функциональное тут не при чём. Функциональное программирование использует модель т.н. функциональных преобразователей "без пямяти", в то время как структурный подход не накладывает это ограничение.
Re[10]: О наследовании, иерархиях и проектировании (философс
Здравствуйте, vdimas, Вы писали:
V>Нет, функциональное тут не при чём. Функциональное программирование использует модель т.н. функциональных преобразователей "без пямяти", в то время как структурный подход не накладывает это ограничение.
Принцип декомпозиции один и тот же.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: О наследовании, иерархиях и проектировании (философс
Здравствуйте, VladD2, Вы писали:
V>>Нет, функциональное тут не при чём. Функциональное программирование использует модель т.н. функциональных преобразователей "без пямяти", в то время как структурный подход не накладывает это ограничение.
VD>Принцип декомпозиции один и тот же.
Ну, в ФП одним из критериев является "чистота" ф-ий (без побочных эффектов), а в структурном критерий декомпозиции заключается лишь в самом факте декомпозиции: разбиении сложных модулей (участков) на простые. Соответственно и результат может быть разным. В структурных программах почти всегда есть состояние. Классика структурного подхода, это следующая последовательность действий:
— анализ предметной области
— разработка основных структур данных
— разработка алгоритмов по обработке этих данных.
А ООП-декомпозиция в первую очередь декомпозирует... тоже данные (ха-ха, именно), рассматривая их в виде хранилища пространства состояний для вводимых абстрактных сущностей (моделей). Т.е., мы вводим понятие "сущности", наделяем её состояниями и поведением... По законам автоматики, внешнего наблюдателя не должно интересовать конкретная реализация состояний функционального преобразователя с памятью (автомата), т.е. внешнему наблюдателю не важен внутренний способ кодирования состояний, интересует лишь последовательность выходных сигналов в ответ на последовательность внешних сигналов (раздражителей), из этого принципа весьма естественно выходит инкапсуляция, ведь объект в ООП — это классический автомат.
Почему я собственно влез — мне ООП всегда казалось очень близким именно к структурному программированию по принципу работы, да и хорошо продумманные структурные программы уж очень идеологически на ООП смахивали, но никак не на ФП. Обычная структурная программа и ООП-программа — это цифровые автоматы, в то время как ФП-программы удачнее всего будет сравнить с аналоговыми схемами без памяти.
Re[12]: О наследовании, иерархиях и проектировании (философс
Здравствуйте, vdimas, Вы писали:
V>Почему я собственно влез — мне ООП всегда казалось очень близким именно к структурному программированию по принципу работы, да и хорошо продумманные структурные программы уж очень идеологически на ООП смахивали, но никак не на ФП. Обычная структурная программа и ООП-программа — это цифровые автоматы, в то время как ФП-программы удачнее всего будет сравнить с аналоговыми схемами без памяти.
Структурное программирование — это разбиение задачи на части, которые удобны. Некторые задачи удобно разбивать на объекты, некоторые — на функции.
В данном случае, всё-таки, если действия были первичны, то это всё-таки ближе к ФП
Re: О наследовании, иерархиях и проектировании (философское)
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Ответу на этот вопрос и посвящена презентация «Проектирование игровых и бизнес-программ. Разработка архитектуры, устойчивой к изменениям», которая была показана на Конференции разработчиков игр 2007. В презентации демонстрируется, что понятие «идеальная программа» существует и в программировании, и что это понятие можно успешно использовать для решения задач проектирования.
Просмотрел. Кратко мнение:
Что хорошо — это то, что вы понимаете, что сценарии применения (вы их называете "полезными функциями", в литературе же они проходят как use cases, user stories, и пр.) являются центральным аспектом при разработке и верификации дизайна системы. Это делает ваш подход в целом рабочим — на самом деле, многие не понимают важности анализа сценариев и городят. Это отличная, и правильная догадка. Единственно — полезные функции далеко не всегда ограничиватся границами модулей, как предполагается у вас.
Что плохо — этим все и ограничивается. Вы не рассказали ни о процессе разработки дизайна (изложенное — довольно наивный подход, так студенты систему проектируют — правильно eao197 написал), ни о правилах верификации дизайна, ни об общих ООП правилах — design guidelines. Упомянуты "слоеные"системы — однако не указаны элементарные правила, которые не надо нарушать при их конструировании.
Список литературы, который вы приводите, тоже не впечатляет. Паттерны не имеют отношения к проектированию — не думают проектировщики паттернами, патерны не более чем отходы их жизнедеятельности. Гради Буч — написал научно-популярную книжку об ООП, которая рассказывает что это такое, но не дает ответа на вопросы "как". В списке — ни одной ссылки на книги по технике работы с требованиями, также отсутствуют ссылки на книги по процессам проектирования и анализа. Списк литературы очень показателен — он наглядно характеризует источники и жизненный опыт автора. Добавили бы вы в список литературы Rumbaugh, Jordan или Jacobson, прочитав их литературу — глядишь и презентация выглядела бы по другому .
Но это по большому счету мелочи (как и притянутый за уши ТРИЗ, которому посвящается много времени). Главная мысль — про полезные функции, и эта мысль в целом полезна. Комментировать по деталям — не вижу смысла. В качестве чтения — какая-нибудь основополагающая книга по RUP для начала, и вы сами измените свою презенацию.
Re[2]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, Gaperton, Вы писали:
G> Паттерны не имеют отношения к проектированию — не думают проектировщики паттернами, патерны не более чем отходы их жизнедеятельности.
Лучшего определения патернов я в жизни не слышал !!!!
Патерны проектирования — отход жизнедеятельности архитекторов, респект однако !!!!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, Gaperton, Вы писали:
G>Что хорошо — это то, что вы понимаете, что сценарии применения (вы их называете "полезными функциями", в литературе же они проходят как use cases, user stories, и пр.) являются центральным аспектом при разработке и верификации дизайна системы.
Вероятно, Вы имеете в виду пользовательские, а не "полезные" функции. И еще одно: пользовательская функция != use case (дословно — сценарий использования). Сценарий — это все-таки сценарий.
G>Это делает ваш подход в целом рабочим — на самом деле, многие не понимают важности анализа сценариев и городят. Это отличная, и правильная догадка. Единственно — полезные функции далеко не всегда ограничиватся границами модулей, как предполагается у вас.
Чего-то я не помню у себя подобного утверждения.
G>Что плохо — этим все и ограничивается. Вы не рассказали ни о процессе разработки дизайна (изложенное — довольно наивный подход, так студенты систему проектируют — правильно eao197 написал), ни о правилах верификации дизайна,
Давайте не сравнивать реальную работу (в данном случае я пишу о презентации) с некоторым идеалом, который Вам хочется увидеть да еще и сразу. Давайте сравним с аналогами, которые уже опубликованы. Буду рад, если Вы перечислите книги или статьи, в которых уже описано, как надо проектировать программы, в которых учтены Ваши пожелания. При этом, хотелось бы не просто увидеть имена авторов и названия работ, но и ссылки (с точностью до страницы), на которых излагаются методические и инструментальные советы. Под инструментальными я понимаю те, которые можно применять на практике, как формулу Виета для получения корней квадратного уравнения.
G>ни об общих ООП правилах — design guidelines.
Вы заметили, что в презентации не упоминается какая-либо связь с OOD. Поверьте, это не случайно.
G>Упомянуты "слоеные"системы — однако не указаны элементарные правила, которые не надо нарушать при их конструировании.
Выступление готовилось для грамотных специалистов. Не было необходимости повторять и так всем известные истины, которые можно прочитать хотя бы у Фаулера в книге "Архитектура корпоративных приложений".
G>Список литературы, который вы приводите, тоже не впечатляет. Паттерны не имеют отношения к проектированию — не думают проектировщики паттернами, патерны не более чем отходы их жизнедеятельности.
Ряд проектировщиков (в том числе, авторов книг по паттернам) не согласятся с Вашим мнением. Кроме того, книги по паттернам хотя бы описывают эффективные (или просто хорошие) решения ряда стандартных задач. В отличие от книг по проектированию (тогоже Буча или Rumbaugh, Jordan или Jacobson), где ни задачи, ни решения не приводятся. А если решения и приводятся, то неэффективные и порочные.
G>Комментировать по деталям — не вижу смысла.
Здесь я с Вами не согласен. Потому что в деталях-то как раз и заключается здравое зерно. На текущий момент, все, что Вы написали — это лишь Ваше мнение, которое не подкреплено какими-либо фактами либо разбором реальных задач. А еще Стив Макконел в свое книге писал, что экспертное мнение, не подкрепленное деталями, — самая худшая из возможных оценок.
G>В качестве чтения — какая-нибудь основополагающая книга по RUP для начала, и вы сами измените свою презенацию.
RUP излишне разрекламирован. На мой взгляд, реклама этой методологии сильно превышает ее возможности. В свое время я просмотрел немало статей по RUP, но не увидел ни одной (!) разобранной задачи проектирования, которая была бы решена с помощью RUP. Просмотрел я и ряд книжек по UML. В некоторых из них примеры разбирались, но принятые проектные решения, мягко говоря, вызывают ужас.
На мой взгляд, UML хорошо подходит для иллюстрации принятых проектных решений. Но уж никак не подходит в качестве средства решения задач.
Здравствуйте, Кирилл Лебедев, Вы писали:
G>>Что хорошо — это то, что вы понимаете, что сценарии применения (вы их называете "полезными функциями", в литературе же они проходят как use cases, user stories, и пр.) являются центральным аспектом при разработке и верификации дизайна системы.
КЛ>Вероятно, Вы имеете в виду пользовательские, а не "полезные" функции. И еще одно: пользовательская функция != use case (дословно — сценарий использования). Сценарий — это все-таки сценарий.
Равна. Разница не принципиальна. За функцией всегда стоит сценарий, и наоборот. Если вы считаете иначе — так объясняйте разницу. Не можете или не хотите — так нет смысла и воздух сотрясать.
G>>Это делает ваш подход в целом рабочим — на самом деле, многие не понимают важности анализа сценариев и городят. Это отличная, и правильная догадка. Единственно — полезные функции далеко не всегда ограничиватся границами модулей, как предполагается у вас.
КЛ>Чего-то я не помню у себя подобного утверждения.
Вы в тексте предполагаете четкую привязку модулей и функций.
G>>Что плохо — этим все и ограничивается. Вы не рассказали ни о процессе разработки дизайна (изложенное — довольно наивный подход, так студенты систему проектируют — правильно eao197 написал), ни о правилах верификации дизайна,
КЛ>Давайте не сравнивать реальную работу (в данном случае я пишу о презентации) с некоторым идеалом, который Вам хочется увидеть да еще и сразу. Давайте сравним с аналогами, которые уже опубликованы. Буду рад, если Вы перечислите книги или статьи, в которых уже описано, как надо проектировать программы, в которых учтены Ваши пожелания. При этом, хотелось бы не просто увидеть имена авторов и названия работ, но и ссылки (с точностью до страницы), на которых излагаются методические и инструментальные советы. Под инструментальными я понимаю те, которые можно применять на практике, как формулу Виета для получения корней квадратного уравнения.
Да мне не то чтобы хотелось что-нибудь увидеть — я достаточно самых разных материалов по этой теме успел изучить за последние лет 10, чтобы мне еще чего-то хотелось. Это вам хотелось увидеть мнение аудитории — мои ответы часть этого мнения.
Ссылки — много не дам, но кое-что могу по памяти. Предупреждаю — стараюсь не сильно.
Object Modelling Technque — автор Rumbaugh. Лучший учебник по проектированию систем, содержащий большое количество упражнений. Ищем на амазоне, на русский не переводилась.
CRC Cards Book, авторов не помню. Хорошая книга о проектировании ОО систем. Ищем в гугле — находим описание методики.
Ищем в гугле Liscov Substitution Principle, находим лекции по ОО дизайну.
Applying use cases, the Practical Guide http://www.amazon.com/Applying-Use-Cases-Practical-Guide/dp/0201309815
Вообще у Якобсона, по моему, должно быть на ту тему что-то классическое — я, честно говоря, не читал — мне в свое время посчастливилось изобрести нечто похожее самому, что сильно ускорило мое ознакомление с методом — хватило чтения по диагонали случайного материала, уже не помню какого.
G>>ни об общих ООП правилах — design guidelines.
КЛ>Вы заметили, что в презентации не упоминается какая-либо связь с OOD. Поверьте, это не случайно.
Не поверю. С какой стати? Вы что — Иисус Христос, чтоб вам верить?
G>>Упомянуты "слоеные"системы — однако не указаны элементарные правила, которые не надо нарушать при их конструировании.
КЛ>Выступление готовилось для грамотных специалистов. КЛ>Не было необходимости повторять и так всем известные истины, которые можно прочитать хотя бы у Фаулера в книге "Архитектура корпоративных приложений".
Извините, для грамотных специалистов в вашем выступлении нет ничего нового. Совсем. Не понятно, что вы вообще хотели сказать.
G>>Список литературы, который вы приводите, тоже не впечатляет. Паттерны не имеют отношения к проектированию — не думают проектировщики паттернами, патерны не более чем отходы их жизнедеятельности.
КЛ>Ряд проектировщиков (в том числе, авторов книг по паттернам) не согласятся с Вашим мнением.
А я не соглашусь с их мнением — я могу себе позволить иметь собственное. Еще не встречал ни хороших проектировщиков, думающих паттернами, ни одной методики проектирования, основанной на паттернах. Хороший проектировщик все больше функциями, сценариями, и потоками данных в системе озабочен, некогда ему паттернами любоваться и думать о них. Короче, у Рэмбо в книге хорошо показано, чем должен быть озабочен проектировщик.
КЛ>Кроме того, книги по паттернам хотя бы описывают эффективные (или просто хорошие) решения ряда стандартных задач. В отличие от книг по проектированию (тогоже Буча или Rumbaugh, Jordan или Jacobson), где ни задачи, ни решения не приводятся. А если решения и приводятся, то неэффективные и порочные. После такого как-то не получается вас серьезно воспринимать. Книга Рэмбо чуть ли не на треть из задач состоит. Вы почитайте чтоли, задачки порешайте. А потом о паттернах поговорим, расскажете мне, какую важную прикладную задачу решает паттерн "singleton", и как именно вам это знание поможет дизайн спроектировать.
G>>Комментировать по деталям — не вижу смысла.
КЛ>Здесь я с Вами не согласен. Потому что в деталях-то как раз и заключается здравое зерно.
Здесь я с вами не согласен . Его там нет, а если оно и есть — у вас, увы, не получилось его показать.
КЛ>На текущий момент, все, что Вы написали — это лишь Ваше мнение, которое не подкреплено какими-либо фактами либо разбором реальных задач. А еще Стив Макконел в свое книге писал, что экспертное мнение, не подкрепленное деталями, — самая худшая из возможных оценок.
Мое мнение это мое мнение. Можете получить другое мнение — например так. Расскажите вашу презентацию самое вчерашнему студенту — он будет вас слушать раскрыв рот.
G>>В качестве чтения — какая-нибудь основополагающая книга по RUP для начала, и вы сами измените свою презенацию.
КЛ>RUP излишне разрекламирован. На мой взгляд, реклама этой методологии сильно превышает ее возможности. В свое время я просмотрел немало статей по RUP, но не увидел ни одной (!) разобранной задачи проектирования, которая была бы решена с помощью RUP.
Такое бывает. Читают люди вроде одну книгу, а видят там разное. Это нормально.
КЛ>Просмотрел я и ряд книжек по UML. В некоторых из них примеры разбирались, но принятые проектные решения, мягко говоря, вызывают ужас.
Приведите пример книги и решения. Сами знаете — экспертное мнение, не подкрепленное деталями, — самая худшая из возможных оценок.
КЛ>На мой взгляд, UML хорошо подходит для иллюстрации принятых проектных решений. Но уж никак не подходит в качестве средства решения задач.
Да УМЛ тут вообще не причем. Это вообще никакое не средство — это всего лишь нотация .
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Я говорил о количественной статистике — она действительно не собиралась. Но ни что не мешает производить качественную оценку. А о ней я сказал. Методика позволяет:
Не поясните, на основании чего именно и каким образом вы можете делать "качественные" оценки?
КЛ>а) Сократить код.
Код меряется в строках кода. Google по слову LOC, или SLOC. Таки в сравнении с чем ваша методика позволит уменьшить объем кода, во сколько раз, и благодаря чему (вы, эта, когда качественный вывод делаете, обязательно должны объяснить в сравнении с чем и благодаря чему — а то получается что "у нея внутре неонка и думатель")
КЛ>б) Существенно сократить количество багов (от 2 до 5).
Количество багов меряется метрикой Defects/КLOC, что по русски означает "количество ошибок на тысячу строк кода", и называется "плотностью ошибок" (defects density). Исследования метрик реальных проектов показывают, что эта метрика одна из самых стабильных, причем до такой степени, что слабо зависит от применяемого языка программирования. Что означает, что количество ошибок в среднем большей степени определяется объемом кода.
У вас этот принцип нарушается? Ну тогда объясняйте — в сравнении с чем это у вас плотность ошибок скаканет и за счет чего? Неужто у вас в презентации расказанно как объем любого наперед взятого кода в 2-5 раз сократить? Ну ни в жисть не поверю. Хотите проверим? Давайте я вам сюда код приведу, а вы его хотя бы в два раза сократите?
КЛ>в) Существенно упростить сопровождение (архитектура не разъезжается).
Архитектура разъехжается за счет прлпущеных при анализе юзкейсов. Разъезжается она потому, что всех кейсов, которые в будущем появятся, вы в принципе предусмотреть не сможете, никакой ТРИЗ вам не поможет. Тогда приходится проводить рефакторинг (что вы и показываете на элементарном примере примерно четверть своей презентации). Никакого метода у вас я не заметил. Am I wrong? Может я пропустил чего, так вы скажите.
Здравствуйте, Gaperton, Вы писали:
G>Не поясните, на основании чего именно и каким образом вы можете делать "качественные" оценки?
На основании 11-летнего опыта разработки программ и порядка 30 завершенных проектов. Если Вас это не устраивает, звиняйте, других оценок пока нет. Впоследствии — будут.
G>Код меряется в строках кода. Google по слову LOC, или SLOC.
Код — многоуровневая иерархическая структура. И если Вы измеряете его строками, еще не значит, что эта единица измерения единственно правильная. Иногда выгоднее измерять код и в операторах, и в классах.
Да и читали Вы презентацию, судя по всему, невнимательно. Там слово "код" приведено в кавычках, чтобы подчеркнуть возможность различного толкования кода — и как набора операторов, и как набора классов...
G>Таки в сравнении с чем ваша методика позволит уменьшить объем кода, во сколько раз, и благодаря чему (вы, эта, когда качественный вывод делаете, обязательно должны объяснить в сравнении с чем и благодаря чему — а то получается что "у нея внутре неонка и думатель")
В презентации сказано: благодаря "свертыванию" и в сравнении с решениями, полученными на предыдущих этапах. В презентации приведены и этапы, и примеры. Читайте, пожалуйста, внимательнее, если уж пытаетесь написать отзыв. Хотя отзыв, как раз-таки у Вас не получается — в основном беспочвенная ирония и наезды.
G>Количество багов меряется метрикой Defects/КLOC, что по русски означает "количество ошибок на тысячу строк кода", и называется "плотностью ошибок" (defects density). Исследования метрик реальных проектов показывают, что эта метрика одна из самых стабильных, причем до такой степени, что слабо зависит от применяемого языка программирования. Что означает, что количество ошибок в среднем большей степени определяется объемом кода.
Позвольте спросить, Вы утверждаете, что код, написанный программистом-стажером и профи, содержит одинаковое количество багов на 1000 строк? Если Ваш ответ "да", то Вы страшно далеки от реальных проектов. Ибо количество ошибок у стажера может превышать количество ошибок у профи в десятки раз.
Сократить подобное различие может лишь четкая методология и формальный процесс. Но и после плотность ошибок все равно различается в разы.
G>У вас этот принцип нарушается? Ну тогда объясняйте — в сравнении с чем это у вас плотность ошибок скаканет и за счет чего? Неужто у вас в презентации расказанно как объем любого наперед взятого кода в 2-5 раз сократить? Ну ни в жисть не поверю. Хотите проверим? Давайте я вам сюда код приведу, а вы его хотя бы в два раза сократите?
Не передергивайте. Объем кода можно сократить, но далеко не любого. В презентации приведены и ситуации, и конкретные примеры.
G>Архитектура разъехжается за счет прлпущеных при анализе юзкейсов. Разъезжается она потому, что всех кейсов, которые в будущем появятся, вы в принципе предусмотреть не сможете, никакой ТРИЗ вам не поможет. Тогда приходится проводить рефакторинг (что вы и показываете на элементарном примере примерно четверть своей презентации).
Архитектура разъезжается не только за счет пропущенных юзкейсов, а еще и за счет "выведения классов из объектов", проектирования иерархий на основе общих атрибутов, за счет неучета масштаба и объема данных и многого многого другого. При этом, если думать, то рекомендации в презентации помогут, т.к. мудрый человек, понимая закономерность, перейдет сразу к этапу 2.3 или 2.4. А другой — будет заниматься рефакторингом.
G>Никакого метода у вас я не заметил. Am I wrong? Может я пропустил чего, так вы скажите.
Неудивительно. Ведь, судя по ошибкам в названиях, Вы презентацию не читали. Скорее всего — пробежались беглым взглядом, и бросились писать отзыв. Хотя отзывом назвать это трудно. Нет ни конкретных примеров, ни конкретных вопросов по приведенным примерам. Да и обойтись без наездов тоже не можете. Так что, в итоге имеем не отзыв, а банальный обсер на форуме со стороны не разобравшегося в предмете специалиста. Эмоционально понятно. Но для технаря слабовато.
Здравствуйте, Кирилл Лебедев, Вы писали:
G>>Не поясните, на основании чего именно и каким образом вы можете делать "качественные" оценки?
КЛ>На основании 11-летнего опыта разработки программ и порядка 30 завершенных проектов. Если Вас это не устраивает, звиняйте, других оценок пока нет. Впоследствии — будут.
Ой, какой разговор пошел . На основании одного факта, что вы в индустрии провели 11 лет своей жизни, вы, боюсь, здесь никому и ничего не докажете . Хотя бы потому, что не вы один тут имеете опыт 10+ лет. Это не есть ваша уникальная особенность. Посмотрите, кто вам минусы поставил — у них у всех 10+. И у меня тоже. Что дальше? Пиписьками меряться начнем, у кого длиннее?
Не устраивает, разумеется. Меня интересует "каким образом", а то что вы "из головы" свои качественные выводы берете — это и так понятно. Не откуда больше.
G>>Код меряется в строках кода. Google по слову LOC, или SLOC.
КЛ>Код — многоуровневая иерархическая структура. КЛ>И если Вы измеряете его строками, еще не значит, что эта единица измерения единственно правильная. Иногда выгоднее измерять код и в операторах, и в классах.
Код меряется в строках кода. Его так весь мир измеряет. Потому что только эта метрика дает мало-мальски приличные корелляции со временем разработки и с количеством ошибок. Количество классов не является метрикой объема кода, количество операторов дает строгую корелляцию с количеством строк кода, поэтому меряют все равно в строках кода — они проще в подсчете.
Но все-таки, я наверное чего-то не понимаю. Приведите примеры, в каких ситуациях и почему именно "выгоднее" измерять объем кода "в операторах". Желательно — живой пример из своего 11-летнего опыта. Просим-просим.
КЛ>Да и читали Вы презентацию, судя по всему, невнимательно. Там слово "код" приведено в кавычках, чтобы подчеркнуть возможность различного толкования кода — и как набора операторов, и как набора классов...
Раз все настолько сложно и неоднозначно — что понятие "код" берется в кавычки и у этого понятия возможны оказывается разные (!) толкования, то вам следовало посвятить понятию "кода" отдельные слайды вашей презентации. Ваш труд, по видимости, фундаментален, и пересматривает сами основы?
G>>Таки в сравнении с чем ваша методика позволит уменьшить объем кода, во сколько раз, и благодаря чему (вы, эта, когда качественный вывод делаете, обязательно должны объяснить в сравнении с чем и благодаря чему — а то получается что "у нея внутре неонка и думатель")
КЛ>В презентации сказано: благодаря "свертыванию" и в сравнении с решениями, полученными на предыдущих этапах. В презентации приведены и этапы, и примеры. Читайте, пожалуйста, внимательнее, если уж пытаетесь написать отзыв. Хотя отзыв, как раз-таки у Вас не получается — в основном беспочвенная ирония и наезды.
А-а, ну тогда понятно. А можно мне с рацпредложением выступить? Нельзя-ли тот длинный тупой код, в сравнении с которым у вас короче в 5 раз получается, вообще не писать, а? Может, все-таки, сразу нормальный, краткий и правильный код написать? Ну, подумать там как следует (это фаза "дизайн" называется, до половины времени разработки у некоторы занимает), и написать нормально, нет? Так не пойдет? Или по вашему надо сначала хреновню написать, а потом "свертыванием" заниматься?
G>>Количество багов меряется метрикой Defects/КLOC, что по русски означает "количество ошибок на тысячу строк кода", и называется "плотностью ошибок" (defects density). Исследования метрик реальных проектов показывают, что эта метрика одна из самых стабильных, причем до такой степени, что слабо зависит от применяемого языка программирования. Что означает, что количество ошибок в среднем большей степени определяется объемом кода.
КЛ>Позвольте спросить, Вы утверждаете, что код, написанный программистом-стажером и профи, содержит одинаковое количество багов на 1000 строк? Если Ваш ответ "да", то Вы страшно далеки от реальных проектов. Ибо количество ошибок у стажера может превышать количество ошибок у профи в десятки раз.
Я не понимаю, причем тут программист-стажер. Мы кажется тут все с 10+ опытом, говорим о программировании как о профессиональной деятельности, и презентации пишем для настолько умных программистов, что им не надо принципов построения слоеных систем объяснять?
КЛ>Сократить подобное различие может лишь четкая методология и формальный процесс. Но и после плотность ошибок все равно различается в разы.
Не отличается она в разы. У разных людей она отличается в среднем до двух раз, как и объем кода на одну и ту же задачу — в среднем до двух раз. Количество вносимых ошибок на тысячу строк в нормальных условиях постоянно для одного человека, и никак не зависит от формальности процесса и применяемой методологии.
G>>У вас этот принцип нарушается? Ну тогда объясняйте — в сравнении с чем это у вас плотность ошибок скаканет и за счет чего? Неужто у вас в презентации расказанно как объем любого наперед взятого кода в 2-5 раз сократить? Ну ни в жисть не поверю. Хотите проверим? Давайте я вам сюда код приведу, а вы его хотя бы в два раза сократите?
КЛ>Не передергивайте. Объем кода можно сократить, но далеко не любого. В презентации приведены и ситуации, и конкретные примеры.
А, ну понятно. Это в корне меняет дело.
G>>Архитектура разъехжается за счет прлпущеных при анализе юзкейсов. Разъезжается она потому, что всех кейсов, которые в будущем появятся, вы в принципе предусмотреть не сможете, никакой ТРИЗ вам не поможет. Тогда приходится проводить рефакторинг (что вы и показываете на элементарном примере примерно четверть своей презентации).
КЛ>Архитектура разъезжается не только за счет пропущенных юзкейсов, а еще и за счет "выведения классов из объектов", проектирования иерархий на основе общих атрибутов, за счет неучета масштаба и объема данных и многого многого другого. При этом, если думать, то рекомендации в презентации помогут, т.к. мудрый человек, понимая закономерность, перейдет сразу к этапу 2.3 или 2.4. А другой — будет заниматься рефакторингом.
Архитектура разъезжается только по причине неучтенных на тапе проектирования требованиях, частью которых являются юзкейсы. Придуманные вами термины забавны, конечно, но тока я не припомню, чтобы кто-нибудь классы из объектов выводил. Честно — увидел бы такую дичь — запомнил бы .
G>>Никакого метода у вас я не заметил. Am I wrong? Может я пропустил чего, так вы скажите.
КЛ>Неудивительно. Ведь, судя по ошибкам в названиях, Вы презентацию не читали. Скорее всего — пробежались беглым взглядом, и бросились писать отзыв. Хотя отзывом назвать это трудно. Нет ни конкретных примеров, ни конкретных вопросов по приведенным примерам. Да и обойтись без наездов тоже не можете. Так что, в итоге имеем не отзыв, а банальный обсер на форуме со стороны не разобравшегося в предмете специалиста. Эмоционально понятно. Но для технаря слабовато.
С чего вы взяли, что люди должны тратить на ваш труд свое время? Вам тут никто и ничего не обязан. Да и презентация у вас откровенно слаба, для студента ничего, а для технаря вообще никак. Вы бы не позорились с докладами на конференциях, побольше читали, да еще поменьше про 11 лет своего опыта говорили — а то люди-то смеяться будут над вами. Я совершенно серьезно это вам говорю. Себе же хуже делаете.
Re[3]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, Кирилл Лебедев, Вы писали:
G>>Что плохо — этим все и ограничивается. Вы не рассказали ни о процессе разработки дизайна (изложенное — довольно наивный подход, так студенты систему проектируют — правильно eao197 написал), ни о правилах верификации дизайна,
КЛ>Давайте не сравнивать реальную работу (в данном случае я пишу о презентации) с некоторым идеалом, который Вам хочется увидеть да еще и сразу. Давайте сравним с аналогами, которые уже опубликованы. Буду рад, если Вы перечислите книги или статьи, в которых уже описано, как надо проектировать программы, в которых учтены Ваши пожелания. При этом, хотелось бы не просто увидеть имена авторов и названия работ, но и ссылки (с точностью до страницы), на которых излагаются методические и инструментальные советы. Под инструментальными я понимаю те, которые можно применять на практике, как формулу Виета для получения корней квадратного уравнения.
Давайте.
Б.Страуструп, Язык программирования C++, спец.изд./Пер. с англ. -- М.;СПб.:"Издательство БИНОМ" -- "Невский Диалект", 2001 г. -- 1099 с., ил.
Для начала несколько общих слов о проектировании ($23.2, стр.761):
В этой главе можно выделить несколько главных тем:
* Самое главное при разработке программного обеспечения -- ясно понимать, что вы пытаетесь построить. (**)
* Успешная разработка программного обеспечения -- это дело, требующее времени.
* Конструируемые нами системы стремяться оказаться на пределе сложности, доступной нам и нашим средствам.
* В проектировании и программировании не существует универсальных рецептов, которые могли бы заменить ум, опыт и хороший вкус. (***)
* При разработке всякого нетривиального программного обеспечения незаменимо экспериментирование.
* Проектирование и программирование -- итеративные процессы.
* Нельзя строго разделить фазы создания программы, такие как проектирование, программирование и тестирование.
* Нельзя рассматривать программирование и проектирование, не затрагивая вопросы менеджмента.
О целях проектирования ($23.4.2, стр.769):
Какие задачи должно решать проектирование? Одна из них, конечно, -- достижение простоты, но простоты в каком смысле? Допустим, что проект должен развиваться. Т.е. систему придется расширять, переносить, настраивать, вообще по-разному изменять, и заранее нельзя предвидеть, как именно...
Из этого вытекает, что система должна быть спроектирована так, чтобы оставаться как можно проще после серии внесенных в нее изменений. Мы должны закладываться изменения в проект, т.е. мы должны стремиться к:
* гибкости;
* способности к расширению;
* переносимости.
Лучше всего это достигается попытками инкапсулировать те области системы, которые вероятно будут изменяться, и обеспечением такого способа работы, когда последующие проектировщики/программисты вносят изменения в одну область, на затрагивая другие. Это обеспечивается путем определения для данной разработки ключевых понятий и придания каждому классу исключительной ответственности за содержание всей информации, относящейся к отдельному понятию. В этом случае изменение можно внести, модифицировав только один класс. В идеале изменение одного понятия может быть произведено созданием производного класса или заданием другог аргумента шаблона. Естественно, этот идеал легче провозгласить, чем ему следовать.
В качестве примера, который показывает, как может измениться подход к реализации чего-нибудь, в зависимости от целей ($23.4.2, стр.770):
Рассмотрим пример. В моделировании, связанном с метеорологическими явлениями, мы хотим показать дождевую тучу. Как нам это сделать? Мы не можем иметь общую процедуру для показа тучи, поскольку ее внешний облик зависит от ее внутреннего состояния, а это состояние должно быть ответственностью только тучи.
Первое решение проблемы -- дать туче возможность самой показывать себя. Такой стиль решения приемлим во многих конкретных случаях. Однако, он не универсален, потому что существует множество способов представления тучи: например, как подробной картины, как грубого силуэта или как условного значка на карте...
Второе решение проблемы -- сделать так, чтобы туча знала о своем окружении и сама себя отображала. Это решение приемлимо для еще более широкого ряда случаев. Однако это по-прежнему не универсальное решение. Знание тучей всех деталей своего окружения нарушает установку на то, что класс должен отвечать только за одну вещь, и за каждую вещь должен отвечать какой-то один класс...
Третье решение -- заставить тучу (и другие объекты, такие как самолеты и солнце) описывать самих себя для наблюдателя. Это решение достаточно универсально (даже эта модель вряд ли будет удовлетворительной для случаев, когда требуется графика высокого качества, основанная на расчете хода лучей...). Однако, оно может привести к повышению сложности и потере быстродействия...
...Отметим, что третье решение не является "правильным", оно просто самое универсальное. Проектировщик должен балансировать между множеством различных потребностей, чтобы выбрать уровень универсальности и абстрагирования, подходящий для данной задачи в данной системе.
Теперь о самом проектировании ($23.4.3, стр.771):
Итак, рассмотрим, как можно подойти к проектированию компоненты. Поскольку зачастую это непростая задача, стоит разбить ее на этапы, чтобы логичным образом сфокусироваться на разных подзадачах.Как обычно, для этого нет универсального правильного способа. Однако, вот последовательность действий, которая кое-кому помогла:
[1] Выявите понятия/классы и их самые фундаментальные взаимосвязи.
[2] Уточните классы, определив набор операций над ними.
* Классифицируйте это операции. В частности, рассмотрите потребность в конструкторах, деструкторах и копировании.
* Рассмотрите минимальность, полноту и удобство/
[3] Уточните классы, определив их взаимозависимость.
* Рассмотрите параметризацию, наследование и воспользуйтесь зависимостью.
[4] Определите интерфейсы:
* Разделите функции на открытые и защищенные.
* Определите точный тип операций над классом.
И далее эти шаги раскрываются более подробно: $23.4.3.1. Этап 1: выявление классов (сс.772-775), $23.4.3.2. Этап 2: определение операций (сс.775-776), $23.4.3.3. Этап 3: определение взаимозависимостей (стр.777), $23.4.3.4. Этап 4: определение интерфейсов (сс.777-778), $23.4.3.5. Реорганизация иерархии классов (сс.778-779), $23.4.3.6. Использование моделей (сс.779-780).
И это всего лишь одна глава в книге, которая посвящена конкретному языку программирования, а не проектированию программ.
Не могли бы вы здесь, без ссылок на свои статьи или части своей презентации, сформулировать, что нового показала ваша презентация по сравнению, хотя бы, с данной главой из книги Страуструпа?
** Не подразуевает ли это тчательную проработку use-case-ов?
*** Это вообще следует помнить при попытки возведения какого-либо метода (будь то ТРИЗ или RUP) в ранг Методологии.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Ой, какой разговор пошел . На основании одного факта, что вы в индустрии провели 11 лет своей жизни, вы, боюсь, здесь никому и ничего не докажете . Хотя бы потому, что не вы один тут имеете опыт 10+ лет. Это не есть ваша уникальная особенность. Посмотрите, кто вам минусы поставил — у них у всех 10+.
Вы не прячьтесь за чужие минусы, а попробуйте вести дискуссию предметно, конструктивно и без наездов. Пока что наезды с Вашей стороны превышают количество приведенных Вами примеров (их вообще нет). Да и замечания Ваши непредметны. Уж если б придирались, то хотя бы к конкретным слайдам.
G>И у меня тоже. Что дальше? Пиписьками меряться начнем, у кого длиннее?
Хочу напомнить, что разговор в таком тоне начали Вы. Если уж пытаетесь разобраться в предмете, то задавайте вопросы вежливо и, желаетльно, без наездов на собеседника. Если же Вам разбираться не хочется, то зачем Вы вообще ввязались в дискуссию?
G>Не устраивает, разумеется. Меня интересует "каким образом", а то что вы "из головы" свои качественные выводы берете — это и так понятно. Не откуда больше.
Если Вас интересует ответ на этот вопрос, обратите внимание на пример, приведенный в презентации. Полагаю, что ответ будет очевиден.
G>Код меряется в строках кода. Его так весь мир измеряет. Потому что только эта метрика дает мало-мальски приличные корелляции со временем разработки и с количеством ошибок. Количество классов не является метрикой объема кода, количество операторов дает строгую корелляцию с количеством строк кода, поэтому меряют все равно в строках кода — они проще в подсчете.
Уважаемый коллега! В детстве, Вы наверняка, смотрели мультик про слоненка, мартышку, попугая и удава. Там наглядно показано, что длину можно мерить в чем угодно. Так удава измеряли и в мартышках, и в слоненках, и в попугаях. Даже маленькие дети понимают, что измерять можно, в чем угодно. В чем удобнее, в том и измерим. Неужели же программист с более чем 10-летним стажем не понимает этой столь простой истины?
G>Но все-таки, я наверное чего-то не понимаю. Приведите примеры, в каких ситуациях и почему именно "выгоднее" измерять объем кода "в операторах". Желательно — живой пример из своего 11-летнего опыта. Просим-просим.
Пример есть в презентации. Если же Вам что-то непонятно, задайте вопрос без ехидства. Я отвечу. На вопросы, сформулированные в таком тоне, как сейчас, я отвечать не буду.
G>Раз все настолько сложно и неоднозначно — что понятие "код" берется в кавычки и у этого понятия возможны оказывается разные (!) толкования, то вам следовало посвятить понятию "кода" отдельные слайды вашей презентации. Ваш труд, по видимости, фундаментален, и пересматривает сами основы?
Я не предполагал, что для кого-то банальная истина может быть непонятна. С учетом того, что здесь уже кажется обсуждали, что текст — не единственно возможное представление кода. Поищите, думаю, обсуждение было где-то в марте-апреле.
G>А-а, ну тогда понятно. А можно мне с рацпредложением выступить? Нельзя-ли тот длинный тупой код, в сравнении с которым у вас короче в 5 раз получается, вообще не писать, а? Может, все-таки, сразу нормальный, краткий и правильный код написать? Ну, подумать там как следует (это фаза "дизайн" называется, до половины времени разработки у некоторы занимает), и написать нормально, нет? Так не пойдет? Или по вашему надо сначала хреновню написать, а потом "свертыванием" заниматься?
Я, конечно, "за". Но кто будет "сворачивать" "код" на стадии "дизайна"? И какими методами? Ах, да, Вы опять скажете, что на стадии дизайна кода еще нет. Ведь, как же! Код еще не написан! А его уже пытаются сократить!!! Простая мысль о том, что одна из задач проектирования — это разработка архитектуры, при которой объем кода минимален, Вам не приходит в голову.
Ведь Вы же код меряете только в уже написанных строках! А о том, что иерархию из 115 классов (хотя бы их код и будет минимален) будет трудно сопровождать, Вы как-то не задумываетесь. Если бы задумывались, то, по крайней мере, не спрашивали бы меня, когда код полезно измерять в классах.
КЛ>>Позвольте спросить, Вы утверждаете, что код, написанный программистом-стажером и профи, содержит одинаковое количество багов на 1000 строк? Если Ваш ответ "да", то Вы страшно далеки от реальных проектов. Ибо количество ошибок у стажера может превышать количество ошибок у профи в десятки раз.
G>Я не понимаю, причем тут программист-стажер. Мы кажется тут все с 10+ опытом, говорим о программировании как о профессиональной деятельности, и презентации пишем для настолько умных программистов, что им не надо принципов построения слоеных систем объяснять?
Не уходите в сторону, а отвечайте на вопрос: "Код стажера и код профи, действительно, по Вашему мнению, имеет одинаковое количество багов?" Тут кто-то говорил про универсальность метрик. Так что презентация тут не при чем.
КЛ>>Сократить подобное различие может лишь четкая методология и формальный процесс. Но и после плотность ошибок все равно различается в разы.
G>Не отличается она в разы. У разных людей она отличается в среднем до двух раз, как и объем кода на одну и ту же задачу — в среднем до двух раз. Количество вносимых ошибок на тысячу строк в нормальных условиях постоянно для одного человека, и никак не зависит от формальности процесса и применяемой методологии.
Вот странный человек. Для того и создаются различные методологии, чтобы сократить количество ошибок в коде. И различные процедуры проверки качества типа code review. А Вы все заладили про постоянство ошибок. Поруководите хотя бы пол годика реальными программистами, и Вы сами уже будете знать, сколько ошибок и их серьезность допустит тот или иной программист.
G>Архитектура разъезжается только по причине неучтенных на тапе проектирования требованиях, частью которых являются юзкейсы. Придуманные вами термины забавны, конечно, но тока я не припомню, чтобы кто-нибудь классы из объектов выводил. Честно — увидел бы такую дичь — запомнил бы .
Честно говоря, это уже не забавно, когда человек под объектом понимает только переменную, созданную на основе класса. А то, что в реальном мире (или в предметной области) существуют объекты, которые не являются переменными, например, "лестница", "стул", "стол" — человек уже не понимает. Это странно. Можно подумать, Вы никогда не видели классов типа Window, Folder, Book, Film и т.д. — которые созданы на основе объектов реального мира.
G>С чего вы взяли, что люди должны тратить на ваш труд свое время? Вам тут никто и ничего не обязан. Да и презентация у вас откровенно слаба, для студента ничего, а для технаря вообще никак. Вы бы не позорились с докладами на конференциях, побольше читали, да еще поменьше про 11 лет своего опыта говорили — а то люди-то смеяться будут над вами. Я совершенно серьезно это вам говорю. Себе же хуже делаете.
С чего Вы взяли, что я вообще чего-то взял? Презентация выложена для желающих. Вам это неинтересно? Не читайте! И уж тем более не пишите какие-либо отзывы. Хотя бы потому, что написать вежливо, по-существу и конкретно у Вас не получается. А вычитывать подростковую грубость мне неинтересно.
Здравствуйте, eao197, Вы писали:
E>Не могли бы вы здесь, без ссылок на свои статьи или части своей презентации, сформулировать, что нового показала ваша презентация по сравнению, хотя бы, с данной главой из книги Страуструпа?
Вы хотите, чтобы я назвал отличия? Ну, что ж, держите:
Понятие идеальной программы. Почему выгодно ориентироваться на идеальность.
Этапы развития "кода" (как архитектуры, так и самого кода). Волнообразная модель.
Метод группировки разнородных сущностей. Ему посвящены этапы 1.3 и 2.2. Обычно группируют, находя похожие атрибуты и вынося их в базовые классы. В презентации говорится, что контекст для группировки нужно искать со стороны, т.е. не по похожести атрибутов, а потому, как и для чего объекты используются.
Схлопывание иерархии в класс.
Этапы свертывания. В частности, то, что задание одинаковых интерфейсов для различных сущностей — первый шаг к дальнейшему их свертыванию.
То, что различия между объектами "надо продвигать вниз" (на нижние слои).
То, что нижние слои поглощают средние.
То, что сначала нужно выявлять не классы/понятия, а действия. И проектировать конкретные структуры данных под эти операции (назовем их макро-операции или бизнес-функции).
E>[i]** Не подразуевает ли это тчательную проработку use-case-ов?
Такую обтекаемую фразу можно понимать, как угодно. Я предпочитаю более точное указание.
Встречный вопрос. В части 3 своей книги (http://www.helloworld.ru/texts/comp/other/oop/) Гради Буч разбирает ряд конкретных задач. Не могли бы Вы показать, как, используя рекомендации Страуструпа, можно решить хоть одну из приведенных задач?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Уважаемый коллега! В детстве, Вы наверняка, смотрели мультик про слоненка, мартышку, попугая и удава. Там наглядно показано, что длину можно мерить в чем угодно. Так удава измеряли и в мартышках, и в слоненках, и в попугаях. Даже маленькие дети понимают, что измерять можно, в чем угодно. В чем удобнее, в том и измерим. Неужели же программист с более чем 10-летним стажем не понимает этой столь простой истины?
Даже программисту вообще без стажа работы понятно, что удава в слонах измерили неправильно, и что лучше мерить в одних и тех же единицах — качественного различия не получишь
Потренируемся в знании отечественных мултиков?
G>>Но все-таки, я наверное чего-то не понимаю. Приведите примеры, в каких ситуациях и почему именно "выгоднее" измерять объем кода "в операторах". Желательно — живой пример из своего 11-летнего опыта. Просим-просим.
КЛ>Пример есть в презентации. Если же Вам что-то непонятно, задайте вопрос без ехидства. Я отвечу. На вопросы, сформулированные в таком тоне, как сейчас, я отвечать не буду.
Я вот например то же не понял, почему одни единицы "выгоднее" других? Чем они выгоднее? Тем, что можно слушателя запутать по поводу ожидаемого количества кода?
У каждого измерения есть цель, грубо говоря, функциональная предпосылка. Какая цель в измерении кода количеством строк сказал выше Gaperton, а вот какая цель в измерении классами как-то не очень понятно. Тем более, что не классами он у вас должен меряться, а количеством связей и интерфейсов на одном абстрактном слое. Тут вы сами себе противоречите.
КЛ>Я не предполагал, что для кого-то банальная истина может быть непонятна. С учетом того, что здесь уже кажется обсуждали, что текст — не единственно возможное представление кода. Поищите, думаю, обсуждение было где-то в марте-апреле.
Не единственно возможное, но наиболее часто используемое, удобное и привычное. Сами бы дали ссылку, вам-то легче найти. Споров таких в философии было уже штук пять наверное, на моей памяти.
КЛ>Я, конечно, "за". Но кто будет "сворачивать" "код" на стадии "дизайна"? И какими методами? Ах, да, Вы опять скажете, что на стадии дизайна кода еще нет. Ведь, как же! Код еще не написан! А его уже пытаются сократить!!! Простая мысль о том, что одна из задач проектирования — это разработка архитектуры, при которой объем кода минимален, Вам не приходит в голову.
Ему-то как раз приходит. Он вам и предлагает сократить объём кода, когда он ещё не написан. Потом он уже будет написан и отписать его назад будет невозможно: вот его и придётся сворачивать
Здесь замечание уходит туда же, куда и мои замечания по поводу того, что вы не рассмотрели весь процесс разработки и не выясниили, каким образом проектировать СРАЗУ хорошую архитектуру так, чтобы необходимость в сворачивании кода была минимальна.
Сворачивание кода — дополнительная паразитная работа, которой хотелось бы избежать. Об этом вам говорит Gaperton, если я его правильно понимаю, конечно
КЛ>Ведь Вы же код меряете только в уже написанных строках! А о том, что иерархию из 115 классов (хотя бы их код и будет минимален) будет трудно сопровождать, Вы как-то не задумываетесь. Если бы задумывались, то, по крайней мере, не спрашивали бы меня, когда код полезно измерять в классах.
Т.е. вы предлагаете всю эту иерархию запихнуть в один класс и сказать, что его будет лечге сопровождать, чем хорошо построенную иерархию из простых классов?
КЛ>Не уходите в сторону, а отвечайте на вопрос: "Код стажера и код профи, действительно, по Вашему мнению, имеет одинаковое количество багов?" Тут кто-то говорил про универсальность метрик. Так что презентация тут не при чем.
Т.е. вы хотите сказать, что количество ошибок на один класс у программиста-гуру и стажёра будет одно и то же?
G>>С чего вы взяли, что люди должны тратить на ваш труд свое время? Вам тут никто и ничего не обязан. Да и презентация у вас откровенно слаба, для студента ничего, а для технаря вообще никак. Вы бы не позорились с докладами на конференциях, побольше читали, да еще поменьше про 11 лет своего опыта говорили — а то люди-то смеяться будут над вами. Я совершенно серьезно это вам говорю. Себе же хуже делаете.
КЛ>С чего Вы взяли, что я вообще чего-то взял? Презентация выложена для желающих. Вам это неинтересно? Не читайте! И уж тем более не пишите какие-либо отзывы. Хотя бы потому, что написать вежливо, по-существу и конкретно у Вас не получается. А вычитывать подростковую грубость мне неинтересно.
Не подросток Gaperton вовсе. Он на форуме с 2003 года, за это время уже вырос бы, даже если бы был подростком.
Я бы на вашем месте так резко не реагировал даже на личную критику, в конечном итоге это вам нужно вычленить зерно истины из его критики, а не ему (если вам не нужно, то зачем вы вообще спорите?). Если честно, мне очень странно видеть вашу реакцию на критику, вы портите себе репутацию. Я ещё понимаю, когда я глупости говорю или даже резкости — да мне можно! Я ещё молодой, образумлюсь, те, кто этого не понимает, сами не очень-то значит хорошие начальники. А вот вы-то уже специалист и с опытом, и без юношеских замашек должны быть. Как же вы так?
Я знаю, как неприятно, когда твою презентацию критикуют, но здесь очень много полезного и вам практически все говорят об одном и том же, но по разному. Нужно только прислушаться. Вас никто в дерьмо тут кунать не собирается, нужно наоборот направить людей, что бы они говорили вам понятно...
И помните, что иногда критиковать презентацию послайдово просто нет никакого смысла, так как сама её структура неправильная.
Здравствуйте, Кирилл Лебедев, Вы писали:
G>>Ой, какой разговор пошел . На основании одного факта, что вы в индустрии провели 11 лет своей жизни, вы, боюсь, здесь никому и ничего не докажете . Хотя бы потому, что не вы один тут имеете опыт 10+ лет. Это не есть ваша уникальная особенность. Посмотрите, кто вам минусы поставил — у них у всех 10+.
КЛ>Вы не прячьтесь за чужие минусы, а попробуйте вести дискуссию предметно, конструктивно и без наездов. Пока что наезды с Вашей стороны превышают количество приведенных Вами примеров (их вообще нет). Да и замечания Ваши непредметны. Уж если б придирались, то хотя бы к конкретным слайдам.
Да зачем мне прятаться — я и своих могу понаставить. Вот — держите . Замечания у меня вполне предметны — и на них вы не даете ответа. Слайды ваши по одному я комментировать не буду — я же сказал, смысла в этом не вижу, у вас не в деталях проблемы, а в принципе. Самая существенная проблема — вы не в состоянии никому здесь объяснить, что вы хотели сказать, при этм требуете послайдных комментариев.
G>>И у меня тоже. Что дальше? Пиписьками меряться начнем, у кого длиннее?
КЛ>Хочу напомнить, что разговор в таком тоне начали Вы. Если уж пытаетесь разобраться в предмете, то задавайте вопросы вежливо и, желаетльно, без наездов на собеседника. Если же Вам разбираться не хочется, то зачем Вы вообще ввязались в дискуссию?
Если вам отвечать на вопросы не хочется — зачем вывешивать матриал и просить высказать мнение?
G>>Не устраивает, разумеется. Меня интересует "каким образом", а то что вы "из головы" свои качественные выводы берете — это и так понятно. Не откуда больше.
КЛ>Если Вас интересует ответ на этот вопрос, обратите внимание на пример, приведенный в презентации. Полагаю, что ответ будет очевиден.
Я прошу вам дать ответ здесь. Отвечайте, если вам есть что сказать. Нечего сказать — закрываем разговор.
G>>Код меряется в строках кода. Его так весь мир измеряет. Потому что только эта метрика дает мало-мальски приличные корелляции со временем разработки и с количеством ошибок. Количество классов не является метрикой объема кода, количество операторов дает строгую корелляцию с количеством строк кода, поэтому меряют все равно в строках кода — они проще в подсчете.
КЛ>Уважаемый коллега! В детстве, Вы наверняка, смотрели мультик про слоненка, мартышку, попугая и удава. Там наглядно показано, что длину можно мерить в чем угодно. Так удава измеряли и в мартышках, и в слоненках, и в попугаях. Даже маленькие дети понимают, что измерять можно, в чем угодно. В чем удобнее, в том и измерим. Неужели же программист с более чем 10-летним стажем не понимает этой столь простой истины?
Уважаемый коллега, вы меня хотите в чем убедить — в том, что ваши знания в софтверных метриках _ограничивается_ детским мультиком про слоненка с мартышкой? Gratz. Вам это удалось.
G>>Но все-таки, я наверное чего-то не понимаю. Приведите примеры, в каких ситуациях и почему именно "выгоднее" измерять объем кода "в операторах". Желательно — живой пример из своего 11-летнего опыта. Просим-просим.
КЛ>Пример есть в презентации. Если же Вам что-то непонятно, задайте вопрос без ехидства. Я отвечу. На вопросы, сформулированные в таком тоне, как сейчас, я отвечать не буду.
Да вы ни на один из вопросов в ветке по существу не ответили, коллега . Проверим? Вопрос:"Приведите примеры, в каких ситуациях и почему именно "выгоднее" измерять объем кода "в операторах". Ссылки на вашу презентацию меня не интересуют. Вопрос простой, вилять прекращаем, отвечаем.
G>>Раз все настолько сложно и неоднозначно — что понятие "код" берется в кавычки и у этого понятия возможны оказывается разные (!) толкования, то вам следовало посвятить понятию "кода" отдельные слайды вашей презентации. Ваш труд, по видимости, фундаментален, и пересматривает сами основы?
КЛ>Я не предполагал, что для кого-то банальная истина может быть непонятна. С учетом того, что здесь уже кажется обсуждали, что текст — не единственно возможное представление кода. Поищите, думаю, обсуждение было где-то в марте-апреле.
Охренеть. Вот ведь наука дошла. Ссылочку не дадите — я что-то не нашел .
G>>А-а, ну тогда понятно. А можно мне с рацпредложением выступить? Нельзя-ли тот длинный тупой код, в сравнении с которым у вас короче в 5 раз получается, вообще не писать, а? Может, все-таки, сразу нормальный, краткий и правильный код написать? Ну, подумать там как следует (это фаза "дизайн" называется, до половины времени разработки у некоторы занимает), и написать нормально, нет? Так не пойдет? Или по вашему надо сначала хреновню написать, а потом "свертыванием" заниматься?
КЛ>Я, конечно, "за". Но кто будет "сворачивать" "код" на стадии "дизайна"? И какими методами?
Действительно, вот ведь проблема. Кода-то на стадии дизайна нет. Поэтому, его не надо "сворачивать". Получается, вся ваша теория рушится. Ай-ай-ай. Нет, так конечно не пойдет.
КЛ>Ах, да, Вы опять скажете, что на стадии дизайна кода еще нет.
Yep. I did it! Его в самом деле еще нет. Что будем делать? А?
КЛ>Ведь, как же! Код еще не написан! А его уже пытаются сократить!!!
Угу. Именно. Мало того, что пытаются несуществующий код сократить, так ведь еще и сократить раз в 2-5. Разумеется, в сравнении с несуществующим кодом. Эт вы хитро придумали, коллега. Ловкий ход, у Буча с Рэмбо о таком смелом подходе ни слова. Непонятно только, почему не раз в 10. А так, смело, смело.
КЛ>Простая мысль о том, что одна из задач проектирования — это разработка архитектуры, при которой объем кода минимален, Вам не приходит в голову.
Ну конечно, эта светлая до идиотизма мысль только вам, коллега, первому в голову и пришла. Даже Рэмбо с Якобсоном нервно курят в сторонке.
КЛ>Ведь Вы же код меряете только в уже написанных строках! А о том, что иерархию из 115 классов (хотя бы их код и будет минимален) будет трудно сопровождать, Вы как-то не задумываетесь. Если бы задумывались, то, по крайней мере, не спрашивали бы меня, когда код полезно измерять в классах.
Количество классов не имеет никакой связи со сложностью сопровождения больших систем. Вообще. Если бы вы задумались о том, зачем вообще надо измерять объем кода, вы бы может быть и могли ответить на мой вопрос. А так — вам приходится нести чушь и изворачиваться. Бывает.
G>>Я не понимаю, причем тут программист-стажер. Мы кажется тут все с 10+ опытом, говорим о программировании как о профессиональной деятельности, и презентации пишем для настолько умных программистов, что им не надо принципов построения слоеных систем объяснять?
КЛ>Не уходите в сторону, а отвечайте на вопрос: "Код стажера и код профи, действительно, по Вашему мнению, имеет одинаковое количество багов?" Тут кто-то говорил про универсальность метрик. Так что презентация тут не при чем.
Не буду я отвечать на ваши вопросы. Вы же на мои не отвечаете.
КЛ>>>Сократить подобное различие может лишь четкая методология и формальный процесс. Но и после плотность ошибок все равно различается в разы.
G>>Не отличается она в разы. У разных людей она отличается в среднем до двух раз, как и объем кода на одну и ту же задачу — в среднем до двух раз. Количество вносимых ошибок на тысячу строк в нормальных условиях постоянно для одного человека, и никак не зависит от формальности процесса и применяемой методологии.
КЛ>Вот странный человек. Для того и создаются различные методологии, чтобы сократить количество ошибок в коде.
Количство вносимых ошибок от методологии не зависит — оно только от человека зависит. От методологии зависит, насколько рано вы эти ошибки находите. Сколько ошибок останется в коде, тоже от методологии не зависит. Вам это понять, похоже, сложно, слишком тонкая разница между вносимыми и устраняемыми ошибками, но ничего — в мире есть много сложных вещей, которых, друг Горацио, нам не понять никогда, пора привыкать.
КЛ>И различные процедуры проверки качества типа code review.
Способствуют раннему обнаружению ошибок, снижая цену их исправления. На количество вносимых ошибок не влияет, как и на количество ошибок в конечном продукте. Вы прежде чем слова модные повторять, хоть бы почитали чего по теме. Хотя по списку литературы у вас заметно, что вы не читатель, а писатель . На себя ссылаетесь.
КЛ>А Вы все заладили про постоянство ошибок. Поруководите хотя бы пол годика реальными программистами, и Вы сами уже будете знать, сколько ошибок и их серьезность допустит тот или иной программист.
Я-то как раз знаю, сколько ошибок допускают программисты. Скажу по секрету — по метрикам компании CQG, где я работал пару лет назад, плотность ошибок колеблется в среднем в коридоре 20-40 штук на 1000 строк кода. Язык С++.
А вот вы, похоже, студент, по ответам видно. Материалом не владеем, чушь порем, со старшими спорим .
G>>С чего вы взяли, что люди должны тратить на ваш труд свое время? Вам тут никто и ничего не обязан. Да и презентация у вас откровенно слаба, для студента ничего, а для технаря вообще никак. Вы бы не позорились с докладами на конференциях, побольше читали, да еще поменьше про 11 лет своего опыта говорили — а то люди-то смеяться будут над вами. Я совершенно серьезно это вам говорю. Себе же хуже делаете.
КЛ>С чего Вы взяли, что я вообще чего-то взял? Презентация выложена для желающих. Вам это неинтересно? Не читайте!
Да я и не читаю, вы не волнуйтесь . Вам мои ответы не интересны? Не читайте!
КЛ>И уж тем более не пишите какие-либо отзывы.
Звиняйте. Я пишу когда хочу и что хочу. Вам же никто не запрещает поток сознания в презентации заворачивать, а потом на людей бросаться. У нас свободная страна.
КЛ>Хотя бы потому, что написать вежливо, по-существу и конкретно у Вас не получается.
Отчего же — у меня вполне получается. Не получается отвечать у вас.
КЛ>А вычитывать подростковую грубость мне неинтересно.
Конечно, вам ее писать гораздо интереснее, это уже весь город заметил.
Здравствуйте, Кирилл Лебедев, Вы писали:
E>>Не могли бы вы здесь, без ссылок на свои статьи или части своей презентации, сформулировать, что нового показала ваша презентация по сравнению, хотя бы, с данной главой из книги Страуструпа?
КЛ>Вы хотите, чтобы я назвал отличия? Ну, что ж, держите:
Спасибо, удержал. Не сложно было, знаете-ли.
Позволил себе перегруппировать и прокомментировать их.
КЛ>Понятие идеальной программы. Почему выгодно ориентироваться на идеальность.
Под идеальностью, надо полагать, понимается вот это (или вокруг этого):
Техническая система считается идеальной, если ее вес, объем и площадь стремятся к нулю, а способность выполнять работу при этом не уменьшается. Иными словами, идеальная техническая система – это когда системы нет, а ее функция выполняется.
Т.е. с вашей точки зрения идеал -- это минимальное количество кода, решающего конкретную задачу. Ну что ж, ваше мнение таково. Нельзя запретить его вам иметь.
Как и сложно с ним согласиться. В частности, по моему опыту идеально заточенные под конкретную задачку фрагменты программы (т.е. такие, в которые не убавить, но добавить) оказываются несопровождабельными при смене требований. Именно так -- чуть-чуть потребовалось изменить поведение и приплыздец -- код такой, что в него не добавишь, не убавишь, только переписать и можно. В то же время более универсальный, а значит более избыточный и не такой эффективный, код оказывается гораздо восприимчивее к изменениям. Т.е. система не идеальна, но зато затраты на ее развитие ниже, соответственно, не идеальная система оказывается более правильной.
В качестве примера: есть такая Unix-овая библиотека, getopt. Довольно старая и, соответственно, дизайн у нее старый. Я пользуюсь ее воплощением в C++ в библиотеке ACE. Код по обработке опций командной строки получается весьма избыточным. Но, в отличии от библиотек, которые я использовал ранее, он очень понятный, легко расширяется и, что не маловажно оказалось, очень легко переносит copy&paste из проекта в проект.
Аналогичная ситуация с Ruby-реализаций: GetoptLong требует больше кода, чем OptionParser, зато обработка различных нестандартных сочетаний аргументов в GetoptLong выполняется с ходу, а для OptionParser нужно более долгое и тчательное изучение деталей работы OptionParser.
По этим причинам стремление к универсальности кода, о чем и говорит Страуструп, мне представляется гораздо более близким к действительности, чем ваша "идеальность".
КЛ>Этапы развития "кода" (как архитектуры, так и самого кода). Волнообразная модель. КЛ>Схлопывание иерархии в класс.
Все это частные случаи в итеративном подходе к разработке.
Может быть вы объясните почему вы настолько сильно настаиваете на этом, поскольку я еще лет пятнадцать тому обнаружил, что даже при написании первой версии даже небольшой программы всегда происходит некоторый возврат назад с переработкой архитектуры/кода. Не говоря уже про развитие программы. К этому настолько привыкаешь, что это кажестся само-сабой разумеющимся. Настолько, что говорить об этом то же самое, как говорить о необходимости дышать.
КЛ>Метод группировки разнородных сущностей. Ему посвящены этапы 1.3 и 2.2. Обычно группируют, находя похожие атрибуты и вынося их в базовые классы. В презентации говорится, что контекст для группировки нужно искать со стороны, т.е. не по похожести атрибутов, а потому, как и для чего объекты используются. КЛ>Этапы свертывания. В частности, то, что задание одинаковых интерфейсов для различных сущностей — первый шаг к дальнейшему их свертыванию. КЛ>То, что сначала нужно выявлять не классы/понятия, а действия. И проектировать конкретные структуры данных под эти операции (назовем их макро-операции или бизнес-функции).
Слова "обычно группируют", вполне возможно, имеют какой-то смысл в вашей конкретной обстановке. Вероятно, вы имеете все основания сказать: "Мы обычно смотрим на описание задачи, выделяем все существительные и объявляем, что каждому существительному будет соответствовать свой класс. А потом уже пытаемся заставить эти классы как-то взаимодействовать".
Мне повезло и на первом курсе преподаватель как-то сумел привить нам навыки структурного проектирования и модульного программирования (язык был подходящий, Turbo Pascal). Так вот там декомпозиция проводится именно по действиям и задачам, а структуры данных используются для переноса или накопления информации между действиями. Соответственно, переход к ООП произошел естественным образом -- ведь объект это не более чем объединение под одной крышей данных и кода, их обрабатывающего. При этом объекты не более чем еще один способ оформить те действия, которые программа должна выполнить. Посему лично я читая у Страуструпа или Буча описания классифицирования сущностей просто подразумеваю что рассматривается необходимость выделения объектов для выполнения конкретных действий. Т.е. все подчинено выполнению действий.
Так что я просто не понимаю, зачем акцент делается на выявление действий. Имхо, это и так понятно. Возможно, вам не повезло и вы работаете среди программистов, которым это не понятно. Ну что же, пусть так.
КЛ>То, что различия между объектами "надо продвигать вниз" (на нижние слои). КЛ>То, что нижние слои поглощают средние.
Несколько лет назад мне доводилось читать вполне серьезные и наукоподобные утверждения о том, что все в мире делится на двуполярные составляющие, а каждая составляющая состоит из трех частей. И т.о. в любом явлении есть шесть основных элементов. В качестве доказательств приводилось что-то из разряда задания цветов с помощью RGB.
Вот эти ваши два постулата напоминают мне тот наукоподобный текст.
E>>[i]** Не подразуевает ли это тчательную проработку use-case-ов? КЛ>Такую обтекаемую фразу можно понимать, как угодно. Я предпочитаю более точное указание.
Я имею в виду вот что: нельзя реализовать в программе то, что ты сам не понимаешь. А чтобы понять, нужно максимально полно представить себе все сценарии использования (use-case) будующей программы. А еще лучше -- стать ее пользователем и специалистом в конкретной прикладной области.
КЛ>Встречный вопрос. В части 3 своей книги (http://www.helloworld.ru/texts/comp/other/oop/) Гради Буч разбирает ряд конкретных задач. Не могли бы Вы показать, как, используя рекомендации Страуструпа, можно решить хоть одну из приведенных задач?
Мне не показалось что вы представляете себе объем предлагаемой мне задачи. Даже если взять первую из них, метеорологическую станцию, объем необходимой работы там составит не одну тысячу строк. Поскольку теоритизирование на бумаге или в форуме -- это одно, но оно мало чего стоит. Реально стоит только написанная программа, которую можно запустить и погонять под нагрузкой и в разных режимах. Для чего нужно спроектировать и написать не только ее, но и различные эмуляторы внешних устройств (т.н. тестовый стенд). Я не вижу абсолютно никаких стимулов к тому, чтобы заниматься этой работой.
Здесь с год назад IT какую-то проблему описывал с генерацией кода извлечения объектов разных типов из БД (не нашел, может кто подскажет). Интересно было бы и для этой задачи вашим способом решение увидеть.
Или вот еще: если же вы так уверены в собственной методике, то попробуйте ради хохмы изложить свое видение такой задачки: есть инструмент Mxx_ru
. Сейчас он заточен под C/C++. Мне требуется перепроектировать его под поддержку языка D, но так, чтобы в одном композитном проекте можно было сочетать C/C++ и D библиотеки, т.е. это означает, что C/C++ и D проекты нуждаются в разделении некоторой части параметров компиляции (например, т.к. RELEASE или DEBUG режим). Исходники здесь
Я это в качестве иллюстрации очень небольшой и даже не критически важной задачи, которая требует, тем не менее, серьезного проектирования. А большинству (в том числе и мне) по работе приходится заниматься намного более сложными и ответственными задачами, поверить в существование "идеальных" решений для которых лично мне не позволяет ни опыт, ни остатки здравого смысла.
И уж тем более поверить, что получение "идеальной системы" для сложных задач возможно с помощью какой-то конкретной методики... Вспоминая Страуструпа:
В проектировании и программировании не существует универсальных рецептов, которые могли бы заменить ум, опыт и хороший вкус.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
.
Ну тогда объясняйте — в сравнении с чем это у вас плотность ошибок скаканет и за счет чего? Неужто у вас в презентации расказанно как объем любого наперед взятого кода в 2-5 раз сократить? Ну ни в жисть не поверю. Хотите проверим? Давайте я вам сюда код приведу, а вы его хотя бы в два раза сократите?
Его в самом деле еще нет. Что будем делать? А? 