Определите, какие поля POJO доступны в коде - PullRequest
Новая
       17

Определите, какие поля POJO доступны в коде

2 голосов
/ 22 мая 2019

У меня есть огромный (родительский) POJO, который используется в каком-то компоненте.POJO имеет отдельные поля, а также вложенные POJO.Можно ли определить, какие все поля / вложенные поля из этого POJO доступны в этом компоненте?

Я думал о JUnits / аспектах, но не уверен, сработает ли какое-либо из них.Я пытался просмотреть SF / и Google, но не смог найти ни одной соответствующей темы для этой вещи.

Скажем, ниже приведен пример POJO: 

public class Student {

  private String name;
  private Date date;
  private Subject subject;

  public String getName() {
    return name;
  }
  public void setName(String name) {
    this.name = name;
  }
  public Date getDate() {
    return date;
  }
  public void setDate(Date date) {
    this.date = date;
  }
  public Subject getSubject() {
    return subject;
  }
  public void setSubject(Subject subject) {
    this.subject = subject;
  }

}

У него есть три поля имя, датаи предмет, не все из которых будут использоваться в моем компоненте.Поэтому мне нужно определить, какие из них на самом деле используются.

Редактировать: Спасибо Шарон за то, что указал, что геттер / сеттеры были защищены.Я только что создал класс на лету для целей вопроса и не заметил проблемы.Исправлено сейчас.Как инициализируется класс: Для целей компонента объекты будут создаваться из данных Json / XML и иметь только вызываемые методы getter.Что касается статического и динамического анализа, я бы предпочел добиться этого с помощью статического анализа кода, если это возможно, в противном случае время выполнения также подойдет мне, если это проще.Что касается использования шаблона Decorator, есть ли у нас что-либо, не требующее изменения существующего кода?Вот почему я подумал, может ли JUnits сделать это.

1 Ответ

1 голос
/ 22 мая 2019

Прежде всего, странно видеть защищенные методы получения / установки. мне кажется они должны быть публичными?
В любом случае, я бы использовал шаблон оформления Decorator . Из связанной статьи:

Шаблон дизайна декоратора позволяет нам динамически добавлять функциональность и поведение к объекту, не влияя на поведение других существующих объектов в том же классе.

Итак, наш украшенный ученик должен унаследовать от целевого класса. Все методы могут регистрировать их использование и вызывать super для вызова целевой операции. Вы не сказали, как Student инициализируется, но в любом случае вы захотите изменить это для создания экземпляров LogUsageStudent

public class LogUsageStudent extends Student {

  protected String getName() {
    // log usage of getName() 
    return super.getName();
  }
  // etc
}
...