OOPs - продолжение.

Начало: 1, 2, 3.

Немного повторюсь про инкапсуляцию, поскольку это важно.

Значит, инкапсуляция. Чёрный ящик с защищённой внутренней структурой и внешними интерфейсами.  Но обычно ещё к ней же относят и локальность. Т.е. практически во всех языках объект - это некий указатель на компактную структуру данных, хранящюю состояние объекта. В принципе, в языках, где объект - это нечто неспецифицированное, это может быть не указатель, а более абстрактный handle, который может быть, например индексом во многих разных массивах. Но я такого не встречал. Чаще всего это указатель. Зачем это говорю? Cейчас подойдём.

Значит написали мы черный ящик. Мощный, удобный, защищенный. Один объект - всё замечательно работает. Два объекта, десять объектов. Сто тысяч одинаковых объектов. Начинаются проблемы. Во первых уже давно надо нам объект искать. Если десять можно было показать пользователю, для ста, тоже сойдет, колесико у мышки спасает ситуацию, то тысячу уже сложно. Надо искать по параметрам, которые у нас, наверное, выведены как свойства. Есть в программе массив объектов (или, скажем, дерево), давайте мне возможность запросов. Linq скажут гордые своей осведомленностью, молодые программисты. Sqlite, скажут пожав плечами бородатые одмины. Вам нужен SQL сервер, скажут системные интеграторы и такие же аналитики.

Можно добавить в объект интерфейс для запросов. Для тысячи будет работать. А когда подойдем к миллиону, то ещё один для построения индексов. И тут мы обнаружим, что всё работает медленно. Долго загружается, долго индексируется, долго ищется и занимает кучу памяти. Даже закрывается долго! Ещё мы обнаружим, что если всё распечатать в текстовый файл, открыть в Фаре и поискать, то всё и откроется мгновенно, и найдется быстрее. Как же так, мы использовали самые лучшие объектные технологии, а без них быстрее? Может, таки прав аналитик, и надо всё засунуть в базу?

И проблемм здесь несколько. Первая основная: неудобно управлять большим количеством черных ящиков. Если объектов много и они одинаковые, то их набор начинает обладать своими собственными свойствами. Перегородки между объектами становятая слишком дороги. Мы как бы переходим от одной молекулы к веществу, и то, что в молекуле казалось внутренним, начинает задавать макро-свойства.

С точки зрения объектной, объектом становится весь контейнер объектов, и индивидуальные объектики становятся не нужны. Начинаются всякие вырезки и наборы, методы, работающие с вырезками и т.д. Произошла векторизация API.

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

Третья проблема - locks. Замки. Это вообще отдельная долгая история, которой касаться сейчас не буду. Просто разные поля часто требуют разных локов, но, при этом, защищены должны быть несколько объектов, или даже весь контейнер.

Короче мораль: много объектов - тоже объект. Неправильно! Не "тоже"! Только! Или никто не объект. А данные.

Объект - это его состояние. Его надо хорошо продумать и нормализовать. Удалить лишние состояния, особенно всякие "недоделанные". Атомарно создать, сразу "готовый". Сделать методы модифицирующие состояние, по возможности атомарно с нужным количеством параметров. И не надо всяких лишних объектных моделей и "свойств". Сделайте ядро с данными и потом, по просьбе трудящихся, можно навесить столько объектных моделей, сколько надо (а надо будет несколько, с разными версиями API...). Навесить снаружи. Не надо размазывать данные по объектной модели. Вы потом их не найдете и не соберёте. Тогда контейнерный объект сделается изменением этого ядра. Его можно будет перевести на SQL. И т.д.

Да... Скомкано и непонятно. Долгая история. Хотел коротко объяснить, но нет, не получается. Тут каждый довод можно объяснять, целая книжка получится.