Классическое внедрение SQL ASP

Ответ на предыдущий комментарий в @me здесь из-за моей репутации:

Vlookward, не запись методов get/методов set не имеет никакого смысла вообще. Единственные опции для установки частных полей состоят в том, чтобы иметь явные методы set, чтобы установить их в Вашем конструкторе или установить косвенно с помощью других методов (функционально задерживающий метод set к другому месту). Почему бы не использовать методы set?

ну, иногда, нет никакой потребности к полю быть частной (Извините, если мой английский язык не очень хорош). Часто, мы пишем наше программное обеспечение, поскольку это была библиотека, и мы инкапсулируем наши поля (наши поля бизнес-логики) с ненужными методами get/методами set.

Другие времена, что методы на самом деле необходимы. Затем существует две возможности:
1. Существует бизнес-логика в них. Тогда они должны быть протестированы, но они не настоящие методы get/методы set. Я всегда пишу что логика в других классах. И тестовый тест, что другие классы, не POJO.
2. Нет. Затем не пишите им вручную, если Вы можете. Например, реализация для следующего интерфейса может быть полностью автоматически сгенерирована (и также во времени выполнения!):

interface NamedAndObservable {
  String getName();
  void setName(String name);
  void addPropertyChangeListener(PropertyChangeListener listener);
  void addPropertyChangeListener(String propertyName,
                                 PropertyChangeListener listener);
}

Так тестируют только, что записано вручную. Неважно, если это - метод get/метод set.