of marker interfaces. Neither in any codebase, nor in resources/documentation/books i.e. examples. I doubt that it's open source, but if it is, can you please share the link? Neither I've ever heard about such anti-pattern being described. Again, if you have a link to any resource about it can you post it here?
One more thing to clarify. this is not a marker interface:
interface Dog {
bark();
}
interface DomesticDog extends Dog {
// empty but not marker
}
interface FightingDog extends Dog {
fight(Dog withOther);
}
interface HuntingDog extends Dog {
hunt(Animal fowl);
}
In the code above interface DomesticDog is empty, but it's totally OK and is a good design. It indicates that type "DomesticDog" is a specialization of Dog but has nothing special. Yet. And this is the key factor - YET. Marker interfaces will always be empty whatever way the design would change. They are like tags.
Thus, I can't say for sure what exactly do interfaces in your codebase do.
If they are true marker interfaces. For classification in 100% I've ever faced it was done either this way in old java (you can often find such code in old projects):
interface HttpResponseType {
static final int OK = 200;
....
}
class HttpResponse {
int type;
}
or with enums (was it java 1.5+ ? can't remember when enums were added):
enum HttpResponseType {
OK,
...
}
class HttpResponse {
HttpResponseType type;
}
And in the client code you just check that type propertly of the object. Havent ever seen such classification was done with instanceof and true marker interfaces. Ever.
I can see several drawbacks of using marker interfaces for classification with instanceof operator:
- it's totally uncommon technique and has no any real advantages over using enums (which is common and thus readable); so other would guess about the real purpose of using those marker interfaces (what actually I'm doing here)
- the cost of instanceof operation is much higher than simple identity check with type == Type.ENUM_CONSTANT.
- polluting your project sources structure with totally different substance: all the xxx.java files actually represent type or utility class (non-instantiable/singleton with utility methods). But markers/tags are different, and they'll pollute sources and bring confusion for new developers.
But I can't see any huge "smell", no any real stopper to not use it. It's just so uncommon.
But having marker interfaces being used like tags makes sense. It really matters how exactly those marker interfaces are used. For example, the famous Serializable is used not for classification but for adding special ability/treatment from the runtime side. I could imagine the same with some framework, but all of them use annotations for this (or I just havent payed attention to this and cant remember now).
thnx, was useful! The project which I am am working on, is closed-source and the last developer who was working on it, added a lot of interfaces without any method or constant variable. accourding to what you said, now I'm sure they should be deleted soon.👍
Обсуждают сегодня