Qué es el patrón Singleton y porqué se usa en el plugin CRR

Tiempo de lectura: 4 min

Valencia, 30/10/2026, G.B.
El patrón Singleton garantiza que una clase tenga una única instancia en toda la aplicación y ofrece un punto de acceso global a ella. A raíz de la preparación del cuaderno técnico del plugin Control y Reserva de Recursos (CRR), que publicaré en breve, cuento que, a diferencia de otros desarrollos anteriores como Agenda Indaga, en el CRR no utilizo una clase con patrón Singleton, sino un conjunto de funciones planas con el prefijo crr_ en un único archivo. Vamos a ver qué es este patrón y por qué decidí prescindir de él en este plugin.

Pero, ¿qué es eso del patrón Singleton?

El patrón Singleton (o patrón de instancia única) es un patrón de diseño de software pensado para que una clase tenga una sola instancia y para dar acceso global a ella.

Normalmente, en PHP puedes crear tantos objetos de una clase como quieras con la palabra clave new. El Singleton restringe esto con tres reglas clave:

1. Constructor privado (private function __construct): impide que cualquier código externo cree nuevos objetos con new MiClase().
2. Propiedad estática (private static $instance): almacena dentro de la propia clase la única instancia permitida.
3. Método de acceso público estático (public static function get_instance()): es el único punto de entrada. Si la instancia no existe, la crea; si ya existe, devuelve la que estaba guardada.

class Mi_Plugin_Singleton {
    private static $instance = null;

    // 1. Constructor privado para evitar instanciación externa
    private function __construct() {
        // Inicialización del plugin (ganchos, acciones, etc.)
    }

    // 2. Método global para obtener la única instancia
    public static function get_instance() {
        if ( self::$instance === null ) {
            self::$instance = new self();
        }
        return self::$instance;
    }
}

// Arranque del plugin
Mi_Plugin_Singleton::get_instance();

Por qué se usa habitualmente en WordPress

• Organización orientada a objetos: permite agrupar la lógica, las propiedades y los métodos del plugin en una estructura limpia y encapsulada
• Ayuda a evitar duplicidades: reduce el riesgo de que los ganchos de WordPress (add_action, add_filter) se registren más de una vez si la clase se carga en distintos puntos del ciclo de vida
• Punto de acceso único: cualquier parte del plugin puede obtener el mismo objeto con get_instance(), sin pasarlo de un sitio a otro

Por qué decidí no usarlo en el CRR

En el plugin Control y Reserva de Recursos (CRR) opté por un enfoque más directo: un conjunto de funciones con el prefijo único crr_ dentro de un único archivo. Así se ve el arranque en el código real del plugin:

function crr_instalar() {
    // Creación de las tablas con dbDelta, versión de la base de datos, etc.
}
register_activation_hook( __FILE__, 'crr_instalar' );

function crr_comprobar_actualizacion_db() {
    if ( get_option( 'crr_db_version' ) !== CRR_VERSION ) {
        crr_instalar();
    }
}
add_action( 'plugins_loaded', 'crr_comprobar_actualizacion_db' );

• Simplicidad y legibilidad: se trata de un sistema autocontenido, centrado en la gestión de recursos y reservas mediante formularios e inventario. Un único archivo de funciones se lee de arriba abajo, sin saltar entre clases, y es fácil de mantener
• Colisiones de nombres prácticamente eliminadas: al usar el prefijo crr_ en todas las funciones y constantes, el riesgo de choque con WordPress o con otros plugins activos es mínimo. No es una garantía absoluta, pero en la práctica basta

Los inconvenientes del Singleton

Conviene ser honestos: el Singleton tampoco está libre de críticas, y muchos desarrolladores lo consideran un antipatrón. Introduce estado global, dificulta las pruebas automatizadas y aumenta el acoplamiento entre componentes. Que sea habitual en WordPress no significa que sea siempre la mejor opción.

Cuándo sí y cuándo no

• Singleton (o clases en general): si el plugin crece, tiene estado compartido o se compone de varios componentes que deben colaborar
• Funciones planas con prefijo: si el plugin es pequeño, autocontenido y no necesita compartir estado entre piezas

Este post es, en sí, un apunte técnico; la primera parte del cuaderno técnico del CRR llegará en breve.

Singleton explicado en Refactoring Guru