Creating SOLID immutable and mutable Location types

To ensure immutability, you must make the class final or define a package-private constructor (it's assumed that somebody sneaking in your package is a sin freeing you from all your promises).

The big problem with your ImmutableLocation is that it's not thread-safe as an immutable class should be. No final fields, no safe publishing.

interface Locatable {

I don't see what you need it for. A Location as an abstract class is good enough, unless you want to let people add their own implementations.

1. I'm not sure if the enum is an overkill

And you won't be sure until it's used a lot. There's typo in its name (IncremeantOperation).

2. If the setters are a violation of SOLID; I'm not sure how else I should do it.

Not having them in the immutable class is the best option. You could make the fields protected and add the setters in the mutable subclass... but this isn't better either.

3. If UnsupportedOperationException is best fit for the adjust method.

It should be abstract, unless there's a very good reason for not implementing it in a member. But what should be such a member good for if it does not implement the only operation it should implement?

However, UOE is for me always a sign of an imperfection. But we don't live in a perfect world and the alternatives to UOE are often worse (class hierarchy blow up). OTOH with mere two concrete classes, there should be a better way.

When I wrote a similar class, I left everything out of the superclass what wasn't really common. An immutable class has final fields while a mutable one has non-final fields, so there are none in common.

abstract class Location {
    abstract int getX();
    abstract int getY();
}

@Getter @Setter
final class MutableLocation extends Location {
    private int x;
    private int y;

    adjust...

    // I find this pretty useful....
    ImmutableLocation toImmutableLocation() {...}
}

@Getter @RequiredArgsConstructor
final class ImmutableLocation extends Location {
    private final int x;
    private final int y;

    // ... and this too.
    MutableLocation toMutableLocation() {...}
}

The Lombok annotations do exactly what you think they do. If you don't want to use them, you can write the boilerplate manually.

You can replace the abstract superclass by an interface if you prefer. But I guess, you don't need both.

Your IncrementOperation enum is total overkill. Remember that integers can be negative, so location.adjustX(5, IncrementOperation.DECREASE) is exactly equivalent to location.adjustX(-5) when that method is implemented as

void adjustX(int delta) {
    setX(getX() + delta);
}

Are these classes SOLID? Well, we can look at the list:

• Single Responsibility Principle: Yes, your classes represent a possibly mutable coordinate.

• Open–Closed Principle: This is more difficult since two different ideas hide behind that name:

  (1) You can modify a class by subclassing it and inheriting most of its behaviour. Oh God, please not! See the “Fragile Base Class Problem” on why this might be a moronic idea. This might be a consideration for C++ libraries, but it ought to be discouraged everywhere else.

  (2) You can switch out a class in a system by reimplementing its interface. This is possible here since you wrote a Locatable interface. But is following the OCP sensible in your case? My take is that architecture requirements for a published API and for internals code is drastically different: With internal code, you control all dependencies and can therefore safely do arbitrary changes of behaviour. But when you don't control all code that may depend on Location, it might make sense to support the OCP so that other people can write a CustomLocation that suits their needs. In that case, you should also publish a separate interface for the methods of MutableLocation.

• Liskov Substitution Principle: Your two subclasses are proper subtypes of Location. However, it is possible to create a subclass of the ImmutableLocation that violates the LSP. It would make very much sense to make that class final.

• Interface Segregation Principle: All your interfaces are sufficiently small.

• Dependency Inversion Principle: Your code has no dependencies, therefore no dependencies could be inverted. Looks good!

So to summarize, your classes generally pass the SOLID tests, although there are some details where you have to think about what you actually want.

Another point I noticed is that you do not use @Override annotations when implementing interface methods. Consider doing that, it especially makes it easy to see at a glance whether this allows consumers of the class to depend on interfaces rather than on concrete classes.

This is how you implement quasi-mutable value objects, without generating class hierarchy clutter:

public class Location {
    private final int x;
    private final int y;

    public Location(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() {
        return x;
    }

    public int getY() {
        return y;
    }

    public Location withX(int newX) {
        return new Location(newX, this.y);
    }

    public Location withY(int newY) {
        return new Location(this.x, newY);
    }
}

Of course replace withFoo methods with more meaningful names from the domain, whenever available. Think of BigDecimal. It is immutable but you can add another BigDecimal to it.