Marker interface pattern: Difference between revisions

Revision as of 09:18, 29 July 2023

Latest revision as of 13:29, 20 July 2025

(3 intermediate revisions by 3 users not shown)

Line 1:

{{Short description|Design pattern in computer science}}

{{Refimprove|date=June 2013}}

The '''marker interface pattern''' is a [[design pattern (computer science)|design pattern]] in [[computer science]], used with languages that provide run-time type information about objects. It provides a means to associate metadata with a class where the language does not have explicit support for such metadata.

Line 26 ⟶ 27:

</syntaxhighlight>A class implements this interface to indicate that its non-[[Transient (computer programming)|transient]] data members can be written to an {{Javadoc:SE|java/io|ObjectOutputStream}}. The <code>ObjectOutputStream</code> private method <code>writeObject0(Object,boolean)</code> contains a series of <code>instanceof</code> tests to determine writeability, one of which looks for the <code>Serializable</code> interface. If any of these tests fails, the method throws a <code>NotSerializableException</code>.

== Critique ==

== Use Cases of Maker Interfaces ==

A majorOne problem with marker interfaces is that, since an interface defines a contract for implementing classes, and that contract is inherited by all subclasses., Thisa meansmarker thatcannot you cannotbe "unimplementunimplemented" a marker. In the example given, if you create aany subclass that you do not wantintended tofor serializeserialization (perhaps because it depends on transient state), you must resort to explicitly throwingthrow <code>NotSerializableException</code> exceptions (per <code>ObjectOutputStream</code> docs).

Some of the use cases of marker interfaces are mentioned below:

* '''Categorization and Identification''': Grouping classes based on characteristics (e.g., Serializable, Cloneable).

* '''Runtime Type Checking''': Checking if an object belongs to a specific category.

* '''Enabling Additional Functionality:''' Signaling eligibility for specific operations or enhancements.

* '''Integration with Frameworks and Libraries:''' Identifying and handling specific types of objects.

* '''Documentation and Contracts:''' Communicating expected behavior or capabilities.

* '''Compatibility and Extensibility:''' Designing classes to adapt to future features.

* '''Conditional Behavior or Logic:''' Enabling specific actions based on marker interface presence.

== Critique ==

A major problem with marker interfaces is that an interface defines a contract for implementing classes, and that contract is inherited by all subclasses. This means that you cannot "unimplement" a marker. In the example given, if you create a subclass that you do not want to serialize (perhaps because it depends on transient state), you must resort to explicitly throwing <code>NotSerializableException</code> (per <code>ObjectOutputStream</code> docs)

Another solution is for the language to support [[metadata]] directly:

Line 48 ⟶ 38:

==References==

{{Reflist}}

{{Reflist}}<ref>{{Cite web |title=Marker interface in Java: Valuable Insights |url=https://javagyansite.com/2020/04/25/marker-interface-in-java/ |url-status=live |website=javagyansite}}</ref>

== Further reading ==

''Effective Java''<ref>{{Cite book |last=Bloch |first=Joshua |url=https://www.worldcat.org/oclc/1018432176 |title=Effective Java |date=2018 |isbn=978-0-13-468599-1 |edition=Third |___location=Boston |oclc=1018432176}}</ref> by [[Joshua Bloch]].

{{Design Patterns patterns}}