программистское: Мордой об стол

[yigal_s]

Где ООП явно не в тему - это ГУИ (пример правильного построения гуя - Fudgets).

[link]

Я так-сяк повертел это заявление (и прочие, прочитанные на sql.ru), вспомнил некоторые почему-то не получившиеся для написания задачи из своей практики, равно как и некоторые "гениальные ООП решения", и сформулировал супер-радикальный тезис:

Объектно ориентированное программирование менее всего подходит для отображения объектов реального мира (включая сюда и объекты - элементы GUI) в объекты (в терминологии OOP/D) программы.

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

Почитать, что ли Симулу какую... Для избавления от ереси неверия в то, во что верил последние 14 лет.

Comments

Полнота

[(Anonymous)]

Есть и еще одна сторона.

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

Для объектно-ориентированной модели подобных доказательств полноты, насколько я знаю, не существует

Re: Полнота

[yigal_s]

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

Скажем, можно же просто всё написать в виде методов одного объекта (или почти одного) - тем самым, полнота гарантирована.

Но с интуитивной точки зрения некоторая неполнота ощущается. Когда только начинал это дело осваивать, было ощущение жуткой несвободы, отсутствия некоторого универсального базиса для написания ОО кода. Надо было пройти некоторый скорбный путь, тьмный тоннель, в конце которого получался неплохо задизайненный код, но... никто не гарантировал, что этот путь удастся пройти. Сейчас, конечно, те проблемы малоактуальны (многое понял из "банды четырех", да и опыта поднабрался). Но факт - базиса как не было, так и нет. Иной факт - не было такого скорбного пути в необъектных языках. Была куда большая свобода, легко получался рефакторинг, не было ощущения, что шаг вправо-шаг влево и будут стрелять, что сопровождает в ООП до сих пор.