Mutable класса как ребенок неизменного класса

Question

Я хочу иметь неизменное Java объектов, как это (сильно упрощено):

class Immutable { 

    protected String name; 

    public Immutable(String name) { 
     this.name = name; 
    } 

    public String getName() { 
     return name; 
    } 

} 

В некоторых случаях объект должен быть не только для чтения, но изменяемым, так что я мог бы добавить изменчивость по наследству:

public class Mutable extends Immutable { 

    public Mutable(String name) { 
     super(name); 
    } 

    public void setName(String name) { 
     super.name = name; 
    } 

} 

Хотя это технически хорошо, мне интересно, если это согласуется с объектно-ориентированным программированием и наследованием, что изменяемое также типа неизменных. Я хочу избежать преступления ООП, чтобы бросить UnsupportedOperationException для неизменяемого объекта, как это делает API коллекций Java.

Что вы думаете? Любые другие идеи?

Answer 1

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

Joda Time использует «ReadableXXX», чтобы дать понять, что «этот класс предоставляет доступ только для чтения, другие подклассы могут быть изменчивыми». Я не уверен, нравится ли мне эта идея, но я не могу сказать, что видел много альтернатив.

В основном проблема с выражения отрицательной - Immutable описывает то, что вы не можете сделать (мутировать его), и что не может быть разумно применяться в подклассах. (Даже если поля в пределах Immutable были окончательными, это не остановило бы подкласс с собственными изменчивыми полями.)

Answer 2

Неизменяемые классы должны быть final точно, чтобы избежать измененных подтипов.

Предоставление подтипа неизменяемого класса для расторжения неизменяемого контракта делает его совершенно бессмысленным для того, чтобы класс был непреложным в первую очередь. Это может быть законным в том смысле, что Java позволяет вам это делать (неизменность не применяется на языке), но такой класс не действительно непреложный, если он может быть подклассифицирован.

Вот почему строка является окончательной.

Answer 3

Я нахожу ваш код довольно любопытным.

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

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

Answer 4

Ваш подкласс плох, потому что он нарушает Liskov substitution principle. Не делай этого.

Answer 5

Я бы предположил, что у вас должен быть наследуемый базовый класс «ReadableFoo», производный закрытый класс ImmutableFoo и другие производные классы MutableFoo. Код, который не заботится о том, изменен ли Foo или нет, может принять ReadableFoo. Код, который хочет Foo, который гарантированно не изменится, может принять ImmutableFoo. Код, который может понадобиться для изменения Foo, может принять MutableFoo.

Обратите внимание, что конструкторы как для ImmutableFoo, так и для MutableFoo обычно должны принимать ReadableFoo. Таким образом, любой Foo будет конвертируемым в изменяемую или неизменяемую версию.