2008-12-30 9 views
19

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?¿Hay alguna regla para OOP?

Respuesta

39

Parece que lo que estás buscando es Principles of Object-Oriented Design.

Resumido de Agile Software Development Principles, Patterns, and Practices. 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 Principio de responsabilidad única Una clase solo debe tener un motivo para cambiar.

OCP El principio de abierto abierto Las entidades de software (clases, paquetes, métodos, etc.) deben estar abiertas para su extensión, pero se pueden cerrar para su modificación.

LSP The Liskov Substition Principle Los subtipos deben ser sustituibles por sus tipos de base.

DIP 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 Release-Reuse El gránulo de reutilización es el gránulo de liberación.

CCP El Cierre Común Principio Las clases de un paquete debe cerrarse juntos 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 The Acylcic Dependencies Principio No permite ciclos en el gráfico de dependencia.

SDP El principio de las dependencias estables Dependen de la estabilidad.

SAP The Stable Abstractions Principio Un paquete debe ser tan abstracto como estable.

4

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) otros son OO específicos. Demasiados a la lista aunque :-)

De la parte superior de la cabeza, las más importantes son:

  • acoplamiento flojo, alta cohesión
  • Escribir clases comprobables, que se prueba
  • Uso inheritence con moderación y solo cuando tenga sentido (prefiera la composición)
  • Pruebe atenerse al principio de apertura/cierre.
  • (lo más importante) de KISS

Un montón de ampliar y añadir :-)

EDIT: Debo añadir, las reglas que usted enumeró no son exclusivos de Oo

+0

Ni la tuya :). Por cierto, ¿cómo podemos practicar Herencia, Polimorfismo, etc. en un idioma que no sea OO? Creo que estos 4 son paradigmas OO. –

6

No está seguro acerca cualquier regla Todas estas cosas mencionadas son más como paradigmas OO para mí. Hay algunos consejos que seguimos similares,

  • Separación de preocupación
  • responsabilidad individual por Clase
  • Prefiero composición sobre la herencia
  • programación a la interfaz
  • Además de todas mencionado por Billybob, ya
5

Estos principios OO son directamente de Head First Design Patterns:

  • encapsular lo que varía
  • programa a una interfaz, en lugar de una implementación
  • favor composición sobre la herencia
  • Una clase debe tener una sola razón cambiar (Principio de Responsabilidad Individual)
  • Los subtipos deben ser sustituibles para ti r Base (Liskov Substitition Principio)
  • Clases shoule abierto a la extensión, pero cerrado para Modificación (abierto-cerrado Principio)
4

Según los programadores pragmáticos - las reglas son:

  • mantenerlo seco (no te repitas)
  • Mantenga SHY (Asegúrese de que las clases tienen una alta cohesión y bajo acoplamiento)
  • y decirle al otro tipo (separación de intereses)

http://media.pragprog.com/articles/may_04_oo1.pdf

3

No hay "reglas" de programación orientada a objetos.

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 es una guía. Las mejores/más útiles pautas que he leído son GRASP

Muchas de las sugerencias no son fáciles de entender por parte de personas ajenas a la CS. Pensé que GRASP era pragmático y accesible.

Creo que GRASP es agradable porque sugiere la parte más crítica de OO en su nombre: asignación de responsabilidad (a los objetos no a los 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.

BTW - ¿Acabo de entrevistarlo? Transcribiste la pregunta incorrectamente ...

Cuestiones relacionadas