Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, FDSC, Вы писали:
FDS>>Тогда это не "ключевые параметры порядка", а упорядочивающие ключевые параметры
КЛ>Возможно, так будет лучше. Но термин "параметр порядка" предложен не мной, а отцом синергетики — Германом Хакеном. См. здесь.
Возможно, это просто неудачный перевод. Да и странно было бы думать, что все читали этого человека.
Re[10]: О наследовании, иерархиях и проектировании (философс
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, FDSC, Вы писали:
FDS>>Тогда это не "ключевые параметры порядка", а упорядочивающие ключевые параметры
КЛ>Возможно, так будет лучше. Но термин "параметр порядка" предложен не мной, а отцом синергетики — Германом Хакеном. См. здесь.
К сожалению, здесь вы вообще, как мне кажется, забыли о том, что параметр порядка, величина, как подразумевается в работе Хакена, численная. А вы предлагаете выбирать дискретные объекты. Да и вообще, тогда вы дублируете слово "ключевые" и словом "порядка", так как те параметры, которые ключевые, и есть параметры порядка. От других параметров поведение системы качественно не зависит. Но это к слову.
Главное: в системе, которая нам дана или которую мы разрабатываем, мы НЕ МОЖЕМ выбирать параметры порядка. Параметры порядка в разрабатываемой системе будут получаться сами собой и нам нужно их не выбирать, а исследовать и находить. Это ваша грубая ошибка в работе. Грубейшая. Если бы вы сказали, как найти такие параметры, как сделать так, что бы они совпадали с действительно значимыми параметрами моделируемой среды, как недопустить спонтанного появления новых, паразитирующих, параметров порядка, вот тогда ваша работа была бы, наверное, просто классической и её стали бы проходить в ВУЗе. Но у вас этого нет, да и не может быть.
Re[15]: О наследовании, иерархиях и проектировании (философс
Здравствуйте, Кирилл Лебедев, Вы писали:
V>>То, о чем вы говорите как раз и называется структурная декомпозииция. Почитайте Гриди Буча, он в самом начале своей книги по ООП разбирал именно два эти подхода, и наглядно, на примере какой-то задачи по обработке файлов демонстрировал недостатки структурной декомпозиции над объектно-ориентированной.
КЛ>О качестве некоторых архитектурных решений Гради Буча можно прочитать в этой статье.
Приводить в подтверждение своих слов собственную же статью -- это, безусловно, сильный дискуссионный прием.
КЛ>А в этом примере продемонстрирован классический пример иерархии, которая разработана исключительно для рисования. Т.е. целая иерархия классов разработана исключительно ради одного действия. В этом есть смысл, т.к. иерархия избавляет нас в коде от оператора if.
V>>Если же говорится не о декомпозиции уже поставленной и четко сформулированной задачи, а о непосредственно формулировании задачи (то есть определении того, куда копаем), то опять "все украдено до нас". Почитайте про Use Case'ы, не забывая при этом что они совершенно не противоречат ООП.
КЛ>Да, use cases используются. Но о том, как use case переводить в структуры данных не сказано ни где.
Да не нужно их переводить в структуры данных! Нужно построить модель, реализующие эти UC с заданными ограничениями. Как именно -- дело десятое, можно например итеративно: высосали из пальца -- приложили -- подточили -- еще раз приложили, и так до победного конца, можно как-то иначе.
Re: О наследовании, иерархиях и проектировании (философское)
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Ответу на этот вопрос и посвящена презентация «Проектирование игровых и бизнес-программ. Разработка архитектуры, устойчивой к изменениям», которая была показана на Конференции разработчиков игр 2007. В презентации демонстрируется, что понятие «идеальная программа» существует и в программировании, и что это понятие можно успешно использовать для решения задач проектирования.
Безотносительно к содержанию: приковыряйте туда кнопку "next" -- зачем заставлять пользователя искать в меню следующий пункт, тем более что текущий никак не выделяется.
Re[2]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, Eugene Kilachkoff, Вы писали:
EK>Безотносительно к содержанию: приковыряйте туда кнопку "next" -- зачем заставлять пользователя искать в меню следующий пункт, тем более что текущий никак не выделяется.
Спасибо. Сейчас по этой ссылке презентация выложена в виде отдельного файла PPT.
Признаться, вы заставили меня надолго задуматься.
ГВ>>Тогда вам, вероятно, не составит труда дать агрегированные характеристики проектов. Например, такие: КЛ>В основном, мне приходилось работать с проектами, размером от сотен клибайт до нескольких мегабайт.
КЛ>Продолжительность тоже разная. От месяца до года и т.д.
Я не зря упомянул об усреднённых цифрах. Средняя величина не колеблется в пределах "от" и "до". Она — единственная и неповторимая.
ГВ>>И, соответственно, сводку по эволюции проектов:
ГВ>>- Как изменились характеристики проектов после модификации (размеры до и после, сложности, соотношения в разрезе проектов и языков программирования); ГВ>>- Продолжительность циклов модификации; ГВ>>- Корреляция характеристик модификаций с усреднённым опытом команд.
КЛ>Обычно подобная статистика собирается после обкатки методики. Т.е. я ее не собирал.
А как же тогда обкатывать методику, если не собирать статистику в процессе обкатки?
КЛ>Во-первых, считаю, что рано.
То есть десятки (по вашим словам) проектов — это недостаточно для обкатки методики? Ну... в принципе, честь и хвала за такой подход. Но только я не понимаю — графики тогда откуда взялись?
КЛ>Во-вторых, и без того еще много задач, которые необходимо решить.
А вот это совершенно не важно. Вы предлагаете некий метод, для рекламы которого строите умопомрачительные графики, не подкреплённые статистикой.
Пока что всё это вместе называется наукообразием.
КЛ>Однако, если судить по эволюции проектов, которые правильно спроектированы (пусть даже и небольших), то можно увидеть следующее:
КЛ>1)... 2)... 3)...
"Правильно" — это как? По вашей методике? Или "вообще"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я не зря упомянул об усреднённых цифрах. Средняя величина не колеблется в пределах "от" и "до". Она — единственная и неповторимая.
Простите, но я в упор не понимаю, как проект, продолжительностью в год, можно "усреднить" до проекта, в продолжительностью в месяц.
Проекты разные, и об этом следует сказать.
ГВ>А как же тогда обкатывать методику, если не собирать статистику в процессе обкатки?
Я говорил о количественной статистике — она действительно не собиралась. Но ни что не мешает производить качественную оценку. А о ней я сказал. Методика позволяет:
а) Сократить код.
б) Существенно сократить количество багов (от 2 до 5).
в) Существенно упростить сопровождение (архитектура не разъезжается).
КЛ>>Во-первых, считаю, что рано.
ГВ>То есть десятки (по вашим словам) проектов — это недостаточно для обкатки методики? Ну... в принципе, честь и хвала за такой подход. Но только я не понимаю — графики тогда откуда взялись?
Опять-таки — я говорил о количественной оценке. Качественная оценка проводилась.
По поводу графиков... Их легко построить, сравнив количество классов (модулей, функций) в том или ином решении.
Приведенные в презентации графики ну никак не соотносятся с Вашими вопросами.
ГВ>А вот это совершенно не важно. Вы предлагаете некий метод, для рекламы которого строите умопомрачительные графики, не подкреплённые статистикой.
Мягко говоря, ложное утверждение. Вы спрашиваете об одном, а графики — совсем о другом. Это называется подмена понятия.
ГВ>"Правильно" — это как? По вашей методике? Или "вообще"?
Здравствуйте, FDSC, Вы писали:
FDS>А в этом примере уменьшения кода и нет.
Как же это нет? Даже первоклассник сможет сказать, что 1 класс — это меньше, чем 4 класса.
FDS>Здесь есть введение дополнительного абстрактного слоя, о чём я и говорю.
Давайте говорить предметно. Какой "абстрактный слой" появился благодаря сворачиванию 4-х "датчиков" в один?
FDS>Любая проблема архитектуры решается введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества абстрактных слоёв, если не ошибаюсь, именно это написано у кого-то из участников форума в подписи. Так что тут ничего нового. Никакого уменьшения ОБЪЁМА кода нет, а раз так, значит по прежнему могут возникнуть очень и очень острые проблемы побочных эффектов, неправильного понимания механизмов работы алгоритмов или неучтённых, но нужных информационных связей.
Как же это нет? Добавление промежуточного слоя как раз-таки уменьшает количество кода! Но только в пределах одного слоя. Просто "пухлый" код внутри одного слоя разносится по нескольким слоям.
Но это и есть решение проблемы сложности! Каждый слой от этого становится легче сопровождать! Никто вообще не говорил о том, что уменьшение объема кода должно неминуемо приводить к уменьшение количество character'ов!
FDS>Т.е. все проблемы остаются. Вы всего лишь пытаетесь научить общественность тому, что она уже умеет: пытаетесь сказать, что вот мол, ребята, давайте вводить более удобные интерфейсы. ДАВАЙТЕ, ДВУМЯ РУКАМИ ЗА!!!
По-своему, правильно. Но только кроме призывов, у меня содержатся еще и конкретные методы, как этой задачи достичь.
FDS>Мы можем сколько угодно давать абстрактные советы, но когда я сяду за новую систему, я, прочитав эти советы, всё равно буду проектировать по старому. Просто потому, что советы надо уметь и не забывать применять, а именно это и делается сплошь и рядом. Не из-за недостатка советов, а из-за недостатка понимания того, как вообще проектировать архитектуру.
О том, что проектированию надо учить, никто не возражает. Но учить проектированию легче, когда есть конкретные методы. Если методов нет, то и учить сложнее.
Кстати, почему это Вы называете мои конкретные советы абстрактными? Давайте говорить предметно. Какой из советов Вы считаете абстрактным? И что Вы в нем не понимаете?
Из презентации не понял, как именно вы предлагаете решать описанные проблемы.
Достаточно странная подачса материала , может файл битый ? В разделе теория распичвыется пример с сенсорами , в разделе практика даются расплывчаты рекомендаци.
Надеюсь может доклад был получше ?
P.S. Ваша манера вести диалог, мягко говоря не очень конструктивна (я по результатам ваших постов в этом форуме). Рекомендую проанализировать , и попробовать поменять на более конструктивную.
Здравствуйте, Кирилл Лебедев, Вы писали:
ГВ>>Я не зря упомянул об усреднённых цифрах. Средняя величина не колеблется в пределах "от" и "до". Она — единственная и неповторимая.
КЛ>Простите, но я в упор не понимаю, как проект, продолжительностью в год, можно "усреднить" до проекта, в продолжительностью в месяц.
Запросто. Путём сложения их метрик и деления суммы пополам.
КЛ>Проекты разные, и об этом следует сказать.
Можно разделить проанализированные проекты на группы.
ГВ>>А как же тогда обкатывать методику, если не собирать статистику в процессе обкатки?
КЛ>Я говорил о количественной статистике — она действительно не собиралась. Но ни что не мешает производить качественную оценку.
Качественную... Без количественных? В технической области?!
КЛ>А о ней я сказал. Методика позволяет:
КЛ>а) Сократить код. КЛ>б) Существенно сократить количество багов (от 2 до 5). КЛ>в) Существенно упростить сопровождение (архитектура не разъезжается).
То есть, выражение "сократить код" — это не количественная оценка? Сокращение количества багов — это тоже не количественная оценка?
КЛ>>>Во-первых, считаю, что рано.
ГВ>>То есть десятки (по вашим словам) проектов — это недостаточно для обкатки методики? Ну... в принципе, честь и хвала за такой подход. Но только я не понимаю — графики тогда откуда взялись?
КЛ>Опять-таки — я говорил о количественной оценке. Качественная оценка проводилась.
Так в том-то и фокус, что качественная оценка без количественных мер (пусть и подразумеваемых, но тогда они должны быть очевидными) вырождается в банальную вкусовщину: кому что более понятно, тот то и считает более коротким-компактным-простым.
КЛ>По поводу графиков... Их легко построить, сравнив количество классов (модулей, функций) в том или ином решении. КЛ>Приведенные в презентации графики ну никак не соотносятся с Вашими вопросами.
ГВ>>>>Вот эта картинка на основе каких данных получена?
КЛ>>>На основе анализа ряда примеров. Один из них приведен здесь. Но есть и другие.
ГВ>>Сколько их было всего? И ещё: что у вас по оси ординат?
КЛ>Сложность системы: количество модулей, классов и т.п.
Притом этот график вовсе не хухры-мухры, а аж "методический вывод"!
ГВ>>А вот это совершенно не важно. Вы предлагаете некий метод, для рекламы которого строите умопомрачительные графики, не подкреплённые статистикой.
КЛ>Мягко говоря, ложное утверждение. Вы спрашиваете об одном, а графики — совсем о другом. Это называется подмена понятия.
Хорошо, повторяю вопрос: о чём тогда сей одиозный график? Что у вас по оси ординат?
ГВ>>"Правильно" — это как? По вашей методике? Или "вообще"?
КЛ>Да.
Да = "по вашей методике"? Похоже, что так.
Но эти же наблюдения применимы и для правильного проектирования "вообще". То есть смысл проектирования — как раз в том, чтобы выделить неизменные элемены ПО и вынести их в некий фреймворк, каркас, структуру — назови хоть груздём. Иными словами, точь-в-точь то же самое можно сказать относительно любого проектирования, претендующего на "правильность"...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: О наследовании, иерархиях и проектировании (философс
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Из чего следует, что я зацикливаюсь на ООП? Наоборот, я считаю, что OOD — не лучшая методика проектирования.
Те существует методика которыя всегда лучше чем ООД?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, minorlogic, Вы писали:
M>P.S. Ваша манера вести диалог, мягко говоря не очень конструктивна (я по результатам ваших постов в этом форуме). Рекомендую проанализировать , и попробовать поменять на более конструктивную.
Вот давайте и перейдем к конструктивной манере. Думаю, это будет возможно, когда Вы конкретизируете свои претензии. Например, "в слайде № таком-то мне непонятно то-то" или "рекомендация № такая-то мне кажется слишком абстрактной".
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, FDSC, Вы писали:
FDS>>А в этом примере уменьшения кода и нет.
КЛ>Как же это нет? Даже первоклассник сможет сказать, что 1 класс — это меньше, чем 4 класса.
Вот именно, первоклассник скажет, что меньше. А программист знает, что и одна процедура может быть на 2000 строк.
FDS>>Здесь есть введение дополнительного абстрактного слоя, о чём я и говорю.
КЛ>Давайте говорить предметно. Какой "абстрактный слой" появился благодаря сворачиванию 4-х "датчиков" в один?
Давайте, к чему и призываю. Здесь http://www.triz-ri.ru/themes/kri_2007_lebedev-28.asp# у вас всё равно остаётся 3 класса на диаграмме. Вы просто ещё выставляете 4-ый класс, который работает с этими 3-мя.
FDS>>Любая проблема архитектуры решается введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества абстрактных слоёв, если не ошибаюсь, именно это написано у кого-то из участников форума в подписи. Так что тут ничего нового. Никакого уменьшения ОБЪЁМА кода нет, а раз так, значит по прежнему могут возникнуть очень и очень острые проблемы побочных эффектов, неправильного понимания механизмов работы алгоритмов или неучтённых, но нужных информационных связей.
КЛ>Как же это нет? Добавление промежуточного слоя как раз-таки уменьшает количество кода! Но только в пределах одного слоя. Просто "пухлый" код внутри одного слоя разносится по нескольким слоям.
Вот именно, что только в пределах одного слоя. И тут вы как раз вводите лишний слой, почему-то, в предыдущем сообщении, спрашивая меня где он.
КЛ>Но это и есть решение проблемы сложности! Каждый слой от этого становится легче сопровождать! Никто вообще не говорил о том, что уменьшение объема кода должно неминуемо приводить к уменьшение количество character'ов!
Уменьшение объёма кода и есть уменьшение количества операторов. Всё остальное, это упрощение интерфейса и т.п., но никак не уменьшение объёма кода. В вашей декларации, что идеальная система должна быть бесконечной простой и малой, вы как раз говорите о том, что кода в этой системе, в идеале, не должно существовать.
FDS>>Т.е. все проблемы остаются. Вы всего лишь пытаетесь научить общественность тому, что она уже умеет: пытаетесь сказать, что вот мол, ребята, давайте вводить более удобные интерфейсы. ДАВАЙТЕ, ДВУМЯ РУКАМИ ЗА!!!
КЛ>По-своему, правильно. Но только кроме призывов, у меня содержатся еще и конкретные методы, как этой задачи достичь.
Где? Я не заметил. Я не заметил ничего, что бы могло реально помочь проектированию. Вы вообще не смотрите на процесс проектирования как на итеративный процесс движения от версии к версии. Естественно, что очень просто советовать как нужно построить систему заново, но советовать нужно как её менять и как её строить так, что бы новая функциональность не мешала, что бы, скажем, можно было бы легко добавить ваш новый абстрактный слой.
С нуля система и будет такая, какую вы описали, если не лучше. Вопрос только в том, что это она будет с нуля, а на самом деле, в начале, она будет проектироваться не так и никакие лишние абстрактные слои ей нужны не будут, они будут именно лишними. А потом, по мере усложнения системы, разработчики и хватятся за голову — нужно то и сё переделывать. Но тогда ваши советы опять уже не помогут.
FDS>>Мы можем сколько угодно давать абстрактные советы, но когда я сяду за новую систему, я, прочитав эти советы, всё равно буду проектировать по старому. Просто потому, что советы надо уметь и не забывать применять, а именно это и делается сплошь и рядом. Не из-за недостатка советов, а из-за недостатка понимания того, как вообще проектировать архитектуру.
КЛ>О том, что проектированию надо учить, никто не возражает. Но учить проектированию легче, когда есть конкретные методы. Если методов нет, то и учить сложнее.
Я не увидел конкретных методов.
КЛ>Кстати, почему это Вы называете мои конкретные советы абстрактными? Давайте говорить предметно. Какой из советов Вы считаете абстрактным? И что Вы в нем не понимаете?
Я называю ваши советы абстрактными просто потому что я не увидел ничего, кроме названия этих советов в заголовках. Советы будут не абстрактными, когда они будут подкреплены реальной информацией и методикой их применения. Фактически у вас и советов то нет, только совсем уж очевидные, что давайте ребята делать более удобные интерфейсы, как я уже сказал. Всё, больше там советов нет.
Здравствуйте, Кирилл Лебедев, Вы писали:
M>>P.S. Ваша манера вести диалог, мягко говоря не очень конструктивна (я по результатам ваших постов в этом форуме). Рекомендую проанализировать , и попробовать поменять на более конструктивную.
КЛ>Вот давайте и перейдем к конструктивной манере. Думаю, это будет возможно, когда Вы конкретизируете свои претензии. Например, "в слайде № таком-то мне непонятно то-то" или "рекомендация № такая-то мне кажется слишком абстрактной".
Это довольно большой объём работы, сопоставимый с созданием самой презентации. Вы слишком многого хотите, сами-то поленились конкретику у себя описывать.
Я вам конкретизирую здесь, хотя меня вы просили в другой ветке
Свертывание
* Средство борьбы со сложностью
* Количество полезных функций, выполняемых «кодом», остается тем же, а количество структур данных, модулей сокращается
Объединены в один список неоднородные понятия. В одном вы поясняете, что это средство, а в другом поясняете результат. Затрудняет чтение. Кстати, довольно абстрактно, но дальше у вас подробнее расписывается.
http://www.triz-ri.ru/themes/kri_2007_lebedev-22.asp#
С какой стати датчики возвращают разные объекты и где это написано на схеме? http://www.triz-ri.ru/themes/kri_2007_lebedev-24.asp#
Далее, ввели конкретное решение для задачи, общие рекомендации не даны. Все эти "разные" объекты оказались по своей сути однородными и свелись к возвращению одного скаляра. А если один метод должен вернуть массив, а другой должен вернуть скаляр, третий матрицу 4х4? Какие у вас будут рекомендации, как их физически, в коде, объединить воедино? Это не сказано, вы можете, конечно, сейчас даже объяснить, как это делать, но ничего этого в презентации нет, т.е. свет абстрактный — "ребята, объединяйте объекты, вот видите, как у меня всё здорово". Я видел людей, которые на примере простых для исследования объектов показывают как у них всё замечательно, а как дело по сложнее, оказывается, что у них методика принципиально неправильная.
Например, альтернатива вашему подходу: функция вообще не должна возвращать объект или информацию. Она должна возвращать метод рассчёта поведения объекта.
http://www.triz-ri.ru/themes/kri_2007_lebedev-25.asp
Сгруппировали в массив и что? А какая дальше цель? Как обрабатывать значения, которые получены от этих датчиков если мы должны различать сущность информации? Где об этом говорится? Сгруппировать любой дурак может, но ведь на датчики ещё нужно реагировать и эта реакция может требовать именно учёта сущности информации, а не просто суммирования с коэффициентами
http://www.triz-ri.ru/themes/kri_2007_lebedev-27.asp
Дак что мы делаем? Те классы, которые были мы всё-таки не удаляем или удаляем? Свёртывать тут можно несколькими разными способами и ничего не сказано о том, как конкретно идёт свёртка здесь
http://www.triz-ri.ru/themes/kri_2007_lebedev-28.asp#
Опять же, что подразумевается под свёртыванием на уровне реализации и почему там такая-же UML-схема, как и на свёртке на уровне интерфесов?
Тут нет никакого свёртывания на уровне реализации вообще. Нет и в принципе не может быть, это терминологическая ошибка
http://www.triz-ri.ru/themes/kri_2007_lebedev-34.asp# и предыдущие два
Дак как же всё-таки разнородные веса объединяются в один???? КАК они обрабатываются. Как скорость и здоровье обрабатываются одной и той же функцией?
http://www.triz-ri.ru/themes/kri_2007_lebedev-43.asp#
Вообще не понятно, что тут надо делать, зачем и к чему. Зачем мне что-то мысленно увеличивать? Что бы представить себе дальнейшее развитие системы? Это совершенно не обязательно делать
Что значит "архитектура разъединяется"
http://www.triz-ri.ru/themes/kri_2007_lebedev-44.asp
Так и не объяснил, как это сделать. Обычно они вглубь не убираются именно по причине того, что не понятно, как это сделать, а не потому что вот все такие тупые.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Вот давайте и перейдем к конструктивной манере. Думаю, это будет возможно, когда Вы конкретизируете свои претензии. Например, "в слайде № таком-то мне непонятно то-то" или "рекомендация № такая-то мне кажется слишком абстрактной".
У меня нет претензий к вам и к вашей статье. Я просто прочел презентацию и высказал мнение о ней, думал вас именно это интересовало.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[15]: О наследовании, иерархиях и проектировании (философс
Здравствуйте, VladD2, Вы писали:
VD>Вообще-то это мошейничество. Бывают случае когда ОО-декомпозиция полнейший оверкил, а структрурная рулит. Бывает наоборот. Так что такой пример приведенный в качестве доказательства превосходства ОО-декомпозиции ни что иное как подлог.
Это не подлог!! Это... ммм... Тщательно отобранные факты, вот!
... << RSDN@Home 1.2.0 alpha rev. 673>>
Re[15]: О наследовании, иерархиях и проектировании (философс
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: О наследовании, иерархиях и проектировании (философск
Большое спасибо за проделанную работу! Возможно, ряд вопросов объясняются тем, что на html-страницах со слайдами показана статическая картинка. Сейчас по этой ссылке можно скачать презентацию целиком и посмотреть все в динамике.
Сравните это решение вот с этим. Неужели же непонятно, что в одном случаи "датчики" возвращают "машины", "power-up'ы" и "мины" (это отражено даже в названии функций), а в другом — "target'ы". Т.е. различные объекты приведены к единому типу.
Т.е. важно не просто "тупое" объединение классов в иерархию, но и выбор такой "точки зрения", с которой различия между названными объектами не важны. Это-то и позволило создать обобщенный класс CTarget.
FDS>http://www.triz-ri.ru/themes/kri_2007_lebedev-22.asp# FDS>С какой стати датчики возвращают разные объекты и где это написано на схеме?
В названии функций — health, score и position. При этом, тип данных может быть один и тот же (например, float), но семантически это разные объекты.
Но, согласен, в тексте это можно было подчеркнуть.
FDS>http://www.triz-ri.ru/themes/kri_2007_lebedev-24.asp# FDS>Далее, ввели конкретное решение для задачи, общие рекомендации не даны. Все эти "разные" объекты оказались по своей сути однородными и свелись к возвращению одного скаляра. А если один метод должен вернуть массив, а другой должен вернуть скаляр, третий матрицу 4х4? Какие у вас будут рекомендации, как их физически, в коде, объединить воедино? Это не сказано, вы можете, конечно, сейчас даже объяснить, как это делать, но ничего этого в презентации нет, т.е. свет абстрактный — "ребята, объединяйте объекты, вот видите, как у меня всё здорово". Я видел людей, которые на примере простых для исследования объектов показывают как у них всё замечательно, а как дело по сложнее, оказывается, что у них методика принципиально неправильная.
О том, как решать такие задачи, сказано здесь, здесь и здесь.
В соответствии с приведенными рекомендациями, нужно:
Посмотреть только на различия (т.е. на разные объекты, которые возвращают методы).
Задать вопрос: "А для чего мы используем полученные объекты? Что мы делаем с полученными объектами дальше?"
Вот это-то дальше как раз и задаст критерии, которые важны, и позволит отбросить критерии, которые не важны.
FDS>Например, альтернатива вашему подходу: функция вообще не должна возвращать объект или информацию. Она должна возвращать метод рассчёта поведения объекта.
Как раз-таки и вовсе не альтернатива, а полное следование моему подходу. То, что должна возвращать функция, задается дальнейшей задачей, ради которой мы, собственно говоря, и получаем объекты.
FDS>http://www.triz-ri.ru/themes/kri_2007_lebedev-25.asp FDS>Сгруппировали в массив и что? А какая дальше цель? Как обрабатывать значения, которые получены от этих датчиков если мы должны различать сущность информации? Где об этом говорится? Сгруппировать любой дурак может, но ведь на датчики ещё нужно реагировать и эта реакция может требовать именно учёта сущности информации, а не просто суммирования с коэффициентами
Об учете сущности информации говорится здесь, здесь и голосом .
FDS>http://www.triz-ri.ru/themes/kri_2007_lebedev-27.asp FDS>Дак что мы делаем? Те классы, которые были мы всё-таки не удаляем или удаляем? Свёртывать тут можно несколькими разными способами и ничего не сказано о том, как конкретно идёт свёртка здесь
Было 2 иерархии. Осталось 2 класса. Что непонятного?
FDS>http://www.triz-ri.ru/themes/kri_2007_lebedev-28.asp# FDS>Опять же, что подразумевается под свёртыванием на уровне реализации и почему там такая-же UML-схема, как и на свёртке на уровне интерфесов? FDS>Тут нет никакого свёртывания на уровне реализации вообще. Нет и в принципе не может быть, это терминологическая ошибка
Почему такая же? Сверху изображена иерархия классов. Снизу — один класс. К тому же, он имеет другое название. И не помечен, как абстрактный. А интерфейс у него и не должен был поменяться, т.к. изменения происходят на уровне реализации. Интерфейс-то остается тем же.
FDS>http://www.triz-ri.ru/themes/kri_2007_lebedev-34.asp# и предыдущие два FDS>Дак как же всё-таки разнородные веса объединяются в один???? КАК они обрабатываются. Как скорость и здоровье обрабатываются одной и той же функцией?
Только не скорость, а количество набранных очков.
Об этом я уже написал выше. Но здесь поясню. В частности, то, что было сказано голосом.
Нам количество набранных очков и здоровье были нужны не сами по себе, а для выполнения какой-то задачи. Применительно к AI-водителю, правила использования количества набранных очков и здоровья могут формулироваться так:
1) Если здоровья маловато, AI должен отклоняться за power-up'ом здоровья.
2) Если набранных очков маловато, AI должен отклоняться за power-up'ом, добавляющим очки.
Т.е. нужен был некий вес, говорящий о том, маловато нам этого (здоровья, набранных очков и т.п.) или достаточно. Этот вес, помимо величины, мог так же содержать тип характеристики, весом которой он является (здоровья, набранных очков). Этот тип можно задать флагом.
В алгоритме выбора направления движения учитываются потребности AI (в виде весов) и лежащие объекты на трассе. Но этому алгоритму совершенно не нужно иметь дело с реальными объектами — минами, машинами и power-up'ами. Ему достаточно представления этих объектов в виде набора объектов CTarget.
FDS>http://www.triz-ri.ru/themes/kri_2007_lebedev-38.asp FDS>А что, мы раньше не формулировали???? Замечательная рекомендация! Это студентам первого курса такую давать надо
Вы ради разнообразия зайдите как-нибудь на форум "Архитектура" и посмотрите, какие вопросы задают люди,приступающие к проектированию.
Здравствуйте, Кирилл Лебедев, Вы писали:
FDS>>http://www.triz-ri.ru/themes/kri_2007_lebedev-18.asp# FDS>>Очевидное предложение: группа классов объединяется в иерархию.
КЛ>Сравните это решение вот с этим. Неужели же непонятно, что в одном случаи "датчики" возвращают "машины", "power-up'ы" и "мины" (это отражено даже в названии функций), а в другом — "target'ы". Т.е. различные объекты приведены к единому типу.
КЛ>Т.е. важно не просто "тупое" объединение классов в иерархию, но и выбор такой "точки зрения", с которой различия между названными объектами не важны. Это-то и позволило создать обобщенный класс CTarget.
Когда классы объединяются в иерархию всегда выбирается такая точка зрения, с которой различия приводятся к "похожестям", иначе что же это за иерархия?
FDS>>http://www.triz-ri.ru/themes/kri_2007_lebedev-24.asp# FDS>>Далее, ввели конкретное решение для задачи, общие рекомендации не даны. Все эти "разные" объекты оказались по своей сути однородными и свелись к возвращению одного скаляра. А если один метод должен вернуть массив, а другой должен вернуть скаляр, третий матрицу 4х4? Какие у вас будут рекомендации, как их физически, в коде, объединить воедино? Это не сказано, вы можете, конечно, сейчас даже объяснить, как это делать, но ничего этого в презентации нет, т.е. свет абстрактный — "ребята, объединяйте объекты, вот видите, как у меня всё здорово". Я видел людей, которые на примере простых для исследования объектов показывают как у них всё замечательно, а как дело по сложнее, оказывается, что у них методика принципиально неправильная.
КЛ>О том, как решать такие задачи, сказано здесь, здесь и здесь.
КЛ>В соответствии с приведенными рекомендациями, нужно:
КЛ> КЛ>Посмотреть только на различия (т.е. на разные объекты, которые возвращают методы). КЛ>Задать вопрос: "А для чего мы используем полученные объекты? Что мы делаем с полученными объектами дальше?" КЛ>Вот это-то дальше как раз и задаст критерии, которые важны, и позволит отбросить критерии, которые не важны. КЛ>
Вот-вот. Поэтому я и говорю, что ваши советы абстрактны. Не рассмотрены вот эти самые варианты "для чего" и соотв. объединения. Не рассмотрено как раз то, что вызывает трудности. Не рассмотрены конкретные советы КАК объединять, а общий совет обычно или очевиден, или настолько закопан, что о нём никто не вспомнит.
Т.е. практическую ценность ваш совет бы обрёл, когда вы бы посоветовали на нескольких сложных примерах, как выделять общее зерно классов, а ещё лучше, дали бы какой-то алгоритм, структуру, по которой это можно было бы делать формально.
FDS>>http://www.triz-ri.ru/themes/kri_2007_lebedev-25.asp FDS>>Сгруппировали в массив и что? А какая дальше цель? Как обрабатывать значения, которые получены от этих датчиков если мы должны различать сущность информации? Где об этом говорится? Сгруппировать любой дурак может, но ведь на датчики ещё нужно реагировать и эта реакция может требовать именно учёта сущности информации, а не просто суммирования с коэффициентами
КЛ>Об учете сущности информации говорится здесь, здесь и голосом .
Об этом там не говорится. Там не говорится, что делать, если не получается сгруппировать все обратные связи в однотипный массив. Там даже не говорится, по какой формуле вы сами обрабатываете информацию, как учитываете различия в семантике получаемых вещественных значений. Куда они затем идут.
Вы даже не показали ваше решение полно. Я его искал, но даже в конце, на страницах "Выбор направления движения" ничего не сказано о том, как вы обрабатываете разнотипную инфомацию. Такое впечатление что это очень очевидно и легко, хотя это не так, если задача хоть чуть-чуть сложная.
FDS>>http://www.triz-ri.ru/themes/kri_2007_lebedev-27.asp FDS>>Дак что мы делаем? Те классы, которые были мы всё-таки не удаляем или удаляем? Свёртывать тут можно несколькими разными способами и ничего не сказано о том, как конкретно идёт свёртка здесь
КЛ>Было 2 иерархии. Осталось 2 класса. Что непонятного?
Вот именно. Здесь у вас осталось два класса, а вот тут http://www.triz-ri.ru/themes/kri_2007_lebedev-30.asp# у вас снова появилась иерархия, просто с дополнительным абстрактным слоем. Т.е. 27-ой слайд неправильно показывает сущность свёртки как внесения абстрактного слоя. Ничего мы в те два класса не выносим, мы только делаем этими двумя классами новый интерфейс.
FDS>>http://www.triz-ri.ru/themes/kri_2007_lebedev-28.asp# FDS>>Опять же, что подразумевается под свёртыванием на уровне реализации и почему там такая-же UML-схема, как и на свёртке на уровне интерфесов? FDS>>Тут нет никакого свёртывания на уровне реализации вообще. Нет и в принципе не может быть, это терминологическая ошибка
КЛ>Почему такая же? Сверху изображена иерархия классов. Снизу — один класс. К тому же, он имеет другое название. И не помечен, как абстрактный. А интерфейс у него и не должен был поменяться, т.к. изменения происходят на уровне реализации. Интерфейс-то остается тем же.
Вот и возникает вопрос, как это согласуется с 30-ым слайдом. Реализацию-то вы оставили в тех классах, которые были, вы же её не впихнули в один класс. А если впихнули, то: 1. 30-ый слайд неправилен, 2. каким образом это приводит к уменьшению сложности непонятно, ведь этот класс должен включать все методы классов, которые он заменил, т.е. нужно расписать, что вы сделали с этими классами
FDS>>http://www.triz-ri.ru/themes/kri_2007_lebedev-34.asp# и предыдущие два FDS>>Дак как же всё-таки разнородные веса объединяются в один???? КАК они обрабатываются. Как скорость и здоровье обрабатываются одной и той же функцией?
КЛ>Только не скорость, а количество набранных очков.
КЛ>Об этом я уже написал выше. Но здесь поясню. В частности, то, что было сказано голосом.
КЛ>Нам количество набранных очков и здоровье были нужны не сами по себе, а для выполнения какой-то задачи. Применительно к AI-водителю, правила использования количества набранных очков и здоровья могут формулироваться так:
КЛ>1) Если здоровья маловато, AI должен отклоняться за power-up'ом здоровья. КЛ>2) Если набранных очков маловато, AI должен отклоняться за power-up'ом, добавляющим очки.
КЛ>Т.е. нужен был некий вес, говорящий о том, маловато нам этого (здоровья, набранных очков и т.п.) или достаточно. Этот вес, помимо величины, мог так же содержать тип характеристики, весом которой он является (здоровья, набранных очков). Этот тип можно задать флагом.
КЛ>В алгоритме выбора направления движения учитываются потребности AI (в виде весов) и лежащие объекты на трассе. Но этому алгоритму совершенно не нужно иметь дело с реальными объектами — минами, машинами и power-up'ами. Ему достаточно представления этих объектов в виде набора объектов CTarget.
Замечательно. Тут я получил один ответ.
Но, как же всё-таки быть, когда мне нужно в алгоритме учесть разнородные параметры. Скажем, мне нужно обработать не только целевые факторы, но и возможность их достижения, которая описывается, скажем, массивом матриц 4х4? Что мне делать, если у меня появится ещё одна группа параметров, но это будет уже, скажем, массив матриц 3х3 или, скажем, массив массивов? Как мне объединить эти группы разнородных параметров в один?
FDS>>http://www.triz-ri.ru/themes/kri_2007_lebedev-38.asp FDS>>А что, мы раньше не формулировали???? Замечательная рекомендация! Это студентам первого курса такую давать надо
КЛ>Вы ради разнообразия зайдите как-нибудь на форум "Архитектура" и посмотрите, какие вопросы задают люди,приступающие к проектированию.
Мммм. Ну, значит, такие вопросы там задают студенты первого курса .
Тут тоже вопрос, для каких людей вы писали эту презентацию. Если для студентов, тогда ладно. Причём для довольно слабых студентов.
Средняя величина не колеблется в пределах "от" и "до". Она — единственная и неповторимая. 
.