oop - segregation - solid principles java
¿Hay alguna regla para OOP? (6)
Recientemente escuché que hay 9 reglas para OOP (Java). Solo conozco cuatro como Abstracción, Polimorfismo, Herencia y Encapsulación. ¿Hay más reglas para OOP?
Estos son conceptos, no reglas. No hay reglas realmente, solo decisiones que tomar, algunos diseños son mejores que otros, algunos mucho mejores que otros :-)
Aunque hay muchas pautas :-) Algunas son específicas del lenguaje (C ++ está plagado de ellas) otras son específicas de OO. Demasiados para hacer una lista :-)
Fuera de mi cabeza, los más importantes son:
- Acoplamiento flojo, alta cohesión
- Escribir clases comprobables, que usted prueba
- Use la herencia con moderación y solo donde tenga sentido (prefiera la composición)
- Intente apegarse al principio de abrir / cerrar.
- (lo más importante) KISS
Mucho para expandir y agregar :-)
EDITAR: Debería añadir, las reglas que enumeró no son exclusivas de OO
No estoy seguro de las reglas. Todas estas cosas mencionadas son más como paradigmas OO para mí. Hay algunos consejos que seguimos como,
- Separación de la preocupación
- Responsabilidad individual por clase
- Prefiere la composición sobre la herencia
- Programación a la interfaz
- Además de todos los mencionados por Billybob, ya
No hay "Reglas" para OOP.
Hay 4 propiedades de idioma que hacen que un lenguaje esté orientado a objetos o no (estas son las cosas que enumeró en su pregunta).
El resto del material que hay son pautas. Las mejores / más útiles pautas que he leído son GRASP
Muchas de las sugerencias no son fácilmente comprensibles para laicos (no especialistas en CS). Pensé que GRASP era pragmático y accesible.
Creo que GRASP es bueno porque sugiere la parte más crítica de OO en su nombre: Asignación de Responsabilidad (a objetos no programadores).
Los dos conceptos GRASP más importantes de los que deriva todo lo demás son el acoplamiento y la cohesión. Estos dos conceptos / principios impulsan todos los otros patrones y enfoques.
Por cierto, ¿acabo de entrevistarlo? Transcribiste la pregunta incorrectamente ...
Según los programadores pragmáticos, las reglas son:
- Manténgalo SECO (No se repita)
- Mantenlo TENIDO (Asegúrate de que tus clases tengan alta cohesión y bajo acoplamiento)
- y decirle al otro TIPO (Separación de preocupaciones)
Estos principios de OO son directamente de los patrones de diseño de Head First :
- Encapsular lo que varía
- Programa a una interfaz, en lugar de una implementación
- Favorecer la composición sobre la herencia
- Una Clase debe tener solo una razón para Cambiar ( Principio de Responsabilidad Individual )
- Los subtipos deben ser sustituibles por su base ( Principio de sustitución Liskov )
- Las clases deben estar abiertas para la extensión, pero están cerradas para la modificación ( principio abierto-cerrado )
Parece que lo que estás buscando son los Principios de Diseño Orientado a Objetos .
Resumido de principios, patrones y prácticas de desarrollo de software ágil . Estos principios son el producto ganado con esfuerzo de décadas de experiencia en ingeniería de software. No son el producto de una sola mente, pero representan la integración y las escrituras de un gran número de desarrolladores de software e investigadores. Aunque se presentan aquí como principios de diseño orientado a objetos, en realidad son casos especiales de principios de larga data de ingeniería de software.
SRP El Principio de Responsabilidad Individual Una clase debe tener solo una razón para cambiar.
OCP Las entidades de software de principio abierto (clases, paquetes, métodos, etc.) deben estar abiertas para la extensión, pero se deben cerrar para su modificación.
LSP Los Subtipos de Principio de Substancia Liskov deben ser sustituibles por sus tipos base.
DIP El Principio de Inversión de Dependencia Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.
ISP El principio de segregación de la interfaz Los clientes no deben ser forzados a depender de métodos que no usan. Las interfaces pertenecen a clientes, no a jerarquías.
REP El principio de Equivalencia de Liberación-Reutilización El gránulo de reutilización es el gránulo de liberación.
CCP El Principio de Cierre Común Las clases en un paquete deben cerrarse juntas contra los mismos tipos de cambios. Un cambio que afecta a un paquete cerrado afecta a todas las clases en ese paquete y no a otros paquetes.
CRP El Principio de Reutilización Común Las clases en un paquete se reutilizan juntas. Si reutilizas una de las clases en un paquete, las reutilizas todas.
ADP El principio de dependencias acíclicas No permite ciclos en el gráfico de dependencia.
SDP El principio de dependencia estable depende de la estabilidad.
Principio de abstracciones estables de SAP Un paquete debe ser tan abstracto como estable.