Каковы некоторые общие стратегии для рефакторинга больших объектов только для состояния?
Я работаю над конкретной системой поддержки принятия решений в режиме реального времени, которая делает онлайн-моделирование/моделирование национального воздушного пространства. Эта часть программного обеспечения расходует множество каналов передачи данных в реальном времени и дает оценку "состояния" большого количества объектов в воздушном пространстве раз в минуту. Проблема расплывается аккуратно, пока мы не ударим то, что в данный момент является сущностью самого низкого уровня.
Наша математическая модель оценивает/прогнозирует более 50 параметров для временной шкалы в несколько часов в прошлое и будущее для каждого из этих объектов, примерно один раз в минуту. В настоящее время эти записи кодируются как один Java-класс с большим количеством полей (некоторые из них сворачиваются в ArrayList). Наша модель развивается, и зависимости между полями еще не установлены в камне, поэтому каждый экземпляр блуждает по запутанной модели, накапливая настройки по мере ее продвижения.
В настоящее время мы имеем что-то вроде следующего, которое использует шаблон шаблона построителя для создания содержимого записи и обеспечивает соблюдение известных зависимостей (в качестве проверки на ошибку программиста как на развитие режима.) Как только оценка мы преобразуем приведенное ниже значение в неизменяемую форму с использованием метода типа .build().
final class OneMinuteEstimate {
enum EstimateState { INFANT, HEADER, INDEPENDENT, ... };
EstimateState state = EstimateState.INFANT;
// "header" stuff
DateTime estimatedAtTime = null;
DateTime stamp = null;
EntityId id = null;
// independent fields
int status1 = -1;
...
// dependent/complex fields...
... goes on for 40+ more fields...
void setHeaderFields(...)
{
if (!EstimateState.INFANT.equals(state)) {
throw new IllegalStateException("Must be in INFANT state to set header");
}
...
}
}
Как только очень большое количество этих оценок будет завершено, они будут собраны в сроки, когда анализируются совокупные модели/тенденции. Мы рассмотрели использование встроенной базы данных, но боролись с проблемами производительности; мы предпочли бы получить эту информацию с точки зрения моделирования данных, а затем постепенно перемещать части кода в режиме реального времени во встроенный хранилище данных.
После того, как это будет сделано с учетом времени, продукты будут очищены от плоских файлов и базы данных.
Проблемы:
- Это гигантский класс с слишком большим количеством полей.
- В классе очень мало поведения, закодированного; это в основном держатель для полей данных.
- Поддержание метода
build()чрезвычайно громоздко. - Неудобно вручную поддерживать абстракцию "автомата" только для того, чтобы обеспечить достаточное заполнение объекта данных большим количеством зависимых компонентов моделирования, но это сэкономило нам массу разочарований по мере развития модели.
- Существует много дублирования, особенно когда записи, описанные выше, объединяются в очень похожие "свопы", которые составляют скользящие суммы/средние или другие статистические продукты указанной структуры во временных рядах.
- В то время как некоторые из полей могут быть сгруппированы вместе, все они логически "сверстниками" друг друга, и любая пробой, который мы пробовали, привел к тому, что поведение/логика была искусственно разделена и ей необходимо достичь двух уровней в глубину косвенности.
Вне коробки идеи развлекали, но это то, что нам нужно, чтобы постепенно развиваться. Прежде чем кто-либо еще это скажет, я отмечу, что можно предположить, что наша математическая модель недостаточно четкая, если представление данных для этой модели трудно получить. Справедливая точка зрения, и мы работаем над этим, но я думаю, что побочный эффект среды R & D с большим количеством участников и множество параллельных гипотез в игре.
(Не то, чтобы это имело значение, но это реализовано на Java. Мы используем HSQLDB или Postgres для выходных продуктов. Мы не используем рамки персистентности, частично из-за незнания, отчасти потому, что у нас есть проблемы с производительностью просто база данных и ручные системы хранения данных... мы скептически относимся к дополнительной абстракции.)
