Как правильно сказать про методы в ООП

[Spook]

Немного запутался в терминологии.
Как правильно, "метод класса" или "метод над классом"?

[Maxim Vlasov]

Класс это совокупность данных и методов их обработки.
Поэтому говорим "поле класса" (данные) и "метод класса".

"Метод над классом" - непонятно что можно назвать так. Где-то встречалось ?

[e2e4]

Цитата:

Как правильно, "метод класса" или "метод над классом"?

Метод класса.

[zbl]

Spook писал(а):

Немного запутался в терминологии.

Если для определённости взять C++, то под методом понимают реализацию функции-элемента (в терминологии Страуструпа), а объявление функции-элемента называют операцией класса.
Эта терминология наиболее общепринятая и принята в UML -- стоит её всячески пропагандировать.
Но вот в каждом конкретном языке эти вещи называются по-своему; можно встретить и "обобщённая фукция" (CLOS) и много чего ещё.
Различать же объявление и определение метода имеет смысл в связи с интерфейсами, которые поддерживаются со стороны некоторых языков (например -- Java).

[Spook]

Maxim Vlasov писал(а):

Где-то встречалось ?

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

[worm2]

Вот ещё достойный материал для философствования в ООП:
Круг --- это не эллипс (то же самое в Википедии; то же самое по-русски).

[незваный гость]

Spook в сообщении #141888 писал(а):

Как правильно, "метод класса" или "метод над классом"?

Метод над классом не встречал. Методы класса встречаются в динамических языках, когда класс — это объект класса метакласс. И соответственно, метод класса манипулирует классом, а не объектом. (Smaltalk-80).

Кроме того, методом класса иногда называют статические методы, чтобы подчеркнуть их неприменимость к объектам класса (instances). Но для языков, имеющих явные статические методы, это скорее жаргон (или архаизм).

worm2 в сообщении #142497 писал(а):

Круг --- это не эллипс (то же самое в Википедии; то же самое по-русски).

Забавно! Но рассуждения (философствования) не впечатлили. Никто не хочет указать на психологическую ловушку: эллипс в математике (а это то, как большинство его понимает) — неизменяемый (immutable). А в программировании — изменяемый (mutable). Отсюда и проблемы. Я бы вывел бы оба (Ellipse и Circle) из ImmutableEllipse. Ну, или уж если очень надо, ImmutableEllipse -> Ellipse и ImmutableEllipse -> ImmutableCircle -> Circle.

[zbl]

незваный гость писал(а):

Я бы вывел бы оба (Ellipse и Circle) из ImmutableEllipse.

Но они ж тогда будут как в математике, а не как в программировании?
Что делать, если нужны именно изменяемые эллипс и окружность?
Ответ, в общем-то, -- ничего.
Мы же не станем возражать, что, если сплющить окружность, то она перестанет быть окружностью.
Если мы хотим это поддерживать, то вынуждены и реализовывать окружность так, чтобы она могла динамически менять свой тип (в некоторых языках есть поддержка динамической типизации).
Какого-то парадокса тут нет совсем, а уж какого-то деффекта ООП и подавно.

[worm2]

Конечно, дефекта ООП (здесь это "объектно-ориентированное проектирование") здесь нет.
Просто есть противоречие между принципом ООП "всё, что можно делать с предком, должно гарантированно работать и с потомком" (не помню, как называется) и наивным представлением о наследовании как о теоретико-множественном включении. Это и есть парадокс (когда интуитивные представления о чём-либо являются ложными).

[zbl]

worm2 писал(а):

Это и есть парадокс (когда интуитивные представления о чём-либо являются ложными).

Я же парадокс мыслю как факт противоречивости знания, который требует это знание подкорректировать, а не как неверное восприятие верного знания...
В случае с ООП первого много меньше, чем второго -- чего не скажешь, судя по подобной литературе в Сети: каждый, кто сталкивается с собственным недопониманием компонентов объектного подхода в первую очередь списывает затруднения на несовершеннство ООП, а не на свой счёт.

[незваный гость]

zbl в сообщении #143447 писал(а):

Но они ж тогда будут как в математике, а не как в программировании?
Что делать, если нужны именно изменяемые эллипс и окружность?

class ImmutableEllipse 
{
  protected double a, b;

  ImmutableEllipse(double a, double b);

  double area();
  
  double length();

  …

}

class Ellipse:
  public ImmutableEllipse
{
  Ellipse(double a, double b);

  void compress_x(double factor);
  void compress_y(double factor);

  …
}

class Circle:
  public ImmutableEllipse
{
  Circle(double radius);
  
  // create an Ellipse object out of Circle  
  Ellipse* Ellipse();

  // override length with simpler one
  double length();

  void compress(double factor);

  …
}

worm2 в сообщении #143484 писал(а):

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

Я вижу здесь другой конфликт: между математическим и «программистким» терминами. Соответственно, и предлагаемый мною подход. При этом соблюдаются и принцип Барбары Лисков, и теоретико-множественное включение. Хотя наблюдается некоторая неуклюжесть названий: «неизменяемый» эллипс — это не эллипс, который не может меняться, а эллипс, который мы не умеем менять. В некотором смысле, полуфабрикат. В то же время, объект этого типа не является «неизменяемый» в строгом смысле этого слова в программировании, когда после создания объекта гарантирована неизменность его свойств. Так что, быть может, стоило бы поискать другое имя.

zbl в сообщении #143500 писал(а):

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

Куда приятнее чувствовать себя лучше других, чем понимать своё несовершенство.

Но вот увы: я так и не понимаю, что такое ООП. ООА, ООД — чуть-чуть понимаю, процентов так на 30-50. Хотя мне бы хотелось получить столь же сильные инструменты, как формализм структурного программирования. Между прочим, принцип Б.Лисков — акурат перенос требований структурного программирования на ООД. А дальше? Где свои инструменты?

[Sanyok]

незваный гость писал(а):

worm2 в сообщении #142497 писал(а):

Круг --- это не эллипс (то же самое в Википедии; то же самое по-русски).

Забавно! Но рассуждения (философствования) не впечатлили. Никто не хочет указать на психологическую ловушку: эллипс в математике (а это то, как большинство его понимает) — неизменяемый (immutable). А в программировании — изменяемый (mutable). Отсюда и проблемы. Я бы вывел бы оба (Ellipse и Circle) из ImmutableEllipse. Ну, или уж если очень надо, ImmutableEllipse -> Ellipse и ImmutableEllipse -> ImmutableCircle -> Circle.

Я тоже считаю что круг-это все же не эллипс Время от времени пишу векторный графический редактор, там у меня есть объект GrCircle - то есть круг, который выведен в свою очередь из GrObject - просто графического объекта. Наверняка будет и GrEllipse, выведенный из GrObject. Почему я не хочу выводить эллипс из круга (или наоборот - круг из эллипса)? Просто потому, что у круга у меня один параметр - радиус (и он изменяемый, кстати), а у эллипса их два - две полуоси, a и b. То есть как видим, у этих фигур нет совпадающих параметров. Из круга можно было бы вывести объект кольца, имеющего радиус и толщину, кругового цилиндра и т.д. Безусловно, то, что я сказал - не истина в последней инстанции, это всего лишь мое мнение

[zbl]

незваный гость писал(а):

class ImmutableEllipse 
{
  protected double a, b;

  ImmutableEllipse(double a, double b);

  double area();
  
  double length();

  …

}

// ...

class Circle:
  public ImmutableEllipse
{
  Circle(double radius);
  
  // create an Ellipse object out of Circle  
  Ellipse* Ellipse();

  // override length with simpler one
  double length();

  void compress(double factor);

  …
}

Ну, и зачем в Circle унаследованные от ImmutableEllipse атрибуты a и b?

незваный гость писал(а):

Я вижу здесь другой конфликт: между математическим и «программистким» терминами.

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

незваный гость писал(а):

Но вот увы: я так и не понимаю, что такое ООП. ООА, ООД — чуть-чуть понимаю, процентов так на 30-50. Хотя мне бы хотелось получить столь же сильные инструменты, как формализм структурного программирования.

ООП как раз потому и замена структурному программированию, что мощнее его.
В том смысле, что с помощью ООП можно решать задачи, которые с помощью структурного программирования решить просто невозможно.

незваный гость писал(а):

Между прочим, принцип Б.Лисков — акурат перенос требований структурного программирования на ООД.

По сути, структурное программирование в основном содержится в ООП, но есть и принципиальные непересечения, да и чисто коньюктурно выгодно противопоставлять ООП стуктурному программированию -- поэтому так и делают.

незваный гость писал(а):

Где свои инструменты?

В свободном доступе.
Есть теория, практика и поддержка всего этого со стороны языков -- что конкретно нужно?

[zbl]

Sanyok писал(а):

Почему я не хочу выводить эллипс из круга (или наоборот - круг из эллипса)? Просто потому, что у круга у меня один параметр - радиус (и он изменяемый, кстати), а у эллипса их два - две полуоси, a и b.

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

[Sanyok]

zbl писал(а):

Sanyok писал(а):

Почему я не хочу выводить эллипс из круга (или наоборот - круг из эллипса)? Просто потому, что у круга у меня один параметр - радиус (и он изменяемый, кстати), а у эллипса их два - две полуоси, a и b.

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

Я имел в виду, что параметры этих двух фигур имеют разный смысл. Что касается выделения памяти - дело вкуса, конечно. Но лучше, что бы все внутренние переменные объекта при его создании как-то были проинициализированы - по крайней мере, все указатели надо сбросить в null. Куча трудноуловимых ошибок в прогах на C++ вызваны именно неинициализированными данными класса. Увы, компилятор C++ о них не сообщает, в отличие от Java.

zbl писал(а):

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

Я даже не спрашиваю, как Вы это собираетесь делать Не сомневаюсь, что на языке C++ и не такое можно делать (достаточно Александреску почитать - волосы дыбом встанут:))
Можно, я о другом спрошу? Думал несколько вопросов задать, но по существу они все сходятся к одному - нужно ли, что бы круг мог превращаться в эллипс, а эллипс - в круг, или нет? По-моему, лучше и проще сделать так, что бы на основе параметров данного круга создать новую фигуру - эллипс, а старую фигуру (круг) удалить, нежели посылать кругу сообщение вида "давай, брат, в эллипс превращайся".
P.S. Кстати, у эллипса-то целых 3 парметра- его ж еще повернуть можно!