Skip to main content

Marker Interface

The Marker Interface pattern tags a class with an empty interface so code can detect a capability via runtime type checks. It integrates with the type system but conveys no contract; annotations often replace it.

Type
Structural
When to Use
Tag Types With Metadata, Runtime Type Detection, Opt In Framework Behavior, No Methods To Add

The Marker Interface pattern uses an interface with no methods or fields purely to mark, or tag, a class as having some property. Other code checks at runtime whether an object's type implements the marker and changes behavior accordingly. It solves the problem of associating a yes/no capability or category with a type when there is no behavior to add — the membership in the interface is the whole signal.

How It Works

You declare an empty interface — for example Serializable — and have classes that should carry the property implement it. Elsewhere, code uses a type check (instanceof in Java, is in C#) to ask whether an object implements the marker; if so, it applies the corresponding behavior. The marker conveys metadata at the type level that the language's type system and reflection can see.

Many platforms now offer annotations or attributes (Java annotations, C# attributes, Python decorators) as a more expressive alternative, since they can carry parameters and target methods or fields, not just types. The classic examples remain marker interfaces: Java's Serializable, Cloneable, and RandomAccess.

When to Use It

Use a marker interface when you need to flag types with a capability that affects how a framework or library treats their instances, when the flag is a simple boolean property of the type, and when you want compile-time association (a class declares the marker in its definition) plus runtime detectability. It is appropriate when no methods belong on the interface and when you want the type system to participate, such as letting tools or generics constrain to marked types.

Prefer annotations/attributes when the metadata needs parameters, applies to members rather than whole types, or should be queryable without a type relationship.

Trade-offs

Marker interfaces are simple, integrate with the type system (you can use the marker as a generic bound or method parameter type), and make the tag visible in the class declaration. Detection is fast via a normal type check.

The drawbacks are notable. A method-less interface is widely considered a code smell because interfaces are meant to specify behavior; marking conveys no contract. The mark is inherited by subclasses whether or not it remains appropriate, which can be wrong and cannot be revoked. Markers cannot carry data, and their meaning lives in the consuming code rather than the interface itself, hurting discoverability. For these reasons many style guides recommend annotations instead.

Related Patterns

Marker Interface relates to the Decorator and Visitor patterns insofar as all let external code vary behavior based on type, but markers add no methods. It contrasts with Adapter, which adds an interface to change shape and behavior. Annotation/attribute-based metadata is its modern successor for most uses.

Example

A persistence framework only writes objects that implement the empty Persistable marker. When asked to save an object, it checks obj instanceof Persistable; if true it proceeds, otherwise it throws. Domain classes opt in by declaring implements Persistable with no extra code. A modern equivalent would replace the marker with an @Persistable annotation that the framework discovers by reflection, allowing extra parameters like a table name.