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

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

Приведу один пример на "ядро" "объектной модели". Иногда подобную конструкцию называют "провайдером". Пример, конечно, дурацкий, но простой и для иллюстрации пойдёт.

Допустим мы делаем электронную таблицу, нечто вроде "экселя". Некий PM (или как они там ещё называются? системные аналитики?) написал спек, в котором раcписал "объектную модель". И написано там, что есть объект таблица, у него есть коллекция рядов, каждая из которых есть коллекция клеток, а уж клетка хранит одно значение, которое может быть константой или формулой.

Замечательно, сказали мы, и, не мудрствуя лукаво, написали как сказано. Всё просто и тривиально. После чего пришёл PM и сказал, что заказчик просит ещё коллекцию колонок, и каждая колонка - тоже коллекция клеток. Ну ладно, сказали мы и добавили. Хотя
это в нашей модели уже не так тривиально. После чего, заказчик захотел извлекать клетку прямо из таблицы используя две координаты. Тоже можно сделать. Сделали.

После чего заказчик сказал, что всё медленно и требует много пямяти. Таблица расходует слишком много пямяти на одну клетку, даже если там просто число. Поскольку число мы храним как величину типа "object" в объекте типа "cell", и указатель на него лежит в массивах внутри объекта "строка" и объекта "столбец". Ещё у нас в каждой клетке могут быть массивы указателей на зависимые клетки.

Почему это медленно? Поскольку плохая locality. Процессор быстро работает с пямятью расположенной рядом, поскольку она находится в процессорном кеше. Случайные обращения - значительно, на порядок, дольше.

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

Только мы всё это зашипили, как новая беда. Новый PM, пришедший в вашу группу, взамен старого ушедшего с повышением, сказал, что мы должны перейти на интерфейсы вместо классов и потому мы сделаем новую версию "объектной модели", причём мы будем поддерживать обе сразу, смешано и одновременно: "Вот вам challenge проявить вашу technical excellence."

И как весь этот огород сделать? Очень просто. Надо сделать "провайдер". Или "ядро". Это внутренний объект. Про который не знает ни заказчик, ни PM. Который хранит состояние вашего реального объекта. А реальный объект у вас один - таблица. Всё остальное, все эти строки, столбцы и клетки - её составные части. Как клетки вашего организма - ваши составные части. То, что заказчик просит то извлечь клетку так, то сяк - показатель, что клетка - часть таблицы.

Ключевое слово здесь - "зависимость", "dependency". Клетки зависимы, а таблицы нет. Границы между данными надо проводить по направлениям с наименьшим зависимостями.

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

Псевдокод:

internal class TableDataProvider {
  ...
  public object get_value(int x,int y);
  public void put_value(int x,int y,object value);
};

public class Table {
  private TableDataProvider data;
  public Row get_row(int y){ return new Row(data,y); }
  public Column get_column(int x){ return new Column(data,x); }
  public Cell get_cell(int x,int y){ return new Cell(data,x,y); }
};

public class Row {
  private TableDataProvider data;
  private int row;
  internal Row(TableDataProvider d,int y){ data=d; row=y; }
  public object get_cell(int x){ return new Cell(data,x,row); }
};

public class Column {
  private TableDataProvider data;
  private int column;
  internal Column(TableDataProvider d,int x){ data=d; column=x; }
  public object get_cell(int y){ return new Cell(data,column,y); }
};

public class Cell {
  private TableDataProvider data;
  private int row;
  private int column;
  internal Cell(TableDataProvider d,int x,int y){ data=d; column=x; row=y; }
  public object get_value(){ return data.get_value(column,row); }
  public void put_value(object value){ data.put_value(column,row,value); }
};


Тривиально, не правда ли? Что в этом хорошего?

1. Мы отделили пользовательский интерфейс от внутреннего. Теперь первый можно менять или сделать их несколько с разными версиями, работающие одновременно с теми же данными. И внутреннее представление можно менять и не трогать пользовательские интерфейсы.
2. Все многочисленные объекты объектной модели создаются и существуют только пока они нужны пользовательскому коду и после этого уничтожаются. Они все будут эффективно собраны сборщиком мусора 0-го поколения.
3. Явно видна и понятна стоимость решения. Хотите легкой в обучении и browseable объектной модели - вот её стоимость - несколько операторов new. Хотите эффективности? Давайте добавим get_value/put_value в объект table и немножко сэкономим.
4. Все внутренние вычисления делаются внутри провайдера, пользовательские объекты тут вообще ни при чем.
5. Возможны любые shortcut-ы, как вниз так и вверх. Например, можно добавить метод/свойство получающий объект "таблица" из любого объекта.

Как же мы храним данные внутри TableDataProvider? В массивах и хеш-таблицах. Желательно как value-type, без создания множества объектов, и без "boxing". Это уменьшит расходы памяти и упростит работу сборщика мусора. Можно создать специальные индексы для данных, и разместить данные в соответствии с "access patterns". А если ваша таблица будет настолько большой, что вы захотите запихнуть её в базу данных, переделайте провайдер и всё.