Инкапсулировать то, что не меняется?

Question

Общепринятой практикой является инкапсуляция кода, который часто изменяется. Фактически, это часто в форме использования объекта для делегирования различной логики. Образец будет следующим:

public class SampleClass { 
    Object obj = new ObjectWithVaryingMethod(); 
    public SampleClass(Object obj){ 
     this.obj=obj; 
    } 
    public String getString(){ 
     return obj.toString(); 
    } 
    public static void main(String args[]){ 
     SampleClass sampleClass=new SampleClass(new ObjectWithVaryingMethod()); 
     System.out.println(sampleClass.getString()); 
    } 
} 

class ObjectWithVaryingMethod{ 
    @Override 
    public String toString(){ 
     return "Hi"; 
    } 
} 

Можете ли вы предложить какие проблемы я могу столкнуться, когда «инкапсуляция» делается на то, что не меняется? Я считаю, что это хорошее поведение при кодировании, когда основным классом является тот, который часто подвержен изменениям или улучшениям. Образец будет следующим. В этом втором случае получение «Привет», которое является частью, которая не меняется, была «инкапсулирована» в другой класс.

public class SampleVaryingClass { 

    public static void main(String args[]) { 
     //here I may opt to print getHi's value on sysout or on a dialog 
     System.out.println(ObjectWithNonVaryingMethod.getHi()); 
    } 
} 

В совершенно другом классе ...

public class ObjectWithNonVaryingMethod { 
    private static final String hi = "Hi"; 
    //"Hi" should always be returned 
    public static String getHi() { 
     return hi; 
    } 
} 

Можете ли вы дать некоторые профи и против делать это?

Answer 1

Оба кода не могут сравниваться друг с другом. Один из них статичен, другой - нет. Надеюсь, вы понимаете концепцию инкапсуляции объекта в первый код. Вот плюсы и минусы для второго. Помните, что статичность «вообще» плохая и не поддерживает параллелизм по умолчанию.

плюсы:

1. С getHi, вы оставляете поле строки частное, а это означает, что он не может быть установлен из другого источника

2. Скажите, что вам нужно сделать setHi из другого источника, вам может добавить к нему несколько оговорок охраны. Это называется defensive programming.

   public static setHi(String input){ 
       if(input == null) { input = ""; } // can throw exception instead 
       hi = input; 
   } 
   

минусы:

1. Он статичен, разумеется
2. Вы не получите никаких преимуществ, кроме защитных положений. Если ваш класс не является статичным, вы можете поменять его другим классом, реализующим тот же интерфейс, или другим классом, унаследованным от этого класса.