Patrón Marker Interface

Descripción general

El Patrón Marker Interface usa interfaces vacías (interfaces sin métodos) como etiquetas de metadatos para señalar propiedades o capacidades de una clase. A diferencia de anotaciones o atributos, los marker interfaces se verifican en tiempo de compilación por el sistema de tipos, lo que da garantías más fuertes que la reflexión en runtime sola.

El ejemplo canónico es java.io.Serializable y java.lang.Cloneable de Java. Ninguno define métodos, pero las clases que los implementan declaran su intención de ser serializadas o clonadas. Los frameworks y librerías usan checks de instanceof para decidir si aplicar un manejo especial.

Aunque las anotaciones han reemplazado en gran medida a los marker interfaces en Java moderno, el patrón sigue relevante donde las garantías en tiempo de compilación importan más que la flexibilidad — y es tema recurrente en entrevistas precisamente porque Cloneable es un fallo de diseño famoso.

Cuándo usarlo

Usa el Patrón Marker Interface cuando:

• Necesitas seguridad de tipos en tiempo de compilación para clasificar metadatos — una firma como void send(Serializable s) rechaza tipos sin marcar antes de que el código corra
• Checks de instanceof en runtime deberían determinar el comportamiento en código de framework
• Quieres evitar el costo en runtime de escanear anotaciones
• Una jerarquía de tipos expresa una capacidad de forma natural (ej. todos los objetos Renderable)

Para pipelines de enrutado y transformación en lugar de etiquetado de capacidades, consulta el patrón Pipes and Filters.

Cuándo evitarlo

• Lenguajes sin interfaces o con sistemas de tipos débiles (anotaciones/decoradores son mejores)
• Metadatos que necesitan parámetros (las anotaciones con valores son más expresivas)
• Cuando el rendimiento de la reflexión en runtime es aceptable y prefieres flexibilidad
• Cuando los markers proliferarían en docenas de tipos vacíos — eso es contaminación de interfaces, y deja la jerarquía más difícil de leer que las anotaciones

Solución

Python

Python no tiene interfaces nativas, y aquí vive una trampa sutil: un typing.Protocol vacío no puede actuar como marker. Los Protocols usan subtipado estructural, así que isinstance(x, Serializable) con cero miembros devuelve True para cualquier objeto. El marker tiene que ser una clase base real (vacía):

from abc import ABC
import pickle

# Clases base marker: vacías pero reales — las subclases optan explícitamente
class Serializable(ABC):
    """Marker: las subclases declaran que se puede serializar."""
    pass

class Cloneable(ABC):
    """Marker: las subclases declaran que admiten deepcopy."""
    pass


class User:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email


# Opt-in explícito mediante el marker
class SerializableUser(User, Serializable):
    pass


class Serializer:
    """Componente de framework que usa checks de markers."""
    @staticmethod
    def safe_serialize(obj) -> bytes:
        if not isinstance(obj, Serializable):
            raise TypeError(f"{type(obj).__name__} no es Serializable")
        return pickle.dumps(obj)


# Uso — el check sí discrimina
user = SerializableUser("Alice", "alice@example.com")
data = Serializer.safe_serialize(user)          # funciona
Serializer.safe_serialize(User("Bob", "b@x"))   # TypeError: User no es Serializable

Java

// Marker interfaces propias
interface Auditable {}
interface Immutable {}

class Transaction implements Auditable {
    private final String id;
    private final double amount;

    public Transaction(String id, double amount) {
        this.id = id; this.amount = amount;
    }

    public String getId() { return id; }
    public double getAmount() { return amount; }
}

class MutableConfig {
    private String value;
    public MutableConfig(String value) { this.value = value; }
    public String getValue() { return value; }
    public void setValue(String value) { this.value = value; }
}

class AuditFramework {
    public void logIfAuditable(Object obj) {
        if (obj instanceof Auditable) {
            System.out.println("AUDITORÍA: " + obj.getClass().getSimpleName() + " fue accedido");
        }
    }
}

class ValidationFramework {
    public void validateImmutable(Object obj) {
        if (obj instanceof Immutable) {
            System.out.println("VALIDADO: " + obj.getClass().getSimpleName() + " es inmutable");
        }
    }
}

// Uso — archivo: MarkerDemo.java
public class MarkerDemo {
    public static void main(String[] args) {
        Transaction tx = new Transaction("TX-001", 100.0);
        new AuditFramework().logIfAuditable(tx);                     // registra
        new AuditFramework().logIfAuditable(new MutableConfig("x")); // no registra
    }
}

JavaScript

JavaScript no tiene interfaces, pero los symbols y el duck typing logran resultados similares:

// Los Symbols actúan como claves únicas de marker
const Serializable = Symbol('Serializable');
const Cloneable = Symbol('Cloneable');

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  // Marca esta clase como Serializable
  static [Serializable] = true;
  static [Cloneable] = true;
}

class SecretData {
  constructor(data) {
    this.data = data;
  }
  // No marcada como Serializable
}

class Serializer {
  static safeSerialize(obj) {
    const constructor = obj.constructor;
    if (constructor[Serializable]) {
      return JSON.stringify(obj);
    }
    throw new TypeError(`El objeto de tipo ${constructor.name} no es Serializable`);
  }

  static safeClone(obj) {
    const constructor = obj.constructor;
    if (constructor[Cloneable]) {
      return JSON.parse(JSON.stringify(obj));
    }
    throw new TypeError(`El objeto de tipo ${constructor.name} no es Cloneable`);
  }
}

// Uso
const user = new User('Alice', 'alice@example.com');
const json = Serializer.safeSerialize(user);        // funciona
Serializer.safeSerialize(new SecretData('secret')); // TypeError

Explicación

El Patrón Marker Interface es engañosamente simple:

1. Define una interfaz vacía sin métodos.
2. Las clases optan implementándola — esa es la declaración.
3. Los frameworks verifican vía instanceof (Java), isinstance (Python) o checks de symbol (JS).
4. El comportamiento se ramifica según la presencia del marker.

La ventaja clave sobre las anotaciones es la verificación de tipos en tiempo de compilación. Si una firma requiere Serializable, el compilador lo exige — sin escaneo en runtime. El contraejemplo famoso es Cloneable de Java: el marker dice “clonable” pero el método clone vive en Object, no en la interfaz, así que el contrato queda roto de una forma que confunde a los desarrolladores desde 1997.

Marker Interface vs Anotaciones

Criterio	Marker interface	Anotación
Verificado en	Compilación + runtime	Solo runtime (vía reflexión)
Usable en firmas	Sí — void send(Serializable s)	No — los parámetros aceptan Object
Lleva parámetros	No	Sí — @Retryable(3)
Detectable vía instanceof	Sí	Requiere getAnnotations() + isAnnotationPresent
Herencia del marker	Heredado (no se puede quitar)	Opt-in por declaración
Dirección de Java	Deprecated en favor de	@FunctionalInterface, anotaciones de Jackson/validación

La regla general: usa un marker cuando la etiqueta debe aparecer en firmas de tipos o checks de instanceof; usa una anotación cuando la etiqueta lleva datos o es metadato opcional.

Variantes

Variante	Mecanismo	Lenguaje
Interface	Checks de instanceof	Java, C#
Clase base	isinstance con ABC vacía	Python
Symbol	Propiedades estáticas de symbol	JavaScript
Annotation	@Marker con reflexión	Java (alternativa moderna)
Trait bound	Trait vacío	Rust

Lo que funciona

• Úsalo con moderación. Demasiados marker interfaces contaminan la jerarquía de tipos — si un codebase tiene 20 interfaces vacías, los markers dejaron de aportar señal.
• Documenta el contrato. Aun las interfaces vacías deberían decir qué prometen los implementadores (Serializable no dice nada — de ahí la confusión).
• Prefiere anotaciones para metadatos con parámetros. @Retryable(maxAttempts=3) supera a una interfaz Retryable.
• Combínalo con el patrón visitor. Los markers ayudan a los visitors a decidir qué método visit invocar.
• Mantén los markers vacíos. En el momento en que un marker gana un método, deja de ser un marker — usa una interfaz normal.

Errores comunes

• Tratar los markers como comportamiento. Cloneable no hace los objetos clonables; lo hace Object.clone(). El marker solo señala intención — un malentendido fácil que los libros de Java repiten.
• Heredar el marker por accidente. class Admin extends SerializableUser hereda Serializable quieras o no — los markers no se pueden “des-implementar” en un subtipo.
• Olvidar el check del framework. Un marker que nadie prueba es código muerto: el opt-in no tiene efecto sin un consumidor de instanceof/isinstance.
• Aplicación inconsistente. Algunas subclases marcadas, otras no — los llamadores no pueden predecir qué objetos pasan el check.
• Protocol vacío en Python. El subtipado estructural hace que cero miembros coincidan con todo; usa una ABC vacía o un método marker en su lugar.

Ejemplos del mundo real

Java Serializable

java.io.Serializable es el marker clásico. ObjectOutputStream.writeObject() verifica instanceof Serializable y lanza NotSerializableException si está ausente. El check ocurre en el propio JDK — el marker es la puerta.

Java Cloneable

java.lang.Cloneable marca clases que admiten Object.clone(). Sin él, clone() lanza CloneNotSupportedException. Es el ejemplo de manual de un mal marker: el contrato se reparte entre marker + método protected + protocolo super.clone(), y Joshua Bloch dedica un ítem completo de Effective Java a explicar por qué está roto.

Anotaciones mix-in de Jackson

En el Java moderno, el rol de marker pasó en su mayoría a las anotaciones — @JsonSerializable, @Entity — porque pueden llevar configuración. El patrón sobrevive donde el tipo en sí debe discriminar, no solo anotar.

Solución de problemas

• isinstance/instanceof pasa para cualquier objeto: en Python, probablemente usaste un Protocol vacío — los protocolos vacíos coinciden con todo estructuralmente. Cambia a una clase base ABC vacía.
• El check del framework nunca se dispara: la clase no implementa el marker, o el marker vive en otra ruta de importación (ej. un Serializable propio que sombrea java.io.Serializable). Verifica obj instanceof Marker en un debugger o registra las interfaces del objeto.
• Una subclase pasa el check inesperadamente: los markers se heredan. class Special extends Marked conserva el marker; reestructura la jerarquía o verifica la clase exacta en lugar de instanceof.
• “Agregué el marker pero no pasa nada”: los markers no añaden comportamiento — señalan. Verifica que el framework consumidor realmente los lee, y que el paso de registro/wiring se ejecutó.

Notas de producción

• La deserialización de bytes no confiables con pickle/ObjectInputStream es una superficie de ataque clásica — el marker controla si serializas, no si es seguro. Mantén ambos lados del check explícitos.
• Los checks de instanceof son prácticamente gratis; escanear anotaciones por reflexión no lo es. Esa es la razón de rendimiento real para usar markers en rutas calientes.
• Un marker que solo implementa una clase suele ser ruido — espera al segundo consumidor antes de extraerlo.
• Revisa los markers en cada API pública: se filtran a las firmas y duele quitarlos cuando código externo ya los implementa.

Puntos clave

• Los marker interfaces etiquetan clases sin añadir métodos; los frameworks leen la etiqueta vía instanceof/isinstance.
• La firma en tiempo de compilación es lo único que un marker te da que una anotación no — usa eso como prueba decisiva.
• La historia de Java es la moraleja: Serializable funciona, Cloneable está roto, y el código moderno usa anotaciones.
• Mantén el número bajo y el contrato documentado; si no, tienes contaminación de interfaces en lugar de metadatos.

Lectura adicional

• Joshua Bloch, Effective Java, Ítem 13 — la crítica canónica de Cloneable y los contratos de markers.
• Oracle Java Docs — java.io.Serializable — documentación oficial del marker.
• Marker Interface Pattern — Wikipedia — visión general e historia del “tag interface” de GoF.
• Patrón Pipes and Filters — alternativa cuando el objetivo es enrutar pipelines, no etiquetar tipos.
• Demos ejecutables en el repositorio companion — implementaciones en Python, Java y JavaScript que puedes ejecutar.