Collectible Card Game Headquarters

I know there are people who live and die by the interface segregation principle but I'm of the opinion that an abstract class works as good as an interface to define a contract, if not better. And it comes with the advantage that you don't need the extra redirection level nor the duplication.

I only use interfaces in two cases.

• There are at least 2 immediate implementations in the abstraction tree and there is no instance behavior that would render an abstract class more suitable.
• You want to restrict the API and define the interface so that you can pass object with as much methods as needed.

I did this for the Watcher/WatcherImpl pair. It worked like a charm.

One more point in favor of this refactoring would be to have consistency in the codebase.

Generally no problem for me to remove interface classes if not needed.

And if it's very easy to remove so the interface could not be so neccessary for this class.

I have to admit that IntelliJ is awesome for navigating code and refactoring. It is very easy to inline the interfaces in the Impl classes. Before I go on to merge my changes, I created a branch where I already did this for all the Effect class hierarchy. Please take a look and let me know what you think.

If everything looks good, I'll go ahead and merge this changes and go on to the remaining interfaces with an Impl class implementation.

PS: Extracting an interface if needed is also simple. Since the interface defines getters and things like this, I believe we are better of just using the abstract classes for defining a contract.