Marker interface pattern: Difference between revisions

Revision as of 04:39, 31 October 2008

Revision as of 17:39, 18 February 2009

Line 9:

== 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).

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

Line 15:

* The [[.NET Framework|.NET framework]] supports attributes that can be used to associate any type of data with a class or with its members.

* [[Java_(software_platform)|Java]], as of Java 5 (1.5), also provides [[Annotation|annotations]] [[Java_annotation|support]] on classes, member variables, methods, and method parameters that may be accessed from an instance using [[Reflection_(computer_science)|reflection]].

* In [[Python (programming language)|Python]], the use and term '''"marker interfaces'''interface" is common in [[Zope 3]] and [[Plone (software)|Plone]]. Interfaces are declared as metadata and subclasses can use <code>implementsOnly</code> to declare they do not implement everything from their super classes.

== See also ==