Отслеживайте статус объекта, регистрируя только испорченные поля
Когда я разрабатываю сложную логику для нескольких классов, я часто регистрирую сущности (часто с toString() внизу), чтобы проверить статус объекта, какое поле имеет какое значение. Я всегда нахожу журналы излишне многословными, печатая все поля. Трудно отследить:
- что было изменено и
- когда оно будет изменено
когда сущность проходит долгий путь через кучу классов.
Я хотел бы видеть только «испорченные» поля (поля, которые уже изменены/установлены до достижения строки кода журнала). Я представляю себе такое решение:
- установить значение в поле
- добавьте это поле на карту, например
taintedFields; ключ — это имя поля, а значение — фактическое значение. В идеале делать это в каждом сеттере. А еще лучше, абстрактный класс с таким шаблоном установки в качестве базового класса для всех классов модели/DTO, чтобы каждый установщик делалsuper.tainted(field, value)перед установкой значения. - при печати печатайте только эту карту; другие нулевые/пустые значения игнорируются
Идею несложно реализовать, но интересно, практично ли это? Это хорошая практика? Есть ли какое-либо существующее решение? Я не могу быть первым человеком, который когда-либо задумался об этом. Есть ли лучший способ сделать это?
Последнее редактирование:
Я понимаю причину, по которой этот вопрос закрыт, и меня это устраивает, у него нет ответа, основанного на фактах, но это единственное место, где я могу собрать мнения по этому поводу.
Наконец, я думаю, что это верная идея, но может возникнуть несколько трудностей:
- добавить базовый класс для всех классов модели/DTO — это большая работа в большом проекте; возможно, создайте суперкласс и наследуйте его при необходимости; или аннотация?
- рефлексия неизбежна, так как мы хотим, чтобы в будущем каждое существующее и вновь добавленное поле имело возможность отмечать статус испорченного или нет; поэтому необходима карта с ключами имени поля
- кроме того, возможно, не только испорчено или нет, но и когда и где (в каком классе, в каком методе и в какой строке) оно изменено, также желательно включить в некоторые строки журнала; но это выходит за рамки простого изменения кода; больше инструментов анализа байт-кода во время выполнения.
Ответы 2
Идея отслеживания измененных полей может быть практичной, особенно в сложной логике. и вы правы, вашу идею легко реализовать, но важно проверить ее на предмет проблем с производительностью, поскольку вы собираетесь добавить еще один уровень сложности в свою кодовую базу и усложнить обслуживание вашего приложения. Обычно большую часть времени я использую удаленную и локальную отладку и редко использую журналы для тестирования.
С другой стороны, я знаю, что отладка лучше всего работает на уровне объектов и логики, и ее сложно использовать на других уровнях, таких как постоянство или промежуточное программное обеспечение, при работе над большими сложными проектами.
Итак, я предлагаю, чтобы вы могли использовать свой метод для определенной критической логики, чтобы получить результаты в реальном времени, но я рекомендую использовать модульное тестирование с Mockito. Это действительно полезно имитировать ваши сервисы и напрямую вводить ваши значения, не повторяя бизнес-логику, и вы можете использовать Класс DiffBuilder для отслеживания различий между объектами.
Вы можете сделать это немного проще — логический массив, хранящийся в каждом классе, который вы хотите проверить. каждая ячейка массива будет соответствовать полю (порядок можно выбирать произвольно). Когда вы вызываете установщик для поля, он также переворачивает соответствующую ячейку массива с false на true. Когда вы вызываете toString для печати полей экземпляра, метод будет распечатывать только те поля, для которых соответствующая ячейка в массиве имеет значение true, а после завершения печати toString сбросит все ячейки массива обратно в значение false. Таким образом, вы будете распечатывать только те поля, для которых были установлены новые значения с момента последней контрольной печати, и вам не придется обрабатывать объект карты, что приведет к расточительству ресурсов.
Спасибо. Мне нравится экономить место, но я боюсь, что мой маленький мозг может забыть о расширении массива, когда я добавляю больше полей, и когда это произойдет, простая строка журнала вызовет исключение ArrayIndexOutOfBoundsException...
@WesternGun, не волнуйтесь - вы можете попросить методы toString и setter проявить терпение - если массив не покрывает все поля (скажем, вы добавили несколько новых полей и не израсходовали их), вы можете просто использовать значение по умолчанию к исходному поведению — установите значение, напечатайте значение, как и раньше. Таким образом, вы не выведете индекс за пределы.
Хорошо, удаленная отладка, о которой я не подумал. Мне нужно проверить, как это сделать в среде kubernete/openshift. О DiffBuilder я не слышал, но тоже проверю.