Re[9]: О наследовании, иерархиях и проектировании (философск
От: prVovik Россия  
Дата: 20.04.07 12:24
Оценка: +1
Здравствуйте, Кирилл Лебедев, Вы писали:


КЛ>Не смешивайте два разных понятия: бизнес-функция и функция языка программирования. Я говорю о первой.


Ок, тогда не смешивайте понятия объектно-ориентированного программирования и Use-Case'ов, ибо первые отлично уживаются со вторыми
лэт ми спик фром май харт
Re[10]: О наследовании, иерархиях и проектировании (философс
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 20.04.07 12:27
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Здравствуйте, Кирилл Лебедев, Вы писали:



КЛ>>Не смешивайте два разных понятия: бизнес-функция и функция языка программирования. Я говорю о первой.


V>Ок, тогда не смешивайте понятия объектно-ориентированного программирования и Use-Case'ов, ибо первые отлично уживаются со вторыми


А где Вы заметили смешивание?
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[11]: О наследовании, иерархиях и проектировании (философс
От: prVovik Россия  
Дата: 20.04.07 12:31
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:


КЛ>А где Вы заметили смешивание?


Здесь:


КЛ>Я же предлагаю ориентироваться не на объекты, а на действия. И проектировать структуры данных, модули под эти действия.


Проектировать программу вполне можно (и нужно!) согласно Use-Case'ам, но ориентируясь при этом на объекты.
лэт ми спик фром май харт
Re[8]: О наследовании, иерархиях и проектировании (философск
От: IT Россия linq2db.com
Дата: 20.04.07 12:38
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Имхо, тут присутствует некорректное понимание сложности. Мое мнение таково, что сложность невозможно адекватно измерить простыми метриками. Сложность — это количество реализованных идей.


Какое отношение количество идей имеет к сложности кода?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: О наследовании, иерархиях и проектировании (философс
От: IT Россия linq2db.com
Дата: 20.04.07 12:38
Оценка:
Здравствуйте, ZevS, Вы писали:

ZS>В своем первом сообщении я как раз и сказал о том, что надо бороться за качество, а не размер.


Безусловно.

ZS>Уменьшение размера — побочный положительный эффект.


При этом получается, что компактный и понятный код практически всегда легко менять
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: О наследовании, иерархиях и проектировании (философск
От: IT Россия linq2db.com
Дата: 20.04.07 12:43
Оценка:
Здравствуйте, ZevS, Вы писали:

IT>>В теории? возможно? это так, с теоретиками не буду спорить. Но на практике же оказывается, что в 99% связь между лаконичностью и простотой кода практически прямая. А в случае кода безнес логики это справедливо на 120%.


ZS>Короткие лаконичные программы на Perl просто ужасны.


На перле не пишу. То с чем приходилось сталкиваться вызывало разные чувства. Хорошо отформатированный и откоментированный код не вызывал никаких затруднений при чтении. Квадратные программы (80 строк на 80 символов без единого пробела и пробельной строки) вызывали лёгкий озноб.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: О наследовании, иерархиях и проектировании (философс
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 20.04.07 12:49
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Проектировать программу вполне можно (и нужно!) согласно Use-Case'ам, но ориентируясь при этом на объекты.


В том-то и дело, что я как раз предлагаю обратное: ориентироваться не на объекты, а на действия и проектировать эти объекты под необходимые действия.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[13]: О наследовании, иерархиях и проектировании (философс
От: prVovik Россия  
Дата: 20.04.07 12:59
Оценка: +1
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>В том-то и дело, что я как раз предлагаю обратное: ориентироваться не на объекты, а на действия и проектировать эти объекты под необходимые действия.


То, о чем вы говорите как раз и называется структурная декомпозииция. Почитайте Гриди Буча, он в самом начале своей книги по ООП разбирал именно два эти подхода, и наглядно, на примере какой-то задачи по обработке файлов демонстрировал недостатки структурной декомпозиции над объектно-ориентированной.

Если же говорится не о декомпозиции уже поставленной и четко сформулированной задачи, а о непосредственно формулировании задачи (то есть определении того, куда копаем), то опять "все украдено до нас". Почитайте про Use Case'ы, не забывая при этом что они совершенно не противоречат ООП.
лэт ми спик фром май харт
Re[8]: О наследовании, иерархиях и проектировании (философск
От: IT Россия linq2db.com
Дата: 20.04.07 13:04
Оценка: +2
Здравствуйте, prVovik, Вы писали:

IT>>В теории? возможно? это так, с теоретиками не буду спорить. Но на практике же оказывается, что в 99% связь между лаконичностью и простотой кода практически прямая.


V>Поковыряй какой-нибудь boost. Там код весьма лаконичен, но вот простой ли он?


Сложность буста является прямым следствием неоднозначности и кривизны идей, на которых он базируется. Но сам по себе буст — это пол беды. В конце концов запутанность библиотечного кода не так критична. Хуже то, что использование буста порождает таких же уродцев как и он сам.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: О наследовании, иерархиях и проектировании (философс
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 20.04.07 13:12
Оценка:
Здравствуйте, prVovik, Вы писали:

V>То, о чем вы говорите как раз и называется структурная декомпозииция. Почитайте Гриди Буча, он в самом начале своей книги по ООП разбирал именно два эти подхода, и наглядно, на примере какой-то задачи по обработке файлов демонстрировал недостатки структурной декомпозиции над объектно-ориентированной.


О качестве некоторых архитектурных решений Гради Буча можно прочитать в этой статье.

А в этом примере продемонстрирован классический пример иерархии, которая разработана исключительно для рисования. Т.е. целая иерархия классов разработана исключительно ради одного действия. В этом есть смысл, т.к. иерархия избавляет нас в коде от оператора if.

V>Если же говорится не о декомпозиции уже поставленной и четко сформулированной задачи, а о непосредственно формулировании задачи (то есть определении того, куда копаем), то опять "все украдено до нас". Почитайте про Use Case'ы, не забывая при этом что они совершенно не противоречат ООП.


Да, use cases используются. Но о том, как use case переводить в структуры данных не сказано ни где.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[5]: О наследовании, иерархиях и проектировании (философск
От: FDSC Россия consp11.github.io блог
Дата: 20.04.07 14:28
Оценка: +1
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, FDSC, Вы писали:


FDS>>Ну и как же применять ваши принципы с точки зрения наследования квадрата от прямоугольника?


КЛ>Мне кажется, что ответ дан в этом слайде, а конкретный пример приведен здесь.


КЛ>На всякий случай, еще поясню здесь. Мне кажется, что вопрос, следует ли выводить квадрат из прямоугольника или прямоугольник из квадрата не имеет смысла вне контекста использования иерархии. Т.е. сначала нужно определить, для чего пишется иерархия (и от чего она позволяет абстрагироваться), а затем уже решать, какой класс из чего выводить. А вот задача-то иерархии в упомнутом обсуждении как раз и не прозвучала.


КЛ>Еще конкретнее. Если мы пишем иерархию, чтобы упростить рисование, то нафига нам понадобилось добавлять в класс прямоугольника методы SetWidth() и SetHeight(), а в класс квадрата — метод SetSide()? А если — не для рисования, то тогда для чего вообще городится эта иерархия? Какую задачу она решает? И какой код помогает упростить?


Если бы вы внимательно прочитали ту тему, ссылку на которую сами и привели, то увидели бы, что именно это я и говорю в обсуждении. Так что ваш аргумент абсолютно не верен, так как вы привели пример, где сказали, что кому-то что-то в голову не пришло, а в голову там всё, может быть и не всем, но пришло.
Re[5]: О наследовании, иерархиях и проектировании (философск
От: FDSC Россия consp11.github.io блог
Дата: 20.04.07 14:34
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

[]

КЛ>Вот пример реального обсуждения, где "не пронеслось".


Вы не удосужилисть даже посмотреть внимательно эту тему
ПЕРВЫЙ же ответ (кстати, мой) указывал на правильный с вашей точки зрения ответ
http://rsdn.ru/Forum/Message.aspx?mid=2392333&amp;only=1
Автор: FDSC
Дата: 03.03.07


Этот ответ — кстати, мой. Так что очень странно, что вы вообще лично МНЕ же теперь говорите о том, что это неочевидно. Может мне вас в плагиате обвинить?
Re[3]: О наследовании, иерархиях и проектировании (философск
От: FDSC Россия consp11.github.io блог
Дата: 20.04.07 14:39
Оценка: 3 (1) -1 :)
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Кроме того, рекомендую прочесть еще вот это
Автор: Кирилл Лебедев
Дата: 16.02.07
сообщение.


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


КЛ>Если пример "очевиден", то:


КЛ>

    КЛ>
  1. Почему участники обсуждения
    Автор: igna
    Дата: 03.03.07
    так и не пришли к "очевидному" решению, которое описано в презентации?

    Да потому что Я В ПЕРВОМ СООБЩЕНИИ СКАЗАЛ это решение. В ПЕРВОМ СООБЩЕНИИ, потрудитесь его прочитать!!!!!!!!!!!!!!!!!!!!

    КЛ>
  2. Почему Вы не уловили связь между задачей, изложенной в презентации, и обсуждением про квадрат и прямоугольник
    Автор: igna
    Дата: 03.03.07
    ? На мой взгляд, эта связь тоже очевидна.
    КЛ>

Потому что эта презентация полное говно. Вместо того, что бы рассказать, что вы предлагаете в общем, вы совершенно занудно рассказываете что вы делали конкретно. Это ужасно! Это невозможно читать! Да ещё и постоянно жать "далее..."
Re[3]: О наследовании, иерархиях и проектировании (философск
От: FDSC Россия consp11.github.io блог
Дата: 20.04.07 14:44
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, FDSC, Вы писали:


FDS>>Угу, очень точное, понятное и развёрнутое описание задач


КЛ>Для приведенного в презентации примера подходит. Там сказано, что это — одна из задач. У меня не было цели рассказывать обо всех задачах, с которыми сталкивается программист при проектировании AI.


FDS>>Фактически это предложение по введению дополнительных абстрактых слоёв. Не помню, у кого-то в подписи стоит по этому поводу


КЛ>Слои не только добавляются, но и схлопываются. Об этом сказано здесь.


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



FDS>>Где тут новая методика? Где тут вообще методика?


КЛ>Например, здесь, здесь и здесь демонстрируются конкретные методы унификации различий и сокращения кода.


КЛ>Я прочитал и просмотрел достаточное количество книжек по проектированию. И описаний этих методов там не заметил.


Есть такое понятие, как очевидность и изобретательский уровень.



FDS>>Всё уже давно всем известно на интуитивном уровне


КЛ>Это все слова, слова... Разберите конкретную задачу хотя бы из тех, что обсуждаются на форуме "Архитектура". И тогда можно будет посмотреть, как эта задача решается без методики и как — с методикой.


Разберите конкретную задачу и посмотрите, помогут ли в её решении ваши принципы.
Re[4]: А объяснить минус?
От: FDSC Россия consp11.github.io блог
Дата: 20.04.07 14:48
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, Кирилл Лебедев, Вы писали:


КЛ>>Кроме того, рекомендую прочесть еще вот это
Автор: Кирилл Лебедев
Дата: 16.02.07
сообщение.


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


КЛ>>Если пример "очевиден", то:


КЛ>>

    КЛ>>
  1. Почему участники обсуждения
    Автор: igna
    Дата: 03.03.07
    так и не пришли к "очевидному" решению, которое описано в презентации?

    Да потому что Я В ПЕРВОМ СООБЩЕНИИ СКАЗАЛ это решение. [b]В ПЕРВОМ СООБЩЕНИИ, потрудитесь его прочитать!!!!!!!!!!!!!!!!!!!! [/b]


    КЛ>>
  2. Почему Вы не уловили связь между задачей, изложенной в презентации, и обсуждением про квадрат и прямоугольник
    Автор: igna
    Дата: 03.03.07
    ? На мой взгляд, эта связь тоже очевидна.
    КЛ>>

FDS>Потому что эта презентация полное говно. Вместо того, что бы рассказать, что вы предлагаете в общем, вы совершенно занудно рассказываете что вы делали конкретно. Это ужасно! Это невозможно читать! Да ещё и постоянно жать "далее..."
Re[6]: О наследовании, иерархиях и проектировании (философск
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 20.04.07 14:49
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Если бы вы внимательно прочитали ту тему, ссылку на которую сами и привели, то увидели бы, что именно это я и говорю в обсуждении. Так что ваш аргумент абсолютно не верен, так как вы привели пример, где сказали, что кому-то что-то в голову не пришло, а в голову там всё, может быть и не всем, но пришло.


Да, Ваша мысль, изложенная там, правильна. Но решения — в коде — Вы там так и не привели.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[6]: О наследовании, иерархиях и проектировании (философск
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 20.04.07 14:51
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Этот ответ — кстати, мой. Так что очень странно, что вы вообще лично МНЕ же теперь говорите о том, что это неочевидно. Может мне вас в плагиате обвинить?


Ваша правильная, в принципе, мысль не вылилась в том обсуждении в конкретное решение. Больше запомнились ненужные нагромождения интерфейсов.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[7]: О наследовании, иерархиях и проектировании (философск
От: FDSC Россия consp11.github.io блог
Дата: 20.04.07 14:52
Оценка: +1
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, FDSC, Вы писали:


FDS>>Если бы вы внимательно прочитали ту тему, ссылку на которую сами и привели, то увидели бы, что именно это я и говорю в обсуждении. Так что ваш аргумент абсолютно не верен, так как вы привели пример, где сказали, что кому-то что-то в голову не пришло, а в голову там всё, может быть и не всем, но пришло.


КЛ>Да, Ваша мысль, изложенная там, правильна. Но решения — в коде — Вы там так и не привели.


А какое может быть решение в коде в абстрактной задаче?
Дайте мне конкретику, я вам сделаю её решение
Re[5]: А объяснить минус?
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 20.04.07 14:53
Оценка: +2 -3
Будьте вежливы
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[6]: А объяснить минус?
От: FDSC Россия consp11.github.io блог
Дата: 20.04.07 14:57
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Будьте вежливы


А по существу?

FDS>Потому что эта презентация полное говно. Вместо того, что бы рассказать, что вы предлагаете в общем, вы совершенно занудно рассказываете что вы делали конкретно. Это ужасно! Это невозможно читать! Да ещё и постоянно жать "далее..."
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.