Herencia y Composición en Programación Orientada a Objetos

Curso de Go Intermedio: Programación Orientada a Objetos y Concurrencia

Contenido del curso

Introducción

Programación orientada a objetos

Go Modules

Testing

Concurrencia

Proyecto: servidor con worker pools

Conclusión

30
Resumen del Curso Avanzado de Go: Módulos, Tests y Concurrencia
02:34 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0014:50

Herencia y Composición en Programación Orientada a Objetos

Curso de Go Intermedio: Programación Orientada a Objetos y Concurrencia

Clase 9 de 30

Clase 9 / 30

Recursos

Cuando diseñas software orientado a objetos, tarde o temprano aparece la pregunta: ¿debería usar herencia o composición? Este debate es uno de los más intensos en programación, y la forma en que cada lenguaje lo resuelve cambia por completo la arquitectura de tu código. A continuación se exploran ambos enfoques con ejemplos prácticos en TypeScript y Go, revelando ventajas, limitaciones y por qué el polimorfismo queda en el centro de la discusión.

¿Cómo funciona la herencia en TypeScript?

La herencia permite que una clase derivada reutilice propiedades y métodos de una clase base. En TypeScript se utiliza la palabra reservada extends para indicar que una clase hereda de otra [1:00].

La clase que comparte sus características se denomina clase base (por ejemplo, BaseEmployee).
Las clases que heredan se llaman clases derivadas (como TemporaryEmployee y FullTimeEmployee).
Las propiedades declaradas como privadas en la clase base quedan aisladas: ni siquiera las clases hijas acceden directamente a ellas [2:07].
Solo los métodos públicos de la clase base están disponibles para las clases derivadas.

Gracias a esto, no necesitas copiar y pegar código en cada clase especializada. Cada clase derivada puede agregar sus propias propiedades —como taxRate en FullTimeEmployee— sin afectar a sus clases hermanas [2:52].

¿Qué papel juega el polimorfismo con la herencia?

El polimorfismo permite tratar distintas clases derivadas como si fueran la clase base [3:08]. Puedes crear una función que reciba un BaseEmployee y llamar al método getMessage() sin importar si le pasas un FullTimeEmployee o un TemporaryEmployee.

Sin embargo, hay una señal de alerta: cuando cada clase hija sobrescribe (override) los mismos métodos de la clase base una y otra vez, tu herencia quizás no esté funcionando como esperabas [3:53]. Algunos lenguajes agregan etiquetas como override para hacer explícito que un método está siendo reemplazado.

La regla fundamental de la herencia es la relación "es un": un TemporaryEmployee es un BaseEmployee, así como un FullTimeEmployee es un BaseEmployee [4:30].

¿Por qué Go prefiere composición sobre herencia?

En Go, la herencia no existe como concepto del lenguaje. En su lugar se aplica un principio muy conocido: composición sobre herencia [4:45].

¿A qué se refiere? Imagina que un FullTimeEmployee deja de necesitar un ID. Si usaras herencia, tendrías que modificar la clase base y eso afectaría a todas las clases derivadas. Con composición, cada struct es independiente y maneja sus propias propiedades [5:09].

En lugar de decir que un empleado temporal es un empleado base, decimos que un empleado temporal tiene propiedades de una persona y propiedades de un empleado. Esa diferencia entre "es" y "tiene" es la esencia de la composición.

¿Cómo se implementa la composición con campos anónimos?

En Go, la composición se logra mediante campos anónimos (anonymous fields) dentro de un struct [6:55]:

go type Person struct { Name string Age int }

type Employee struct { ID int }

type FullTimeEmployee struct { Person Employee }

Al declarar Person y Employee sin asignarles un nombre de campo, accedes directamente a sus propiedades (Name, Age, ID) desde FullTimeEmployee [7:40]. Al imprimir la estructura, Go agrupa visualmente las propiedades según el struct al que pertenecen [8:35].

¿Qué ocurre con el polimorfismo sin herencia?

Aquí aparece el problema clave. Si creas una función getMessage que recibe un tipo Person, no puedes pasarle un FullTimeEmployee directamente [9:22]. Go marca un error porque, bajo composición, FullTimeEmployee no es una persona: simplemente tiene propiedades de persona.

En herencia, el polimorfismo funciona de forma natural porque la relación "es un" lo permite. En composición, esa relación no existe, así que el polimorfismo requiere otro mecanismo: las interfaces [10:15].

Este dilema entre "una clase es" versus "una clase tiene" define cuándo conviene cada enfoque. La composición ofrece mayor flexibilidad y menor acoplamiento, pero sacrifica el polimorfismo directo. Las interfaces en Go resuelven exactamente ese vacío, permitiendo definir comportamientos compartidos sin depender de jerarquías rígidas.

¿Prefieres herencia o composición en tus proyectos? Comparte tu experiencia y cuéntanos qué consideraciones aplicas antes de elegir una u otra.

Diego Alberto González González

Hace 5 años

Como puedo separar los structs en archivos separados y llamarlos en mi archivo main?

Nestor Escoto

Profesor

Hace 5 años

Hola Diego, por lo general puedes ir definiendo los structs en paquetes diferentes; por ejemplo: tienes toda la lógica que necesitas para manejar tus llamados de servidor en un archivo llamado servidor.go entonces puedes tener todos tus structs públicos por allí: type Server struct o type Router struct por decir algo; e importarlos desde tu main, pero para esto va a ser necesario que definas tu proyecto como un Go Module, vamos a llamarlo para este caso: mymodulo

package server

type Server struct {}

type Router struct {}

...
...
...

package main

import "mymodulo/server"

func main(){
	var s server.Server ...
	var r server.Router ...
}

Luis Enrique

Hace 5 años

Hola diego

mientras package tenga el mismo nombre, da igual si esta en diferentes archivos, por lo general debe tenerse en la misma carpeta

todo.go

package types

type Todo struct {
   nombre  string  `bson:"nombre" json:"nombre"`
}

otro.go

package types

type Otro struct {
   Otro string  `bson:"otro" json:"otro"`
}

siempre debe estar con mayúsculas para poder importarlos y en mi ejemplo se importaria asi

package types

type Todo struct {
   nombre  string  `bson:"nombre" json:"nombre"`
}

otro.go

package main

// importar antes package types
func main() {
	ejemplo := types.Otro{
		Otro: "Ejemplo"
	}
}

no soy bueno poniendo nombres -.-'

Comentarios (22)22 comentarios

Guillermo Pedro Cuneo

Luis Fernando Cortes Duque

Tan Zuñiga

Carlos Jose Rodriguez Peña

Hace 3 años

Hugo René Pereira Monzon

Julian Torres

Edwin García

Andres felipe Rojas parra

Alejandro Ibarra Rodriguez

José Fabián Beltrán Meza

Omar Lozano

Miguel Angel Reyes Moreno

Hace un año

Oscar Pinochet

Hace 4 años

Carlos Nassif Trejo Garcia

AGEO ANDRÉS FUENTES MERIÑO

Julián Camilo García Rincón

Axel Bau

Hace 2 años

William Rodriguez

Manuel G. Pineda

Victor Hugo Cruz Carballo

Eliaz Bobadilla

Introducción

Programación Orientada a Objetos y Concurrencia en Go

Concurrencia y Testing en Go: Go Routinas y Worker Pools

Fundamentos de Programación en Go: Structs, Apuntadores y Manejo de Errores

Go Routines, Canales y Apuntadores en Golang

Programación orientada a objetos

Programación Orientada a Objetos en Go: Análisis y Comparativa

Equivalente de Clases en Go: Uso de Structs y Propiedades

Métodos en Structs: Implementación de Receiver Functions en Go

Implementación de Constructores en Go: Ejemplos y Mejores Prácticas

Herencia y Composición en Programación Orientada a Objetos

Interfaces y Polimorfismo en TypeScript y Go

Patrón Abstract Factory: Interfaces y Polimorfismo en Go

Implementación del Patrón Factory en Go para Notificaciones

Funciones Anónimas en Go: Uso y Consideraciones Prácticas

Funciones Variádicas y Retornos con Nombre en Go

Go Modules

Manejo de Dependencias y Módulos en Go

Creación y Publicación de Módulos en GitHub con Go

Testing

Tests unitarios y code coverage en Go

Cobertura de Código y Testing en Go: Mejorando la Calidad del Software

Profiling de Código en Go para Optimización de Rendimiento

Testing Unitario en Go: Uso de Mock Services

Testeo Unitario de Funciones con MOOC en Go

Concurrencia

Canales con y sin buffer en Go: diferencias y uso práctico

Sincronización de Rutinas en Go con Wait Group

"Uso de Canales con Buffer como Semáforos en Go"

Manejo de Canales de Lectura y Escritura en Go

Concurrencia en Go: Creación de Worker Pools y Fibonacci

Multiplexación de Canales en Go con Select y Case

Proyecto: servidor con worker pools

Creación de un Web Server con Worker Pool en Go

Creación de un Servidor Web Concurrente con Go

Conclusión

Resumen del Curso Avanzado de Go: Módulos, Tests y Concurrencia

Herencia y Composición en Programación Orientada a Objetos