программистское: Мордой об стол
Oct. 30th, 2007 02:11 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
yigal_sГде ООП явно не в тему - это ГУИ (пример правильного построения гуя - Fudgets).
[link]
Я так-сяк повертел это заявление (и прочие, прочитанные на sql.ru), вспомнил некоторые почему-то не получившиеся для написания задачи из своей практики, равно как и некоторые "гениальные ООП решения", и сформулировал супер-радикальный тезис:
Объектно ориентированное программирование менее всего подходит для отображения объектов реального мира (включая сюда и объекты - элементы GUI) в объекты (в терминологии OOP/D) программы.
Пожалуй, истиннонсть этого тезиса мне пока трудно всерьез обосновать (ложность же напрашивается). Но что-то в этом есть. По крайней мере, стоит об этом тезисе вспоминать, прежде чем бросаться всё и вся выражать в виде объектов и протокола их взаимодействия, а потом тупо думать - что ж оно всё никак не выражается?
Почитать, что ли Симулу какую... Для избавления от ереси неверия в то, во что верил последние 14 лет.
no subject
Date: 2007-10-30 03:18 am (UTC)no subject
Date: 2007-10-30 03:20 am (UTC)no subject
Date: 2007-10-30 03:27 am (UTC)http://gadyuka.livejournal.com/tag/daa
no subject
Date: 2007-10-30 09:52 am (UTC)no subject
Date: 2007-10-30 10:23 am (UTC)no subject
Date: 2007-10-30 12:51 pm (UTC)Вот, к примеру, ниже под этим же постом анонимус на примере глаголов и существительных ругает ОО-программирование - тут все понятно. И понятно, как спорить, если придет охота: объект - это не обязательно существительное, вполне можно объектами считать глаголы =).
Если б понял, в чем суть - постарался бы объяснить своими словами, авось понятнее бы получилось.
И я тут думал о том же
Date: 2007-10-30 03:19 am (UTC)Наверно лучше всего объяснять на метафоре живого языка.
"Процедурное" программирование - это разговор глаголами:
чтобы сделать Х мне надо проверить А, сформировать Б, обратиться к В за таким-то содержанием, и выделить из него части Г, которые скомбинировав вычислить результат.
А,Б,В,Г - это "существительные", некие сущности, "вещи" в самом абстрактном виде. Ими могут выступать файлы, строчки, структуры данных - всякие "что"-абстракции.
А мои подпрограммы - глаголы, глагольные фразы (вроде того, как если удить, то "+ рыбу", читать книгу, спрашивать кого о чем (глагол + одушевленное + "о" + неодушевленное).
Думать так ЕСТЕСТВЕННО в первую очередь
ООП же возникло говорят для исполнения чрезвычайно громоздких проектов, о было решено объединять куски программы вокруг СУЩЕСТВИТЕЛЬНЫХ, а не глаголов, т.е. неких структур хранения или абстрактных сущностей, приписывая к ним "свойства" (attributes) и "глаголы" ("methods"):
-- у нас есть шкаф; у нас есть книги. У "объекта" шкаф есть внутренний абстрактный объект "книга", у которой может быть до 150 на трех "полках" "instances", "воплощений".
У шкафа есть свойства "вместимость", "тип", а от "типа" зависят "методы" (функции, глаголы) доступа - "открыть", "вынуть", "поставить", "закрыть", "сортировать". Если шкаф с дверцами, открыть-закрыть не такие как для шкафа со сдвигаемым стеклом, но якобы внешне к ним обращаться надо так же.
Что мгновенно опознается мозгом как выморочное и вызывает естественный протест - лживость как "объектов" так и методов. Они ненатуральны, и то, как их удумал один человек другой не повторит.
Больше всего меня раздражает то, что "объекты" должны "обмениваться сообщениями" - они не обмениваются никакими сообщениями. Нет никакой реальности за представлением, что компьютер - лес, в котором постоянно якобы живут звери-обекты, которые якобы имеют свою волю и друг с другом разговаривают.
Далее, раздражает дичь того, что каждый мелкий чих оформляется в виде "объекта", и этот мусор выдается за эталон.
В книге "банды четырех" ("Design Patterns") например, объясняют как это классно иметь объект-надзиратель за другим процессом - и когда ты прочитаешь пример, становится понятно, что вся мутота полностью эквивалентна установке булевой переменной-флага и ее проверке!
Я пробовал внутри своей головы перевернуть думалку и конструировать как бы высказывания на основе существительных:
вот, "собрание". Его можно "проводить, созывать, распускать, закрывать, открывать". Но собрание также - событие во времени, поэтому его можно назначить (на дату), перенести, отменить. Вот уже надо встраивать "объект" в две иерархии.
Далее, собрание есть множество людей. Поэтому оно может быть полным, некворумным, разгулявшимся или управляемым - третья иерархия.
Т.е. думая от существительных мы в принципе не получаем логичной однозначной последовательности, логика-организация надумана, всегда частична и произвольна. Почему "открыть" должно храниться вместе со шкафом - а для книги "открыть" будет другим, и храниться внутри "книги", и т.д. - мне неясно. За счет перечисления существительных мы повторяемся, увеличивая число глаголов - реальных компьютерных подпрограмм-вычислений, и это тоже насилует правдоподобие и понижает эффективность.
----------
Другими словами, идеальная процедура программирования должна бы соответствовать мышлению -- а поскольку мышление всегда происходит (или выражается в конце концов) на человеческом языке, то и программирование не должно бы насиловать наш язык, строясь как блоки-сочетания ему соответствующие.
При этом, разумеется, оно всегда будет составлять абстракции более высокого уровня из более мелких, это также естественно для работы мозга: ограаниченное поле внимания не позволяет оперировать миллионом деталей. Ключ в том, чтобы локальная работа над программными эпизодами была независимой - и увязывалась в логичное целое
Полнота
Date: 2007-10-30 03:26 am (UTC)Когда возникало "структурное" программирование, математики озаботились доказательствами и подбором минимально необходимого числа действий для полного выражения всего, что можно выразить.
Как в логике все можно свести к двум операторам, так, оказалось, для эквивалентности вычислялке Тьюринга достаточно иметь: (а) последовательность действий (б) ветвления и (в) повторения
Для объектно-ориентированной модели подобных доказательств полноты, насколько я знаю, не существует
Re: Полнота
Date: 2007-10-30 10:44 am (UTC)Скажем, можно же просто всё написать в виде методов одного объекта (или почти одного) - тем самым, полнота гарантирована.
Но с интуитивной точки зрения некоторая неполнота ощущается. Когда только начинал это дело осваивать, было ощущение жуткой несвободы, отсутствия некоторого универсального базиса для написания ОО кода. Надо было пройти некоторый скорбный путь, тьмный тоннель, в конце которого получался неплохо задизайненный код, но... никто не гарантировал, что этот путь удастся пройти. Сейчас, конечно, те проблемы малоактуальны (многое понял из "банды четырех", да и опыта поднабрался). Но факт - базиса как не было, так и нет. Иной факт - не было такого скорбного пути в необъектных языках. Была куда большая свобода, легко получался рефакторинг, не было ощущения, что шаг вправо-шаг влево и будут стрелять, что сопровождает в ООП до сих пор.