Здравствуйте, Sinclair, Вы писали:


Интересно а как ты квадрат то наследовать будешь? Это вырожденный прямоугольник у которого все стороны равны. Единственное его преймущество, что нужно знать всего одну сторону.
Можно выразить любой квадрат в прямоугольник, но вот не любой прямоугольник можно выразить в квадрат.
У прмоугольника методы периметр, Площадь из квадрата никак не отнаследуешь. Мало того кроме длин сторон, нужно еще и расположение этих сторон.

Здравствуйте, Serginio1, Вы писали:

S> Интересно а как ты квадрат то наследовать будешь?
Вы это в какой модели спрашиваете? В модели мутабельных объектов с наследованием реализации?
Или в модели иммутабельных АлгТД?


S> Это вырожденный прямоугольник у которого все стороны равны.
Ухты! А я-то всё думаю, что ж такое квадрат-то? А то все про него говорят, а я и не в курсе, что это такое.

S> Единственное его преймущество, что нужно знать всего одну сторону.
А недостатки квадрата можно озвучить?

S>Можно выразить любой квадрат в прямоугольник, но вот не любой прямоугольник можно выразить в квадрат.
S>У прмоугольника методы периметр, Площадь из квадрата никак не отнаследуешь.
ОМГ. Вы серъёзно?

public class Rectangle: Square
{
  public Rectangle(int a, int b): base(a)
  {
    _b = b;
  }
  private int _b;
  public int B { get { return _b; }} 
  public override int GetArea(): { return A * B }
  public override int GetPerimeter(): {return 2*A + 2*B;}
}

Никаких проблем c наследованием, как только мы отказываемся от мутабельности.
Вот обратный вариант:

public class Square: Rectangle
{
  public Square(int a): base(a, a)
  {
  }
}

Он тоже прекрасно работает.

Здравствуйте, Serginio1, Вы писали:

S> Интересно а как ты квадрат то наследовать будешь? Это вырожденный прямоугольник у которого все стороны равны. Единственное его преймущество, что нужно знать всего одну сторону.
S>Можно выразить любой квадрат в прямоугольник, но вот не любой прямоугольник можно выразить в квадрат.
S>У прмоугольника методы периметр, Площадь из квадрата никак не отнаследуешь. Мало того кроме длин сторон, нужно еще и расположение этих сторон.

Да не надо его наследовать. Просто такое ощущение, что WH и Синклеру рассказали, что раз есть наследование, значит надо его использовать. В этом случае задача — что от чего наследовать — крайне актуальна .

Если же подходить к наследованию просто как к инструменту композиции для конструирования поведения, все становится очень просто. У каждого инструмента есть свойства, возможности, достоинства, недостатки.

А то как "открыть дверь" на С++, так ООП плохой, а как сделать тож самое на функциональном языке так сразу "гранаты не той системы".

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Интересно а как ты квадрат то наследовать будешь?
S>Вы это в какой модели спрашиваете? В модели мутабельных объектов с наследованием реализации?
S>Или в модели иммутабельных АлгТД?


S>> Это вырожденный прямоугольник у которого все стороны равны.
S>Ухты! А я-то всё думаю, что ж такое квадрат-то? А то все про него говорят, а я и не в курсе, что это такое.

S>> Единственное его преймущество, что нужно знать всего одну сторону.
S>А недостатки квадрата можно озвучить?
Только одни достоинства по отношению к прямоугольнику.

Наследование (которое может быть не виртуальным) и перекрытие виртуальных методов это не совсем одно и тоже.

То, что ты написал может относится к любой фигуре, коими являются и прямоугольник, и частная форма прямоугольника квадрат.
Единственно, добавить к классу фигура вид фигуры.

Здравствуйте, Serginio1, Вы писали:

S>>> Единственное его преймущество, что нужно знать всего одну сторону.
S>>А недостатки квадрата можно озвучить?
S> Только одни достоинства по отношению к прямоугольнику.

Это он тебя подкалывает. Свойства у прямоугольника и квадрата разные, вот и все. В обсуждаемом контексте нет ни достоинств, ни недостатков у обоих фигур

Здравствуйте, Sinclair, Вы писали:

Как я уже и писал выше проще наследоваться от абстрактного класса Фигура. А по твоему подходу можно наследоваться хоть от треугольника, все равно виртуальные методы перекрываются. Это ничем не отличается от интерфейсов. Все таки наследование это в первую очередь наследование существующей реализации и структуры полей, с добавлением дополнительных свойств(полей) и методов.
С Введением интерфейсов, перекрытие в ООП ушло на второй план.

S>Никаких проблем c наследованием, как только мы отказываемся от мутабельности.

Проблем становится меньше, но они все равно остаются. Если, конечно, речь идет о сохранении контракта родителя, а не просто о наследовании реализации.

У наследника для некоторых методов может меняться тип результата, что разрушает контракт родителя.

Для пары квадрат/прямоугольник такого метода сходу не скажу, а для пары эллипс/круг он известен.

Метод "Получить_Оси_Симметрии" для эллипса возвращает тип Конечное_множество_известного_заранее_размера<2, Ось_Симметрии>, а для круга возвращает тип Неисчислимое_множество<Ось_Симметрии>.

Здравствуйте, Serginio1, Вы писали:

S>Как я уже и писал выше проще наследоваться от абстрактного класса Фигура. А по твоему подходу можно наследоваться хоть от треугольника, все равно виртуальные методы перекрываются. Это ничем не отличается от интерфейсов. Все таки наследование это в первую очередь наследование существующей реализации и структуры полей, с добавлением дополнительных свойств(полей) и методов.

Нарушаются контракты, инварианты.

Если возникает необходимость вводить для фигур унифицированый интерфейс, то с этим приходится иметь дело независимо от ЯП. Если такой необходимости нет, то в ФП можно взять ПМ, что Синклер и хочет сказать.

Это как бы и ежу понятно. Фокус в том, что в большом приложении такое унифицирование интерфейсов все равно придется вводить в том или ином виде, может не буквально для фигур,а для компонентов побольше, и там вылезет ровно тоже самое — сохранение контрктов, инвариантов при введении унификации.

Здравствуйте, Ikemefula, Вы писали:

I>Это он тебя подкалывает. Свойства у прямоугольника и квадрата разные, вот и все. В обсуждаемом контексте нет ни достоинств, ни недостатков у обоих фигур

Разные? ))) Вообще то одно полное подмножество другого. )))

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:

S>>Как я уже и писал выше проще наследоваться от абстрактного класса Фигура. А по твоему подходу можно наследоваться хоть от треугольника, все равно виртуальные методы перекрываются. Это ничем не отличается от интерфейсов. Все таки наследование это в первую очередь наследование существующей реализации и структуры полей, с добавлением дополнительных свойств(полей) и методов.

I>Нарушаются контракты, инварианты.

I>Если возникает необходимость вводить для фигур унифицированый интерфейс, то с этим приходится иметь дело независимо от ЯП. Если такой необходимости нет, то в ФП можно взять ПМ, что Синклер и хочет сказать.

Ну кроме ПМ есть такое понятие как утинная типизация или двойная Диспетчеризация. Я на 1С вполне доволен и двойной диспетчеризацией, ну ой как часто не хватает нормального ООП.
Даже ради интеллисенса. (Есть там слабенький вывод типов).
При этом общие методы приходится делать статическими с передачей в параметрах объекта. В 1С есть модуль Объекта типа методы объекта и модуль менеджера — статические методы
Наследование полей будет только в 83 (в 7.7 кстати они были изначально).

I>Это как бы и ежу понятно. Фокус в том, что в большом приложении такое унифицирование интерфейсов все равно придется вводить в том или ином виде, может не буквально для фигур,а для компонентов побольше, и там вылезет ровно тоже самое — сохранение контрктов, инвариантов при введении унификации.

Ну вот ООП для Control мне очень нравится начиная с Delphi.
По теме я все же выскажусь так. Я за кодогенерацию например Т4. Сам активно использую в той же 1С. Я за общие DSL типа SQL, Linq где поведение этих DSL будет одинаково.
Что касается доморощенных DSL, то вот разбираться с ними будет намного сложнее, чем с кодом который они его скрывают.

Здравствуйте, alex_public, Вы писали:

I>>Это он тебя подкалывает. Свойства у прямоугольника и квадрата разные, вот и все. В обсуждаемом контексте нет ни достоинств, ни недостатков у обоих фигур

_>Разные? ))) Вообще то одно полное подмножество другого. )))

Конечно разные. Сможешь однозначно задать произвольный прямоугольник на плоскости с помощью всего двух точек — дам 100$

_>А если говорить по теме, то никакого наследования в этой задаче быть не должно в принципе. Т.к. класс прямоугольник полностью покрывает все возможные функции квадрата.

Как должно, никому не интересно. Интересно выжать максимум оптимизаций из этой разницы. Одну из оптимизаций я уже подсказал.

Здравствуйте, Ikemefula, Вы писали:

I>Конечно разные. Сможешь однозначно задать произвольный прямоугольник на плоскости с помощью всего двух точек — дам 100$

Две точки — это 4 независимых числа. И прямоугольник и квадрат заданного размера задаются на плоскости 3-я числами. Соответственно размер у прямоугольника — это ещё 2 независимых числа, а у квадрата одно независимое числе (т.е. получаем те же самые 4). Таким образом получаем всё тоже самое, но с сохранением единого интерфейса. Чудес в математики не бывает. )))

I>Как должно, никому не интересно. Интересно выжать максимум оптимизаций из этой разницы. Одну из оптимизаций я уже подсказал.

Ууу, оптимизация... Если уж дело доходит до неё (и она не преждевременная), то обычно это происходит в стиле всяческих костылей, а не как другая красивая архитектура (а тут мы вроде как обсуждаем именно это).

Здравствуйте, alex_public, Вы писали:

I>>Конечно разные. Сможешь однозначно задать произвольный прямоугольник на плоскости с помощью всего двух точек — дам 100$

_>Две точки — это 4 независимых числа. И прямоугольник и квадрат заданного размера задаются на плоскости 3-я числами. Соответственно размер у прямоугольника — это ещё 2 независимых числа, а у квадрата одно независимое числе (т.е. получаем те же самые 4). Таким образом получаем всё тоже самое, но с сохранением единого интерфейса. Чудес в математики не бывает. )))

А на деле получается так — (0,0) — (1,3) это ровно один квадрат и при этом бесконечное количество прямоугольников.

Вот тебе и "подмножество".

Здравствуйте, Serginio1, Вы писали:

S>По теме я все же выскажусь так. Я за кодогенерацию например Т4. Сам активно использую в той же 1С. Я за общие DSL типа SQL, Linq где поведение этих DSL будет одинаково.
S>Что касается доморощенных DSL, то вот разбираться с ними будет намного сложнее, чем с кодом который они его скрывают.
А чем твоя кодогенерация на T4 не доморощенный ДСЛ?

Здравствуйте, Ikemefula, Вы писали:

I>А на деле получается так — (0,0) — (1,3) это ровно один квадрат и при этом бесконечное количество прямоугольников.

I>Вот тебе и "подмножество".

Ой, ну что за детский сад, а? ) Это как раз и есть подмножество, т.к. один из этого бесконечного количества и есть наш квадрат. ))) Ну или если говорить языком программирования... Делаем конструктор для нашего класса прямоугольника в виде Rectangle(Point p1, Point p2, double k). И соответственно для квадрата вызываем его как Rectangle(p1, p2, 1).

Здравствуйте, alex_public, Вы писали:

I>>Вот тебе и "подмножество".

_>Ой, ну что за детский сад, а? ) Это как раз и есть подмножество, т.к. один из этого бесконечного количества и есть наш квадрат. ))) Ну или если говорить языком программирования... Делаем конструктор для нашего класса прямоугольника в виде Rectangle(Point p1, Point p2, double k). И соответственно для квадрата вызываем его как Rectangle(p1, p2, 1).

Про то и речь, что квадрат здесь ровно один, задаётся ровно двумя точками. Третий параметр обязателен только для прямоугольника и один единственный прямоугольник невозможно задать только этими двумя точками, нужен и третий параметр который ты сам же и ввёл.

Недавно ты говорил "все тоже самое". Оказывается что не всё, а есть целый набор свойств которые есть следствие равных сторон, например, биссектрисы пересекаются под прямым углом.

Ну если ты все еще сомневаешься, то покажи окружность, вписаную в прямоугольник(который квадратом не является) ну и покажи как унифицировать такой интерфейс.

Здравствуйте, DarkGray, Вы писали:

DG>У наследника для некоторых методов может меняться тип результата, что разрушает контракт родителя.
DG>Для пары квадрат/прямоугольник такого метода сходу не скажу, а для пары эллипс/круг он известен.
DG>Метод "Получить_Оси_Симметрии" для эллипса возвращает тип Конечное_множество_известного_заранее_размера<2, Ось_Симметрии>

Не подходит для эллипса, который есть окружностью.

DG>, а для круга возвращает тип Неисчислимое_множество<Ось_Симметрии>.

IO>Не подходит для эллипса, который есть окружностью.

во-первых, это вопрос терминологии. Или эллипс есть невырожденный эллипс с a != b и a > 0, b > 0, или эллипс есть обобщенный эллипс, включающий в себя в том числе и все вырожденные случаи: круг (a=b a,b!= 0), точка (a=b=0), "двойной" отрезок (a=0,b != 0 или a!=0, b=0)
во-вторых, проблема в любом случае остается и для пары обобщенный эллипс и обобщенный круг. Потому что для обобщенного эллипса метод "Получить_Оси_Симметрии" имеет возвращаемый тип Union<Конечное_множество_известного_заранее_размера<2, Ось_Симметрии>, Неисчислимое_множество<Ось_Симметрии>>, а для обобщенного круга данный метод имеет возвращаемый тип Неисчислимое_множество<Ось_Симметрии>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:

S>>По теме я все же выскажусь так. Я за кодогенерацию например Т4. Сам активно использую в той же 1С. Я за общие DSL типа SQL, Linq где поведение этих DSL будет одинаково.
S>>Что касается доморощенных DSL, то вот разбираться с ними будет намного сложнее, чем с кодом который они его скрывают.
WH>А чем твоя кодогенерация на T4 не доморощенный ДСЛ?

А тем, что я этот сгенеренный код легко могу подправить. Иногда проще исправить в одном двух местах в сгенеренном коде, чем городить навороченный алгоритм всевозможных вариантов.
Например я генерю код для обмена данными между разными конфигурациями, в том числе и между разными платформами 1С.
Ну и опять же я даю это для себя любимого. А кто не хочет брать эту обработку, тот может пользоваться другими инструментами. Нет жесткой зависимости.

Здравствуйте, Serginio1, Вы писали:
S>Как я уже и писал выше проще наследоваться от абстрактного класса Фигура. А по твоему подходу можно наследоваться хоть от треугольника, все равно виртуальные методы перекрываются. Это ничем не отличается от интерфейсов. Все таки наследование это в первую очередь наследование существующей реализации и структуры полей, с добавлением дополнительных свойств(полей) и методов.
Нет. Я не хочу опять заниматься очередным ликбезом, поэтому отвечу кратко: наследование — это отношение "is-a". И наследование реализации — один из худших видов наследования.
А про то, что проще, а что сложнее, рассуждать вообще не имеет смысла до тех пор, пока не поставлена задача.
В реальных решениях все эти иерархии фигур, столь популярные в учебниках, отсутствуют за ненадобностью. В реальной графической программе у вас скорее всего будет что-то вроде одного класса Shape, который состоит из набора прямых, дуг, и кривых Безье. А все "фигуры" будут описываться всего лишь конструкторами.

S>С Введением интерфейсов, перекрытие в ООП ушло на второй план.
Ну-ну.