[ООП] правильное разбитие на классы одного примера
тоже самое, но с абзацами, которые иначе парсер съедает
>Вопрос простой: какую для задачи рациональных чисел и подобных принято строить струтктуру классов?
если в кратце, то данную задачу никто сознательно не решает.
лишь наивно решаются в каждом случае какие-то частные варианта данной задачи.
если в кратце, то данную задачу никто сознательно не решает.
лишь наивно решаются в каждом случае какие-то частные варианта данной задачи.
да, и самое главное - а зачем это тебе надо?
я знаю только два ответа на вопрос "зачем такое надо":
1. если делать иначе, то это "некрасиво". т.е. это чисто фундаментальные размышления, требующие большой значительной проработки, но при этом имеющие слабую практическую пользу
2. будет практическая польза на очень больших (масштаба всего инета) централизованных задачах
1. если делать иначе, то это "некрасиво". т.е. это чисто фундаментальные размышления, требующие большой значительной проработки, но при этом имеющие слабую практическую пользу
2. будет практическая польза на очень больших (масштаба всего инета) централизованных задачах
да, и самое главное - а зачем это тебе надо?сам я уже решил частным случаем
мне кажется что указанная задача должна быть достаточно показательной в плане изучения ООП. У меня есть ощущения, что услышав правильный ответ, я для себя что-то сильно новое в ООП вынесу. Задача плохо ложится на обычную иерархию классов и нужно как-то пристраиваться к ней сбоку (а не сверху вниз). Овладев приёмом такого пристраивания я узнаю методы обхождения некоторых острых углов ООП. Их существование не подлежит сомнению, иначе бы народ не начал городить языков-монстров вроде скалы или библиотеки generic functions (часть PEAK) для питона.2. будет практическая польза на очень больших (масштаба всего инета) централизованных задачах3. Бывают примеры посложнее. Для некоторых задач простые параметры позволяют решать задачу в аналитическом виде, а для полного варианта - приходится делать разложение по тейлору и численно решать. Мне так кажется желание максимально долго удерживаться в пределах символьной арифметики вполне понятно
>указанная задача должна быть достаточно показательной в плане изучения ООП.
указанная задача ортогональна к ООП. сам по себе ООП не имеет ответа как правильно разбивать мир задачи на типы.
к задаче ближе категоризация.
АОП еще настолько же близко, как и ООП.
указанная задача ортогональна к ООП. сам по себе ООП не имеет ответа как правильно разбивать мир задачи на типы.
к задаче ближе категоризация.
АОП еще настолько же близко, как и ООП.
указанная задача ортогональна к ООП. сам по себе ООП не имеет ответа как правильно разбивать мир задачи на типы.к задаче ближе категоризация. АОП еще настолько же близко, как и ООП.ну хорошо и так сойдёт. Просто ООП я знаю, остальное нет, и не против проложить мостик
Вот тут по теме, вроде:
http://en.wikipedia.org/wiki/Circle-ellipse_problem
Если все иммутабельное, то проблем особых нет. Если можно менять объект, тошаблоны рвутся инварианты нарушаются, и ООП идет в все плохо.
Скорее нет, чем да.
http://en.wikipedia.org/wiki/Circle-ellipse_problem
Если все иммутабельное, то проблем особых нет. Если можно менять объект, то
метакласс (по определению дельфи case class (по определению скалы ко- и контр- вариации, generic functions, multiple dispatch; правильно ли я понял что все эти слова так или иначе связаны с первоначальным вопросом и используются (не обязательно совместно) для разных вариантов его решения?
Скорее нет, чем да.
да, очень даже по теме. Народ, правда, на эти грабли наступал ещё двадцать лет назад, а я только сейчас обнаружил 
Но вроде как это действительно классический пример плохой применимости ООП. Так что я был прав - ответ на вопрос, точнее пока только несколько ссылок, действительно, сильно расширили мои знания об ООП.
Но вроде как это действительно классический пример плохой применимости ООП. Так что я был прав - ответ на вопрос, точнее пока только несколько ссылок, действительно, сильно расширили мои знания об ООП.Most descriptions of LSP focus on inheritance, whereas LSP is actually about subtyping, which is more generally about relationships between types and their usage in a particular context. It so happens that inheritance is a mechanism for relating types, and LSP can guide us in that, but it’s not the only game in town. It applies to other forms of polymorphism, such as the classification by Cardelli and Wegner: inclusion polymorphism (extends in Java parametric polymorphism (generics, but nothing so random and clumsy as generics in Java overload polymorphism (particularly relevant when a language supports operator overloading) and coercion polymorphism (in other words, implicit conversions to other types, which is something that you can do in C# and C++, but not Java). In all these cases, LSP applies because it offers guidance on the principle of least astonishment when mixing types that at one level are conceptually interchangeable.идея классификации полиморфизом мне тоже понравилась. Мне вообще хочется услышать единую теорию всего, которая объяснит, чем разные парадигмы программирования отличаются друг от друга: не в технических частностях (вроде отсутствия goto не в маркетинговых свойствах: стоимость разработки, поддержки и модификации, а именно в устройстве самих парадигм.
http://en.wikipedia.org/wiki/Circle-ellipse_problemзадал эту проблему одному из знакомых физиков. Тот сказал, чтобы не маялся дурью и что оба объекта - это одно и тоже, только для отображения эллипса необходимо ещё оператор проецирования на плоскость задать.
Оставить комментарий
yroslavasako
Бывает множество случаев, когда некоторый частный случай более общего типа встречается достаточно часто и реализуется намного проще чем весь тип. Вектор - это матрица с одним столбцом, целое число - это рациональное со знаменателем единица. Можно много придумать классов с параметрами, у которых бывает простые частные случаи.Причём может быть два варианта - val и var, в первом случае объекты класса immutable и любая операция порождает новый объект, во втором случае объекты класса mutable и некоторые опреации вроде += (для рациональных чисел) могут изменять сам объект.Вопрос простой: какую для задачи рациональных чисел и подобных принято строить струтктуру классов? Может под это дело какой паттерн применим.Вопрос сложнее: я слышал много страшных слов (но понял или изучил далеко не все): метакласс (по определению дельфи case class (по определению скалы ко- и контр- вариации, generic functions, multiple dispatch; правильно ли я понял что все эти слова так или иначе связаны с первоначальным вопросом и используются (не обязательно совместно) для разных вариантов его решения?Сам я размышляю о трёх аспектах вопроса:1. Структура классов, создание объектов, конструкторы и фабрики2. Операции над объектами класса, выведение типа результата, трансформации объектов3. Диспетчеризация функций - определение в каких случаях какой вариант функции использовать (для полного или упрощённого случая).