что ж такое object-oriented?
Apr. 30th, 2014 10:05 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
yigal_sМожет быть, просто представление, что программу можно написать в виде объектов, имеющих внутреннее состояние и посылающих друг другу сообщения?
Инкапсуляцию отсюда получаем автоматически - как состояние объектов.
Полиморфизм тоже - ведь мы можем посылать сообщение объекту, не зная его тип.
Наследование... странная идея, что функциональность объектов можно расширять, надстраивая над ними "производный" тип, использующий при этом методы базового объекта. Я вообще-то не уверен, что это "истинное" свойство объектной ориентированности, во всяком случае, зачастую наследование применимо и полезно, а где не применимо - без него вполне можно обойтись.
Всякие там типы... подтипы... интерфейсы... ковариантности и контрвариантности - это интересно, конечно, но нетипизированный object-oriented вполне способен сделать всё то, что делает типизированный, а следовательно, всё перечисленное не является существенным для понимания концепции.
Откуда взялось представление, что объекты моделируют реальный мир, и, следовательно, позоляют модель этого мира запрограммировать? Извините, но объекты реального мира друг другу сообщений уж никак не посылают, тем более не реализуют какие-то многоэтапные протоколы с callbacks. Поэтому доказывать эффективность object-oriented можно как угодно, только не ссылаясь на то, что они моделируют предметную область чуть ли не один в один.
Под посылкой сообщения мы здесь понимали обычный вызов функции с возвратом значения. Сделаем лёгкую вариацию - пусть у нас действительно посылаются сообщения, без ожидания "возврата", т.е. ответа. Кажется, мы получили что-то похожее на Actors. Вопрос, на сколько такая система позволяет практически строить "concurrent" алгоритмы (при том, что мы абсолютно жестко запрещаем одному объекту как-то модифицировать состояние другого, скажем, через переданные указатели на его данные) - опять же нетривиален.
Инкапсуляцию отсюда получаем автоматически - как состояние объектов.
Полиморфизм тоже - ведь мы можем посылать сообщение объекту, не зная его тип.
Наследование... странная идея, что функциональность объектов можно расширять, надстраивая над ними "производный" тип, использующий при этом методы базового объекта. Я вообще-то не уверен, что это "истинное" свойство объектной ориентированности, во всяком случае, зачастую наследование применимо и полезно, а где не применимо - без него вполне можно обойтись.
Всякие там типы... подтипы... интерфейсы... ковариантности и контрвариантности - это интересно, конечно, но нетипизированный object-oriented вполне способен сделать всё то, что делает типизированный, а следовательно, всё перечисленное не является существенным для понимания концепции.
Откуда взялось представление, что объекты моделируют реальный мир, и, следовательно, позоляют модель этого мира запрограммировать? Извините, но объекты реального мира друг другу сообщений уж никак не посылают, тем более не реализуют какие-то многоэтапные протоколы с callbacks. Поэтому доказывать эффективность object-oriented можно как угодно, только не ссылаясь на то, что они моделируют предметную область чуть ли не один в один.
Под посылкой сообщения мы здесь понимали обычный вызов функции с возвратом значения. Сделаем лёгкую вариацию - пусть у нас действительно посылаются сообщения, без ожидания "возврата", т.е. ответа. Кажется, мы получили что-то похожее на Actors. Вопрос, на сколько такая система позволяет практически строить "concurrent" алгоритмы (при том, что мы абсолютно жестко запрещаем одному объекту как-то модифицировать состояние другого, скажем, через переданные указатели на его данные) - опять же нетривиален.
no subject
Date: 2014-05-01 03:23 am (UTC)> Извините, но объекты реального мира друг другу сообщений уж никак не посылают, тем
> более не реализуют какие-то многоэтапные протоколы с callbacks.
Ну почему же? "Солдат Трифонов, выкопать яму метр на метр на метр. Об исполнении доложить". Чем не вызов функции с колбэком?
ИМХО, проблемы ООП начались, когда ВНЕЗАПНО оказалось, что оно вовсе не панацея. Во-первых, объекты трудно запихать в базу данных, а во-вторых, они плохо умеют разговаривать по сети. Слишком много информации надо передавать + есть проблемы со stateless штучками типа HTTP и load balancers. Но в рамках монолитной программы среднего размера ООП очень даже полезно, почему нет?
no subject
Date: 2014-05-01 03:54 am (UTC)Дык, разве я говорю, что вообще нет областей, где объектная модель более-менее соотвествует предмету?
Проблемы вами перечисленные - весьма интересны, но я имел в виду нечто более базовое. Что возможность декомпозиции системы (даже бегущей в пределах одного процесса и без всяких Баз Данных и прочего) на объекты, взаимодействующие через посылку сообщений, вообще говоря, не гарантирована. Т.е. вот например у нас есть некий глобальный метод, который тупо бегает по массиву данных и что-то там на них модифицирует. Теперь где гарантия, что если мы распихаем эти данные по отдельным "объектам", мы можем переписать наш глобальный метод в виде протокола взаимодействия?
no subject
Date: 2014-05-01 03:15 pm (UTC)no subject
Date: 2014-05-02 12:25 am (UTC)проблема - преобразовать их состояние так, чтобы это не требовало прямого доступа к их внутреннему состоянию, и выражалось лишь в диспетчеризации им сообщений.
Ну, скажем, если объекты - это Солнце и планеты, каждый из которых хранит свою координаты и скорости, то как посчитать их движение в объектно-ориентированном стиле?
no subject
Date: 2014-05-02 12:18 pm (UTC)тут, наверно, штука какая: "объект" в ооп -- он ведь не напрямую имитирует объекты окружающего мира?
он имитирует объект в рамках соответствующей модели, т.е. грубо говоря -- не сам объект, а только его представление в той или иной конкретной теории.
т.е. задачу с солнцем и землёй можно решить контейнером "солнечная система", скажем, с функциями от t, возвращающими координаты элемента, но эта модель ничего не скажет нам о вероятности наличия жизни на третьей планете, например -- тут другой набор теорий, в которых планеты должны быть представлены другим набором параметров. проблемы часто начинаются, когда объекты из первой задачи пытаются приспособить для решения второй.
причём "реюз" по прежнему имеет место: "определение координат" -- это всётаки целый класс задач.
как с "материальной точкой" какойнибудь: использовать удобно, но нужно понимать на каких масштабах упрощение перестаёт работать, и нужно использовать другую модель.