Talk:Marker interface pattern

Untitled

Maybe a bit offtopic, but I do not see the point having the clone() method in Object and a seperate interface making a call to clone "valid". Where is the advantage over letting Clonable have (is this correct english?) a method clone() (making this a non-marker interface) or is this for historical reasons? :) A better example for a marker interface would be appreciated.

I agree. It's exactly what I thought when I read the article. Alf Boggis (talk) 14:26, 8 November 2005 (UTC)

That's because it isn't why Cloneable exists. Nowhere do the docs say that Cloneable "indicates that the cloning functionality is actually supported in a proper manner". In fact, they're very specific about why Cloneable is used, and that it gives specific information to Object.clone().

Will be editing the article once I figure out Wikipedia's markup (rhetorical question: why do all wikis have a different set of codes?). Serializable is a better example of a marker interface, because Java provides multiple ways to write an object.

Introduction paragraph

In the last sentence of the introduction paragraph, the statement "If none of these tests pass, the method throws NotSerializableException." is made. My knowledge of java isn't that strong, but should it be "If any of these tests fail, the method throws NotSerializableException."? --WikiWizard (talk) 00:29, 26 March 2008 (UTC)

Further clarification needed

I think a further clarification should be added why an interface is defined to be a marker interface. For instance, it is not clear to every reader

• why the Serializable interface does not have a serialize(…) and a deserialize(…) method, say, so that all the "marked" classes have the same methods for the same task, and
• why JavaBeans are not using a marker interface to mark them as beans as such in a conspicious way.

SAE1962 (talk) 07:34, 5 May 2008 (UTC)

Critique

The critique section imho shows an inappropriate example. The scenario appears to be a liskov violation. If this is resolved, the use of the tagging interface is perfectly sane in the example. This should be at least mentioned. On the other hand - and that would imho make a good critique point - if some state or ghost intrinsic to a class needs to be expressed with a marker and is not handled by other means, this smells a lot like there's a refactoring needed. If you deal with classes members "in a specific way" depending on an empty interface, this makes the use of the API which defines the members in the first place unsafe - and that should of course be avoided. — Preceding unsigned comment added by 193.32.64.180 (talk) 09:37, 9 August 2013 (UTC)