Здравствуйте, FDSC, Вы писали:
FDS>Потому что эта презентация полное говно. Вместо того, что бы рассказать, что вы предлагаете в общем, вы совершенно занудно рассказываете что вы делали конкретно. Это ужасно! Это невозможно читать! Да ещё и постоянно жать "далее..."
Не судите о других людях по себе. То, что Вам очевидно, другим людям вполне может быть неочевидно. Если бы Вы знали, сколько человек городят код такого вида. При чем это делают, опытные программисты, у которых десять и более лет опыт за плечами.
Не забывайте так же о том, что задача выступления — показать закономерность. И каждое изложенное решение — лишь этап в этой закономерности.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, FDSC, Вы писали:
FDS>>Потому что эта презентация полное говно. Вместо того, что бы рассказать, что вы предлагаете в общем, вы совершенно занудно рассказываете что вы делали конкретно. Это ужасно! Это невозможно читать! Да ещё и постоянно жать "далее..."
КЛ>Не судите о других людях по себе. То, что Вам очевидно, другим людям вполне может быть неочевидно. Если бы Вы знали, сколько человек городят код такого вида. При чем это делают, опытные программисты, у которых десять и более лет опыт за плечами.
КЛ>Не забывайте так же о том, что задача выступления — показать закономерность. И каждое изложенное решение — лишь этап в этой закономерности.
Ну, в общем, вы правы. Просто тут презентация БЕЗ выступления
Re[4]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>А что не так в "ключевых параметрах"?
Смысл. Ключевые параметры — это параметры имеющие исключительно важные значения. А то о чем говоришь ты — это нечто используемое в качестве ключа сортировки.
Вообщем, чем срашивать лучше прочти статью.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, FDSC, Вы писали:
FDS>А какое может быть решение в коде в абстрактной задаче? FDS>Дайте мне конкретику, я вам сделаю её решение
Понимаете, конкретная задача — лишь один из способов получить решение. По сути дела, о чем нам говорит задача? О том, что конкретная архитектура (конкретный класс или иерархия) не удовлетворяет заданным требованиям и эту архитектуру надо бы переделать. Но для того, чтобы переделать (или спроектировать) архитектуру вовсе необязательно сталкиваться с реальной задачей. Если программист знает закономерность, изложенную в презентации, он знает, что рано или поздно вся иерархия фигур свернется в один класс. Поэтому, возможно, вообще не надо решать вопрос о том, как правильнее — выводить квадрат из прямоугольника или прямоугольник из квадрата.
Скорее всего, этот общий класс фигуры будет основан на понятии пути (последовательности сегментов прямых линий и кривых Безье 3-го порядка). Если же к изложенному еще добавить закон динамизации, который в презентации не изложен, то рано или поздно простое описание фигуры в виде пути перейдет в параметрическое. Т.е. у фигуры появятся какие-то параметры, изменяя которые, пользователь сможет изменять форму и размеры фигуры. Например, для окружности таким параметром станет радиус, для квадрата — сторона, для прямоугольника — высота и ширина. И т.д.
Заметьте, все эти выводы можно сделать, зная закономерность. И совсем не касаясь конкретных задач.
Здравствуйте, VladD2, Вы писали:
VD>Смысл. Ключевые параметры — это параметры имеющие исключительно важные значения. А то о чем говоришь ты — это нечто используемое в качестве ключа сортировки.
Нет, я использую термин в первом значении. Не во втором. Ключ сортировки тут в общем-то не при чем.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, FDSC, Вы писали:
FDS>>А какое может быть решение в коде в абстрактной задаче? FDS>>Дайте мне конкретику, я вам сделаю её решение
КЛ>Понимаете, конкретная задача — лишь один из способов получить решение. По сути дела, о чем нам говорит задача? О том, что конкретная архитектура (конкретный класс или иерархия) не удовлетворяет заданным требованиям и эту архитектуру надо бы переделать. Но для того, чтобы переделать (или спроектировать) архитектуру вовсе необязательно сталкиваться с реальной задачей. Если программист знает закономерность, изложенную в презентации, он знает, что рано или поздно вся иерархия фигур свернется в один класс. Поэтому, возможно, вообще не надо решать вопрос о том, как правильнее — выводить квадрат из прямоугольника или прямоугольник из квадрата.
КЛ>Скорее всего, этот общий класс фигуры будет основан на понятии пути (последовательности сегментов прямых линий и кривых Безье 3-го порядка). Если же к изложенному еще добавить закон динамизации, который в презентации не изложен, то рано или поздно простое описание фигуры в виде пути перейдет в параметрическое. Т.е. у фигуры появятся какие-то параметры, изменяя которые, пользователь сможет изменять форму и размеры фигуры. Например, для окружности таким параметром станет радиус, для квадрата — сторона, для прямоугольника — высота и ширина. И т.д.
КЛ>Заметьте, все эти выводы можно сделать, зная закономерность. И совсем не касаясь конкретных задач.
И заметьте, что при этом простота использования и очевидность интерфейсов классов существенно упадёт. Так же, повысится сложность самого класса параметрической фигуры.
Если разрабатываемое приложение не такое сложное, то необходимость наследования может возникнуть, мало того, должна возникнуть, если только это приложение с самого начала не идёт как "монстр". И здесь в качестве удобного способа программирования будет удобно объявить именно наследника квадрата или прямоугольника. Вовсе не заморачиваясь универсализацией классов.
В вашем решении есть один большой минус — чем более универсальный класс, тем труднее его использовать, изучать, писать и отлаживать.
Из него опять, для облегчения программирования, будут наследовать квадрат, прямоугольник и т.д. и вопрос встанет с новой силой.
Re[10]: О наследовании, иерархиях и проектировании (философс
Здравствуйте, FDSC, Вы писали:
FDS>И заметьте, что при этом простота использования и очевидность интерфейсов классов существенно упадёт. Так же, повысится сложность самого класса параметрической фигуры.
FDS>Если разрабатываемое приложение не такое сложное, то необходимость наследования может возникнуть, мало того, должна возникнуть, если только это приложение с самого начала не идёт как "монстр". И здесь в качестве удобного способа программирования будет удобно объявить именно наследника квадрата или прямоугольника. Вовсе не заморачиваясь универсализацией классов.
FDS>В вашем решении есть один большой минус — чем более универсальный класс, тем труднее его использовать, изучать, писать и отлаживать. FDS>Из него опять, для облегчения программирования, будут наследовать квадрат, прямоугольник и т.д. и вопрос встанет с новой силой.
Т.е. фактически вы предлагаете усложнить саму логику кода, усложнить его использование, но не делать много разных классов. Не всегда это решение может быть оправданным и правильным даже в рамках одного приложения и одной серии классов.
Там, где нужно и можно работать только с абстрактными данными, ваш способ, возможно, прокатит. Но он лишает программиста, в частности, возможности использования статического контроля типов и т.п. Т.е. всего, что ему предоставляет разбиение системы на несколько классов.
Возможно, он совершенно не хочет и никогда не захочет писать класс параметрической фигуры, а вот наследовать квадрат от прямоугольника ему будет по каким-то причинам удобно и даже правильно.
Re[6]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, prVovik, Вы писали:
V>То, о чем вы говорите как раз и называется структурная декомпозииция. Почитайте Гриди Буча, он в самом начале своей книги по ООП разбирал именно два эти подхода, и наглядно, на примере какой-то задачи по обработке файлов демонстрировал недостатки структурной декомпозиции над объектно-ориентированной.
Вообще-то это мошейничество. Бывают случае когда ОО-декомпозиция полнейший оверкил, а структрурная рулит. Бывает наоборот. Так что такой пример приведенный в качестве доказательства превосходства ОО-декомпозиции ни что иное как подлог.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, ZevS, Вы писали:
ZS>Короткие лаконичные программы на Perl просто ужасны.
У вас проблема терминологические. Ты под "которткие" понимаешь "комактно сжатые", а твой оппонент "выразительные".
Чтобы программа стала понятнее она должна достигать компактности не за счет использования малопонятных умолчаний, и темболее не за счет запихивания всего в одну строку и жервтования отбивкой. Компактность должна достигаться за счет большей декларативности. Тут есть разные подходы:
1. Выноск части логики в библиотеки.
2. Использование более выскоуровневых языков оперирующих прикладными понятиями (DSL-ей).
3. Использовние высокоуровневых конструкций вроде паттерн-матчинга вместо if-ов и switch-ей (а порой и вместо наследования и виртуальных методов).
4. Использовние декомпозиции на уровне фукнций и рекурсии.
В общем, компактность должна достигаться за счет повышении абстракции кода. Потому Перловый код и является плохочитаемым, что он не повышает абстрацию, а наоборот запихивает болшой объем конкретики на еденицу площиди и во всю использует неочевидные умочлчания.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: О наследовании, иерархиях и проектировании (философс
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>В том-то и дело, что я как раз предлагаю обратное: ориентироваться не на объекты, а на действия и проектировать эти объекты под необходимые действия.
Звучит неразумно. Действия — это функции. Крайне глупо без особой на то необходимости проектировать их как объекты. Объкты должны нести информацию, эмулировать суности реального или воображаемог мира, а не действия.
Вообще в твоих рассуждения есть четкая зацикленность на ООП. ООП не панацея. Это всего лишь способ декомпозиции и осмысления. Есть и другие способы. Разные задачи лучше решаются разными срдствами. Например, описание алгоритмов средствами ООП просто дурь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, prVovik, Вы писали:
КЛ>>Я же предлагаю ориентироваться не на объекты, а на действия. И проектировать структуры данных, модули под эти действия. Т.е. операция, функция (пользовательская) — первична, а объект — вторичен.
V>Поздравляю, вы открыли для себя структурное программирование
Ну, или почти открыл функциональное .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Про метрики я знаю. А можно уточнить, в каком случае увеличение размера программы привело к снижению измеримой сложности? И как эту сложность меряли? Какая конкретно метрика использована?
V>Имхо, тут присутствует некорректное понимание сложности.
Почему? Это вполне измеримая характеристика. Вот "трудность понимания" — да, она не меряется, или меряется очень условно ввиду субъективной природы самого явления "понимание". Если эти два термина перепутать, можно получить забавные рассуждения.
V>Мое мнение таково, что сложность невозможно адекватно измерить простыми метриками. Сложность — это количество реализованных идей.
Мда. Идея полёта в космос — что может быть проще?
С другой стороны:
int a = 1;
Аж три идеи в одной строчке!
V>Как именно эти идеи реализованы: в виде классов, шаблонов, или еще как — не суть важно. Таким образом, возможны ситуации, когда компактный код более сложен, чем код раздутый. Например, у нас может быть очень компактный код в стиле "аля Александреску", в котором в нескольких строчках кода сосредоточено большое количество идей, из-за чего код является сложным и при этом компактным. Теперь другой пример: код имеет регулярную структуру, но при этом объем кода большой. Ну, например, ручной DB мэппинг. Или реализация в отдельном классе каждой типизированной колекции. Во всех этих случаях, мы имеем тонны кода, который при этом очень простой.
Такой код прост для восприятия, но и не более того. "Несложным" он от этого не становится.
V>Другое дело, что помимо сложности, можно говорить и об удобстве использования кода. В этом случае да, компактный код более удобен в использовании, чем раздутый.
Не факт. Всё зависит от того, что именно подразумевать под "использованием". Здесь, как я понимаю, имеется ввиду "модификация".
V>Но компактность со сложностью напрямую нисвязаны. То есть может быть компактный простой код, компактный сложный, раздутый простой код и раздутый сложный
В повседневной речи и не такое встречается.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: О наследовании, иерархиях и проектировании (философск
Здравствуйте, VladD2, Вы писали:
VD>Звучит неразумно. Действия — это функции. Крайне глупо без особой на то необходимости проектировать их как объекты. Объкты должны нести информацию, эмулировать суности реального или воображаемог мира, а не действия.
Ну, я в общем-то не предлагал действия представлять объектами . Я лишь сказал, что структуры данных проектируются под конкретные задачи. Если структура данных (класс или иерархия) не имеет конкретных задач, то это повод для беспокойства. Соответственно, задачи определяются действиями, которые необходимо совершить.
На этом слайде приведен пример иерархии, которая разработана для рисования. Виртуальная функция Draw() позволяет свести код отрисовки фигур к циклу. Собственно, в этом и заключалась задача иерархии.
VD>Вообще в твоих рассуждения есть четкая зацикленность на ООП. ООП не панацея.
Вот уж тут Вы приписываете мне совсем не мои мысли . Из чего следует, что я зацикливаюсь на ООП? Наоборот, я считаю, что OOD — не лучшая методика проектирования.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, VladD2, Вы писали:
VD>>Тогда поясни, плиз, что вообще означает загадочная фраза "Примеры ключевых параметров порядка"?
КЛ>Это примеры к этому слайду. См. также это сообщение
Здравствуйте, FDSC, Вы писали:
FDS>И заметьте, что при этом простота использования и очевидность интерфейсов классов существенно упадёт. Так же, повысится сложность самого класса параметрической фигуры.
Совсем необязательно. В этом примере вряд ли класс CTargetSensor как-то стал сложнее классов CCarSensor, CPowerUpSensor и CMineSensor вместе взятых. Аналогично происходит и с фигурами. Обобщенный класс не становится сложным за счет нахождения оптимальной формы представления данных и методов.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, FDSC, Вы писали:
FDS>>И заметьте, что при этом простота использования и очевидность интерфейсов классов существенно упадёт. Так же, повысится сложность самого класса параметрической фигуры.
КЛ>Совсем необязательно. В этом примере вряд ли класс CTargetSensor как-то стал сложнее классов CCarSensor, CPowerUpSensor и CMineSensor вместе взятых. Аналогично происходит и с фигурами. Обобщенный класс не становится сложным за счет нахождения оптимальной формы представления данных и методов.
А в этом примере уменьшения кода и нет. Здесь есть введение дополнительного абстрактного слоя, о чём я и говорю. Любая проблема архитектуры решается введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества абстрактных слоёв, если не ошибаюсь, именно это написано у кого-то из участников форума в подписи. Так что тут ничего нового. Никакого уменьшения ОБЪЁМА кода нет, а раз так, значит по прежнему могут возникнуть очень и очень острые проблемы побочных эффектов, неправильного понимания механизмов работы алгоритмов или неучтённых, но нужных информационных связей.
Т.е. все проблемы остаются. Вы всего лишь пытаетесь научить общественность тому, что она уже умеет: пытаетесь сказать, что вот мол, ребята, давайте вводить более удобные интерфейсы. ДАВАЙТЕ, ДВУМЯ РУКАМИ ЗА!!!
Просто проблемы проектирования возникают не от того, что кто-то чего-то не знает (хотя и от этого тоже), а от того, что кто-то недостаточно много думал или просто не представляет себе сложности всей системы и методов использования отдельных её частей
Мы можем сколько угодно давать абстрактные советы, но когда я сяду за новую систему, я, прочитав эти советы, всё равно буду проектировать по старому. Просто потому, что советы надо уметь и не забывать применять, а именно это и делается сплошь и рядом. Не из-за недостатка советов, а из-за недостатка понимания того, как вообще проектировать архитектуру.
Короче говоря, по моему мнению, вы решаете проблему, которой нет. Вы пытаетесь лечить симптомы, которые даже и не лечатся, да и даже если бы лечились, не стоило бы тратить время на их лечение.
.
