La herencia en la Programación Orientada a Objetos es un mecanismo que permite que una clase derive atributos y comportamientos de otra, estableciendo una relación jerárquica del tipo “es un”, lo que favorece la reutilización de código y la representación estructurada del dominio del problema .

El polimorfismo es la capacidad de que distintos objetos respondan de manera diferente ante una misma operación, siempre que compartan una interfaz o clase base, lo que permite tratar objetos diversos como si fueran del mismo tipo y facilita la extensibilidad del sistema sin modificar código existente .

Ambos principios forman parte de los pilares fundamentales de la POO y se definen desde la etapa de análisis y modelado, antes de la implementación, contribuyendo a evitar duplicaciones y a estructurar correctamente las jerarquías del sistema . No obstante, desde una perspectiva de ciberseguridad, su aplicación debe ser cuidadosamente diseñada, ya que una jerarquía mal definida puede provocar que se hereden comportamientos o privilegios indebidos, generando vulnerabilidades como fallos en los mecanismos de autorización.

5.1 REUTILIZACIÓN DE CÓDIGO MEDIANTE HERENCIA

La herencia debe utilizarse únicamente cuando exista una relación clara y coherente dentro del dominio del problema, especialmente cuando varias entidades comparten características generales, pero requieren comportamientos específicos según su función en el sistema . En un sistema de control de accesos, por ejemplo, una superclase como Usuario puede dar origen a especializaciones como UsuarioAdministrador, UsuarioDocente y UsuarioEstudiante, las cuales comparten atributos comunes (nombre o identificador), pero no necesariamente los mismos privilegios.

Desde la perspectiva de la ciberseguridad, una aplicación inadecuada de la herencia puede propagar comportamientos sensibles a clases que no deberían poseerlos, ampliando la superficie de ataque del sistema. Por ello, se recomienda restringir la herencia a atributos y comportamientos generales, delegando la lógica crítica, como la autorización, a componentes especializados, evitando así que todas las subclases hereden funcionalidades sensibles que no les corresponden .

Principio de diseño seguro aplicado

La herencia debe utilizarse solo para reutilizar características comunes, no para centralizar decisiones de seguridad. Las decisiones críticas deben delegarse a clases específicas (por ejemplo, Rol o Permiso).

La herencia mal aplicada puede ampliar la superficie de ataque del sistema al propagar comportamientos sensibles a clases que no deberían poseerlos.

La Figura 1 muestra la clase Usuario como superclase y varias subclases (Administrador, Docente, Estudiante), destacando atributos comunes heredados y responsabilidadesdiferenciadas.

Ejemplo de implementación en Java del principio de Herencia al problema de control de accesos:

//Clase Permiso

class Permiso {

private String nombre;

private boolean autorizado;

public Permiso(String nombre, boolean autorizado) {

this.nombre = nombre;

this.autorizado = autorizado;

}

public boolean estaAutorizado() {

return autorizado;

}

}

//Clase Rol

class Rol {

//Atributos de la clase

private String nombre;

private Permiso permiso;

//Método constructor de la clase Rol

public Rol(String nombre, Permiso permiso) {

this.nombre = nombre;

this.permiso = permiso;

}

//Responsabilidad (método) de la clase Rol

public Permiso obtenerPermiso() {

return permiso;

}

}

//Usuario es la clase base

class Usuario {

protected String nombre;

protected boolean activo;

protected Rol rol;

//Constructor de la clase Usuario

public Usuario(String nombre, Rol rol) {

this.nombre = nombre;

this.rol = rol;

this.activo = true;

}

//Responsabilidades de la clase Usuario

public boolean estaActivo() {

return activo;

}

public Rol obtenerRol() {

return rol;

}

public String obtenerNombre() {

return nombre;

}

public void desactivar() {

activo = false;

}

}

Se crea una especialización (Herencia), la clase UsuarioAdministrador hereda de Usuario.

//Clase UsuarioAdministrador hereda de la clase Usuario

class UsuarioAdministrador extends Usuario {

//Constructor de la clase UsuarioAdministrador

public UsuarioAdministrador(String nombre, Rol rol) {

//Super es el método constructor de la clase base

super(nombre, rol);

}

}

Análisis:

• UsuarioAdministrador hereda:
• nombre
• estado activo
• rol
• No se reescribe lógica existente
• Se reutiliza código probado y seguro

Un administrador es un usuario, pero con una especialización semántica.

5.2 POLIMORFISMO COMO MECANISMO DE EXTENSIBILIDAD

El polimorfismo permite que distintas clases respondan de manera diferente a una misma operación, siempre que compartan una interfaz común o una superclase. En análisis orientado a objetos, el polimorfismo se define a nivel conceptual, no como detalle técnico. Conceptualmente, este principio favorece el desacoplamiento y la extensibilidad del sistema, ya que evita dependencias rígidas entre componentes .

En lugar de preguntar “qué clase es”, el sistema pregunta “qué comportamiento ofrece”. Esto resulta especialmente valioso en sistemas seguros, ya que evita condicionar la lógica del sistema a tipos concretos.

Ejemplo:

• Todos los roles deben responder a la acción: ¿tiene permiso para acceder a un recurso?

Sin embargo:

• Un rol Administrador evaluará permisos distintos a un rol Usuario.
• Un rol Invitado tendrá restricciones más severas.

El sistema no necesita conocer el tipo exacto del rol, solo necesita saber que puede evaluar permisos.

El polimorfismo reduce dependencias directas entre componentes, lo que mejora la mantenibilidad y limita errores de seguridad derivados de validaciones rígidas.

La Figura 2 muestra distintos tipos de Rol y responden al mismo mensaje verificarAcceso(), pero con comportamientos distintos.

Ejemplo de implementación de polimorfismo en Java:

Se agrega un método común en Usuario

class Usuario {

// (atributos y constructor omitidos por brevedad)

public boolean puedeAcceder() {

return activo && rol.obtenerPermiso().estaAutorizado();

}

}

Se especializa el comportamiento en la subclase:

class UsuarioAdministrador extends Usuario {

public UsuarioAdministrador(String nombre, Rol rol) {

super(nombre, rol);

}

@Override

public boolean puedeAcceder() {

// Administradores siempre activos pueden acceder

return activo;

}

}

Uso polimórfico:

Usuario usuario1 = new Usuario("Ana", rol);

Usuario usuario2 = new UsuarioAdministrador("Carlos", rol);

System.out.println(usuario1.puedeAcceder());

System.out.println(usuario2.puedeAcceder());

Análisis:

• El sistema invoca el mismo método
• El comportamiento cambia según el tipo real del objeto
• No se usan if por tipo

Beneficio: extensibilidad sin modificar código existente.

Relación con la ciberseguridad

Oviedo Regino (2015) menciona que la herencia y el polimorfismo, cuando se definen correctamente en la fase de análisis, permiten:

• Evitar duplicación de lógica de control
• Reducir errores de autorización
• Facilitar auditorías de seguridad
• Preparar el sistema para el uso de interfaces y desacoplamiento, fundamentales para sistemas robustos

Una jerarquía mal diseñada, en cambio, puede provocar:

• Privilegios heredados incorrectamente
• Clases con responsabilidades excesivas
• Aumento del acoplamiento y del riesgo de fallos

Herencia y polimorfismo aplicados al dominio de seguridad

Luego de comprender la herencia y el polimorfismo a nivel conceptual, es fundamental analizar su aplicación en un sistema de control de accesos, donde la seguridad depende de una adecuada distribución de responsabilidades entre clases como Usuario, Rol, Permiso y Recurso . El propósito del análisis orientado a objetos no es definir código definitivo, sino establecer una estructura conceptual segura que permita posteriormente una implementación sin comprometer la integridad del sistema.

Desde una perspectiva de diseño seguro, no todas las clases deben organizarse mediante herencia, ya que forzar relaciones de especialización cuando en realidad existe colaboración incrementa el acoplamiento y puede generar errores de autorización . En este modelo, Usuario mantiene su identidad y estado, Rol agrupa y decide permisos, Permiso define acciones autorizadas específicas y Recurso representa el elemento protegido. Dado que entre estas clases no existe una relación clara de tipo “es un”, no deben heredar entre sí, sino relacionarse de manera controlada para preservar la seguridad del sistema .

En sistemas seguros, la herencia debe usarse con moderación y solo cuando la relación semántica sea clara; de lo contrario, se introducen riesgos innecesarios.

En la Figura 3 un Usuario se asocia con Rol, Rol con Permiso y Permiso con Recurso, sin relaciones de herencia entre ellas.

Uso del polimorfismo en la autorización

El polimorfismo resulta especialmente útil cuando el sistema necesita evaluar accesos sin depender de implementaciones concretas. En lugar de preguntar qué tipo de rol es, el sistema pregunta si el rol permite una acción.

Ejemplo:

Todos los roles deben responder a la operación: ¿Este rol permite acceder a este recurso?

Sin embargo, cada rol puede aplicar reglas distintas:

• Un rol administrativo concede acceso amplio.
• Un rol operativo concede acceso limitado.
• Un rol invitado aplica restricciones estrictas.

Este enfoque evita condicionar la lógica del sistema a tipos específicos y reduce la probabilidad de errores de autorización, contribuyendo a un diseño más seguro y extensible .

La Figura 4, muestra como distintos tipos de Rol responden al mismo mensaje de verificación de acceso, cada uno con su propia lógica.

Para reformar los conocimientos de los temas tratados, ingresa al siguiente video:

DISEÑO DEL MODELO ORIENTADO A OBJETOS

El diseño del modelo orientado a objetos transforma el análisis conceptual del sistema en una estructura técnica organizada que servirá como base para su implementación, actuando como puente entre el estudio del dominio y la construcción del software. En esta etapa se definen la estructura interna de las clases, sus interfaces y contratos, así como las relaciones entre ellas y los mecanismos de encapsulación y control de acceso, distribuyendo responsabilidades de forma coherente según principios de diseño como el de responsabilidad única .

Desde la perspectiva de la ciberseguridad, el diseño busca prevenir riesgos desde la arquitectura, evitando clases con responsabilidades excesivas, protegiendo el estado interno de los objetos y restringiendo el acceso a operaciones críticas, lo que contribuye a mejorar la mantenibilidad, extensibilidad y seguridad del sistema antes de la fase de codificación .

En el diseño orientado a objetos, las interfaces permiten definir contratos de comportamiento entre componentes, estableciendo qué servicios se ofrecen sin detallar cómo se implementan. A diferencia de las clases, no representan entidades del dominio, sino capacidades que pueden ser implementadas por distintas clases. Esta separación entre funcionalidad e implementación favorece un diseño más mantenible y reduce riesgos estructurales .

En sistemas de control de accesos, las interfaces resultan esenciales para delimitar operaciones críticas como la verificación de permisos o la autorización de acciones, evitando que esta lógica sensible quede dispersa. Desde la ciberseguridad, su uso restringe el acceso a la funcionalidad interna, disminuye la dependencia entre componentes, facilita la auditoría y reduce la superficie de ataque al exponer únicamente operaciones controladas, previniendo accesos indebidos a la lógica de autorización .

Las interfaces actúan como una barrera conceptual que protege la lógica interna del sistema y refuerza el principio de encapsulación.

6.1 CONTRATOS DE COMPORTAMIENTO

En la POO, un contrato es un acuerdo formal que define los servicios que un componente ofrece sin especificar su implementación interna, basándose en el principio de abstracción para centrarse en el comportamiento esperado y no en los detalles técnicos . Desde el análisis orientado a objetos, los contratos se establecen a partir de las responsabilidades del dominio, determinando primero qué debe hacer una entidad y en qué condiciones, antes de decidir cómo se implementará.

Desde la perspectiva de la ciberseguridad, los contratos delimitan explícitamente las capacidades de los componentes, reduciendo la superficie de ataque y aplicando el principio de menor privilegio al restringir operaciones y proteger la lógica interna . Además, favorecen la interoperabilidad y el bajo acoplamiento, permitiendo diseños más robustos y evolutivos . En sistemas de control de accesos, por ejemplo, un contrato puede definir la verificación de acceso a un recurso sin exponer las reglas internas, permitiendo distintas implementaciones sin afectar la estabilidad del sistema .

El sistema confía en el contrato, no en la implementación.

La Figura 5 muestra una interfaz que define la operación de verificación de acceso, implementada por diferentes tipos de rol.

Ejemplo de implementación en Java:

Interfaz aplicada al permiso

interface Autorizable {

boolean estaAutorizado();

}

Ahora Permiso cumple el contrato:

class Permiso implements Autorizable {

private String nombre;

private boolean autorizado;

public Permiso(String nombre, boolean autorizado) {

this.nombre = nombre;

this.autorizado = autorizado;

}

@Override

public boolean estaAutorizado() {

return autorizado;

}

}

Diferencia entre contrato y contrato de comportamiento

6.2 DESACOPLAMIENTO MEDIANTE INTERFACES

El desacoplamiento consiste en reducir la dependencia directa entre componentes del sistema. Cuando una clase depende de una interfaz y no de una implementación concreta, el sistema se vuelve más flexible y seguro.

Beneficios del desacoplamiento en ciberseguridad

• Permite reemplazar implementaciones sin afectar al sistema
• Reduce el impacto de errores o fallos de seguridad
• Facilita pruebas y validaciones
• Mejora la trazabilidad de responsabilidades

En un sistema de control de accesos, esto significa que el mecanismo de autorización puede evolucionar (por ejemplo, incorporar nuevas reglas o políticas) sin modificar las clases que consumen ese servicio .

El desacoplamiento mediante interfaces reduce el riesgo de errores sistémicos al limitar el alcance de los cambios.

En la Figura 6, se muestra una clase Usuario interactúa con un contrato de autorización sin conocer la implementación concreta del rol o permiso.

Ejemplo de implementación del desacoplamiento en Java

Uso desacoplado del permiso

Se modifica Rol para depender de la interfaz:

class Rol {

private String nombre;

private Autorizable permiso;

public Rol(String nombre, Autorizable permiso) {

this.nombre = nombre;

this.permiso = permiso;

}

public Autorizable obtenerPermiso() {

return permiso;

}

}

El flujo de acceso no cambia:

if (usuario.estaActivo() && usuario.obtenerRol().obtenerPermiso().estaAutorizado()) {

System.out.println("Acceso permitido");

}

Análisis:

• Rol no depende de una clase concreta
• Puede cambiar la implementación del permiso
• Se reduce el acoplamiento
• Se mejora la mantenibilidad y seguridad

Programar contra interfaces, no contra implementaciones.

Relación con Usuario, Rol, Permiso y Recurso

En el modelo:

• Usuario: No decide permisos ni accede directamente a recursos protegidos.
• Rol: Implementa el contrato de autorización.
• Permiso: Define acciones permitidas de forma específica.
• Recurso: Representa el elemento protegido.

Las interfaces permiten que estas clases colaboren sin acoplarse, reforzando los principios de responsabilidad única, encapsulación y acceso controlado .

La figura 7 muestra el diseño orientado a objetos desacoplado, donde cada clase tiene una responsabilidad clara y el control de acceso se gestiona de forma estructurada y segura.

Para reforzar los conocimientos sobre los temas de interfaces, contratos y desacoplamiento, revisa el siguiente video: