Command Palette

Search for a command to run...

ES·EN

Nivel 2 · 25 min

SOLID Aplicado a OOP

SOLID no es solo teoría — guía decisiones de diseño de clases concretas. En este módulo aplicamos cada principio al diseño orientado a objetos: cómo SRP, OCP, LSP, ISP y DIP se traducen en decisiones sobre jerarquías de clases, interfaces y dependencias.

SRP y OCP en el diseño de clases

SRP en OOP: una clase tiene una única responsabilidad cuando podés describir su propósito con una sola frase sin ''y''. CustomerOrderProcessor viola SRP — hace cosas de Customer y cosas de Order. La refactorización es separar en CustomerService y OrderProcessor. OCP se aplica via herencia o composición — las subclases extienden sin modificar; los decorators agregan sin modificar; los nuevos implementadores de interfaces agregan sin modificar al cliente.

LSP en jerarquías de clases

LSP se viola cuando sobreescribís un método para lanzar NotImplementedException, cuando estrechás precondiciones (el padre acepta null, el hijo no), o cuando aflojas postcondiciones (el padre garantiza que el resultado es '>' 0, el hijo puede devolver 0). La prueba de LSP: agarrá el test suite de la superclase y ejecutalo con cada subclase — todos deben pasar. Si fallan tests, hay violación de LSP.

ISP y DIP en diseño de clases

ISP aplicado a OOP: preferí muchas interfaces específicas a una interfaz grande. Si la clase implementadora tiene métodos vacíos o que lanzan UnsupportedOperationException, la interfaz es demasiado grande. DIP en OOP: las clases concretas dependen de abstracciones (interfaces) no de otras clases concretas. El flujo es: módulo de alto nivel define interface → módulo de bajo nivel implementa → DI container conecta.

Puntos clave

  • El test de LSP: el test suite de la superclase, ejecutado sobre la subclase, debe pasar completamente.
  • ISP se viola cuando ves throws UnsupportedOperationException o métodos vacíos en una implementación — la interfaz sabe demasiado.
  • DIP + interfaces + DI container = el núcleo de Spring Framework. Los beans se configuran contra abstracciones, no implementaciones.

Code example

// LSP test: el test suite del padre debe pasar en el hijo
@Test void debits_reduce_balance(BankAccount account) {
  account.credit(new Money(100, USD));
  account.debit(new Money(30, USD));
  assertEquals(new Money(70, USD), account.getBalance());
}
// Si SavingsAccount falla este test -> viola LSP