Let's start with a loose definition of 'marker interface' (please correct me or dispute this if you disagree):
If applied to a type, a marker interface doesn't provide any contract of methods to implement for that type. A marker interface gives semantic meaning.
So, OK, that's fine. However giving something a meaning has to ultimately have a practical consumption or usage elsewhere to be of benefit, right? So we may have two types that are different, but that are (for example) types related to 'scheduled tasks' in a system, so we may 'decorate' them both with an 'IAmTask' interface.
OK, so how do we then put that to practical use? I've read that:
One of the benefits of a marker interface is to 'communicate a semantic constraint/guarantee that doesn't otherwise change the API'.
OK, well a marker interface isn't defining a contract for methods that must be present on the type, so what's a practical example in code of how a semantic constraint/guarantee can be ultimately be returned to the user and consumed in a way that tightens up the intended guarantee to the consumer, without enforcing methods on the API? There must be a way to do this, otherwise we're simply declaring an essentially useless meaning.
java.util.RandomAccess
which guarantees that indexed access to a list is efficient? All lists support indexed access, but only the ones that implementRandomAccess
support efficient indexed access. – user253751 Jul 7 '17 at 0:06