Immutable and mutable object

Question

Here I want to post some solutions to immutable and mutable objects. First I'll brifely discribe the case when only one type (immutable or mutable) is need accross the application. Then, I'll describe case when both types is using. And finally, the case when only some object can modify this object, while for others it is immutable one. That will be illusrated on the objects discribing current date as number milliseconds from Zero Epoch Era (January 1, 1970).
Let's start from an exampe for Immutable Object.
public final class ImmutableDate {
    private final long date;
    public ImmutableDate(long date){
         this.date= date;
    public long getDate(){
        return date;
}The class is final, so it is imposible to extend it (if it is possible to extend it, it will be possible to add some mutable data-members to the class. Data-member is final to avoid changing (if it is Object it is just warning to programmer not to change it, compiler just can check that reference wasn't changed, but state of this data-member can be changed). There is no method that returns reference to the data-member outside the ImmutableDate. (if data-member was immutable object,it would be possible to return refference to it, if data-member was mutable object and it was possible to revieve reference to it, than it was possible to change the state of data-member through setter function).
Now, lets consider that we need only MutableDate. The implementation is obvious:
public  class MutableDate {
    private long date;
    public MutableDate (long date){
         this.date= date;
    public long getDate(){
        return date;
    public void setDate(long date){
      this.date=date;
}This is regular class.
The question is how what should I do in the case I need both[b ]Mutable and Immutable Object. It is possible to use the above way of implementation. But there are following problems wih this:
* Code is not re-usable. For example, getDate() is implemented twice.
* Implementation is closed to the interface.
* There is no abstraction such a Date. Usable, when we doen't care whether object is mutable or immutable.
It will be also nice to have a mechanism to recieve immutable copy from any object. It can be implemnted as getImmutableDate() function. This function is usable, when we have Date object (or MutableDate) at hand and want to store it in HashMap. So immutable copy is needed. It also usable as deffencive copy of MutableDate, if want one to transfer Date to simebody we don't want to change the state.
Second and third points leads us to declare interfaces:
public interface Date {
  public long getDate();
  public ImmutableDate getImmutableDate(); 
public interface ImmutableDate extends Date  {
public interface MutableDate extends Date {
  public void setDate(long date);
public final class ImmutableDateImpl implements Date, ImmutableDate {
public class MutableDateImpl  implements Date, MutableDate {
}Lets talk more on the first point. In this short example it will look like it is not bug disadvantage. But think, that there are ten data members and setting other value isnot trivvial (for example, other private data members should be recalculated) and you'll realise that this is a problem. What solution OO proposed in such a cases? Right, inheritance. But there is one pitfalls here. Immutable object has to be final (see explanation above). So the only way to do this is to define some new class and inherit from him. It will be look like the following:
abstract class AbstractDate implements Date  {
   protected long date;
   public AbstractDate(long date){
     this.date=date;
   public long getDate(){
     return date;
public final class ImmutableDateImpl extends AbstractDate implements Date, ImmutableDate {
  public ImmutableDateImpl(long date){
    super(date);
  public final ImmutableDate getImmutableDate(){return this;}
public class MutableDateImpl extends AbstractDate implements Date, MutableDate {
  public MutableDateImpl(long date){
    super(date);
  public void setDate(long date){
    this.date=date;
  public final ImmutableDate getImmutableDate(){
    return return new ImmutableDateImpl(date);
}Note that AbstractDate is declare package-private. It is doing to avoid casting this type in the application. Note also that it is possible to cast immutable object to mutable (interface MutableDate doen't extends ImmutableDate, but Date). Note also that data memer is
protected long date;That is not private, but protected and not final. It is a cost of getting re-usability. IMHO, It is not big price. Being protected is not a problem, IMHO. Final is more for programmer, rahter than to compiler (see explanation above). Only in the case of primitive data type compiler will inforce this. programmer can know, that in he shouldn't changed this value in AbstractDate, and ImmutableDate, and he can do it only in MutableDate.
I want to write some words about getImmutableDate() function. This function is usable, when we have Date object (or MutableDate) at hand and want to store it in HashMap. So immutable copy is needed. It also usable as deffencive copy of MutableDate, if want one to transfer Date to somebody we don't want to change the state.
Let consider the following scenarion. We are writting a game, say chess. There are two players, that plays, desk where they play, and environmemnt (arbiter) that enforces rules. One of the players is computer. From OO point of view the implementation has to the following. There is Desk that only Environment can modify it. ComputerPlayer has to be able only to view ("read") the Desk, but not to move figute ("write"). ComputerPlayer has to talk with Environment what he want to do, and Environmnet after confirmation should do it. Here desk is immutable object to everyone, but Environment.
If we go back to our Date, the implementation of this scenario could be
interface AlmostImmutableDate extends Date {
  public void setDate(long date);
public class Class1 {
  public static ImmutableDate getImmutableDate(long date){return new AlmostImmutableDateImpl(date);}
  private static class AlmostImmutableDateImpl implements Date, ImmutableDate/*, AlmostImmutableDate*/ {
    private long date;
    public AlmostImmutableDate(long date){
      this.date=date;
    public long getDate(){
      return date;
    public void setDate(long date){
      this.date=date;
    public final ImmutableDate getImmutableDate(){
      return this;
} Which such implementation only Class1 can modify AlmostImmutableDateImpl. Others even don't know about existance of this type (it is private static class).
It is possible to extends somehow to the case, when not one object, but (a little) group of object can modify Date. See the code above with uncommented part. One way to this is to difine new interface, say AlmostImmutableDate, with package-private scope. AlmostImmutableDateImpl will implements this interface. So, all object that has the same package as AlmostImmutableDate will can to cast the object to this type and modify it.
Note, that AlmostImmutableDate has to extend Date interface (or ImmutableDate), but not MutableDate! If it will extand MutableDate, than it wiil be possible to cast to MutableDate in any package.
If there is no MutableDate object in the application, so AlmostImmutableDate is unique. If there is MutableDate object in the application and we want to construct such almost immutable object, so copy&paste is needed to declare AlmostImmutableDate interface.
Summary.
It is difficult to define really pair of immutable object and mutable object in Java. Implementation consuming time and not very clear. There are many points to remember about (for example, data-member is not final, or order of inheritance, immutable object has to be final, and so on).
I want to ask. If these solutions are complete? That is, it is not possible to modify immutable object or almost immutable objects not in the package of AlmostImmutableInterface. Not using reflexion, of course.
Is these solutions are not to complicated?
What do you think about delcaration of the third class AbstractDate? Has it to implement date? Perhaps, it is possible to define Date as abstract class (as AbstractDate was)? What do you think about definning
protected long date;in AbstractDate?
What do you think about function getImmutableDate() defined in Date interface? Perhaps, it should be declared in other place (even other new interface) or shouldn't be delcare at all?

Answer 1

It seems to me that you are over thinking the problem:
Why not just:
public interface Date {
    long getDate();
public interface MutableDate extends Date {
    void setDate(long);
public class ImmutableDate implements Date
    final long date;
    public ImmutableDate(long date){
         this.date= date;
    public ImmutableDate(Date date){
         this.date= date.getDate();
    public long getDate(){
        return date;
public class ModifiableDate implements MutableDate
    final long date;
    public ModifiableDate(long date){
         this.date= date;
    public ModifiableDate(Date date){
         this.date = date.getDate();
    public long getDate(){
        return date;
    public void setDate(long date){
        this.date = date;
}