Handful of sand

One of the domain entities in my application is a concurrency controlled resource. To give an example, say a NoteBook to which only one user can write at a time, by acquiring a lock.

So i thought of introducing a Lock abstraction to hold lock specific information (who owns the lock, since when). Now a Lock can either soft or hard. A Soft lock held by one user can be acquired(usurped) by someone else. A Hard lock has to be relinquished by the lock owner himself.

My initial approach was to use an enum to realize the lock type. So my Lock abstraction looked as below

public class Lock {
    private boolean locked;
    private User owner;
    private DateTime since;
    private LockType type;
..............
    public static enum LockType {
        SOFT, HARD;
    }
}

When i was typing out the enum definition, it struck me that i was not giving enough importance to the lock type, after all thats what defines a lock. Something like below is what i thought of

public class LockBase {
    private boolean locked;
    private User owner;
    private DateTime since;
....
}

public class SoftLock extends LockBase {
//empty
}

public class HardLock extends LockBase {
//empty
}

So which one did i go with?

I went with the first option of keeping the type as an attribute. I didn’t see any need for the derived classes SoftLock, HardLock because Lock does not have much functionality that differs by the type. And the choice could have been different if Lock was a key abstraction (and not just an anemic value object)