Pull to refresh

Comments 6

Для моделирования этого факта нам нужны: два ИО, моделирующие типы деревьев: берез и осин (в ООП – это классы), один ИО, моделирующий представление Ивановым 4-Д объема в виде кучи и один ИО, моделирующий состав кучи. Далее свяжем ИО, моделирующий состав, с типом берез связью «состоит на 70 процентов» и с типом осин связью «состоит на 30 процентов» (в ООП это сделать невозможно).

Оба утверждения про ООП неверны.


Вот пример ОО-моделирования деревьев с их "типами", не использующий разных классов для разных "типов":


class Tree
{
  Wood Wood;
}

enum Wood
{
  Birch,
  Aspen,
  ...
}

Вот пример ОО-реализации связи состава леса с "типами" деревьев:


class WoodComposition: IDictionary<Wood,decimal>

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

Как видно выше, с невозможностью у вас как-то плохо вышло.


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

Подождите, но какая связь между невозможностью моделировать что-то и невозможностью корректно сформулировать определение?


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

… но определение-то удалось сформулировать? Где оно?


Функция в таком случае моделируется классом функций.

Получилась рекурсия. Где из нее выход?


Трудно понять, что функция, как и объект – это разные представления о 4-Д пространстве, и что функцию, как и объект, можно пощупать

Нельзя. Ни "класс событий", ни "класс функций", ни "класс сценариев" (а это три предложенных вами модели функции) пощупать нельзя. Точно так же, как нельзя пощупать "класс" проданного вам авиабилета.


Надо преодолеть стереотип мышления, который говорит о том, что предприятие функционирует. Модель нам говорит о том, что есть две точки зрения на 4-Д объем. С одной – это объект, с другой – функция.

И зачем для этого преодолевать стереотип "предприятие функционирует"? Этот стереотип всего лишь говорит нам (очень полезно!) что объект и функция — это точки зрения на один объем, а не на разные.


ООП — экземпляры операций и операции. [...] В ООП все перепутано. Там, когда надо сказать об операции, говорят: экземпляр операции, а, когда надо сказать о типе, говорят – операция.

Нет, в ООП так не говорят.

Я ничего не понял, извините. Видимо, мы про разное

Ну давайте попробуем еще раз.


Вы сделали несколько утверждений за пределами вашей методологии:


  • "в ООП – это классы"
  • "в ООП это сделать невозможно"
  • "невозможность сделать это [...] с помощью современных языков программирования"
  • "[в ООП] когда надо сказать об операции, говорят: экземпляр операции, а, когда надо сказать о типе, говорят – операция"

Все они демонстрируемо ошибочны.

В примере я не увидел процентное соотношение: на 30 процентов из осин, на 70 — из берез.
WoodComposition {
  {Aspen, 30.0},
  {Birch, 70.0}
}
Я бы рекомендовал к прочтению Grady Booch. «Object-oriented Analysis and Design with Applications», а то про ООП у Вас какая-то каша.
Only those users with full accounts are able to leave comments. Log in, please.

Articles