Почему создание защищенных свойств в bean-компонентах считается плохой практикой? - PullRequest
Новая
       25

Почему создание защищенных свойств в bean-компонентах считается плохой практикой?

2 голосов
/ 17 февраля 2010

Что я имею в виду: 

public class SomeBackingBean {

   protected String someString;

   public void setSomeString (String str) { 
      this.someString = str; 
   }

   public String getSomeString {
      return someString;
   }
}

Это был просто общий случай общего ответа.

Теперь второй пример: 

public abstract class AbstractBean<T extends EntityInterface> {

   protected T entity;

   public void setEntity (T t) {
      this.entity = t;
   }

   public void getEntity () {
      return entity;
   }

   protected ReturnType calculateSomethingCommon () {
      //use entity (knowing that it implements EntityInterface) 
      //to implement some common for all subclasses logic
   }
}

public class ConcreteBean extends AbstractBean<ConcreteEntity> {
   ...
   //and here we can write only specific for this bean methods
   ...
}

Второй пример тоже пример плохой практики?

Ответы [ 2 ]

6 голосов
/ 17 февраля 2010

Как правило, защищенные переменные нарушают объектно-ориентированные принципы. Вы предоставляете другим объектам прямой доступ к переменным-членам. Таким образом вы формируете более тесную связь, и это усложняет изменение переменной, поскольку другие объекты используют ее напрямую. Это также означает, что вы не можете делать такие вещи, как проверка, когда она установлена, добавлять ведение журнала для получателей / установщиков и т.д.

0 голосов
/ 17 февраля 2010

Если, например, у вас есть PropertyChangeListener, зарегистрированный в свойствах компонента, любые зарегистрированные прослушиватели могут не получать уведомления, если защищенное свойство изменяется непосредственно подклассом.

...