Теоретические проблемы ОО.
От: Maxim S. Shatskih Россия  
Дата: 28.04.06 21:59
Оценка: +4 -4 :)
В этой теме я хочу коснуться именно принципиальных, концептуальных проблем ОО парадигмы, а не применимости ее в конкретных проектах.

Итак.

1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное программирование.

В этом разделе программирования очень важную роль играют атомарные операции, в общем почти транзакции (свойства A и I точно есть). То есть — некая совокупность изменений связанных структур данных должна делаться обязательно до конца, и ее промежуточные состояния не видимы другим субъектам исполнения.

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

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

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

2). В ОО очень плохо решен вопрос операций сразу на большим количеством похожих элементов данных.

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

Кроме итераций, ОО практически ничего не предлагает.

Пример: сохранение в файл большого количества мелких элементов данных. Если такая задача стоит часто и требования к ней по скорости высоки, то имеет смысл хранение данных в памяти проектировать именно "от сохранения в файл". Т.е. — много страниц, каждая из которых сохраняется в файл одним вызовом write(). В странице находятся элементы данных, которые идут там "встык", как в Сишном массиве. Удаление из середины и реюз удаленного места делается, например, списком пустых мест.

Это не-ООшный паттерн. Совсем. Операции оперируют над отдельными объектами, в то время как хранятся сразу агрегаты объектов, и есть агрегатные операции — сохранение в файл.

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

Или взять задачу поиска, отбора элементов данных по какому-то признаку. ООшный стиль будет иметь много больший оверхед, чем вот такой "страничный".

В этом мне видится причина, почему "не пошли" ООБД. Связывать каждый элемент данных с кодом — расточительно. Это требует, например, на неких массовых операциях — инстанцирования каждого объекта. Медленно. SQLный SELECT быстрее.

Общее у этих двух недостатков: ОО предполагает кучу мелких сущностей, каждая из которых состоит из кода и из элемента данных. Это не всегда удобно. Иногда бывает удобно иметь сложные структуры именно одних лишь данных, а код к ним прилеплять уже по мере необходимости с различных боков. Т.е. классический процедурный, не ОО подход.

Ну вот примерно так.
Занимайтесь LoveCraftом, а не WarCraftом!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.