Pregunta

Recientemente he oído que hay 9 reglas para la programación orientada a objetos (Java). Sé que sólo cuatro como la abstracción, polimorfismo, herencia y encapsulación. ¿Hay más reglas para la programación orientada a objetos?

¿Fue útil?

Solución

Parece que lo que estás buscando son los Principios de Diseño Orientado a Objetos .

Principios ágiles de desarrollo de software, patrones y prácticas . Estos principios son el producto duramente ganada de décadas de experiencia en la ingeniería de software. Ellos no son el producto de una sola mente, sino que representan la integración y escritos de un gran número de desarrolladores de software e investigadores. A pesar de que aquí se presentan como principios de diseño orientado a objetos, son casos muy especiales de los principios de larga data de la ingeniería de software.

SRP La Responsabilidad Individual Principio Una clase debe tener una sola razón para cambiar.

El OCP abierto-cerrado Principio entidades de software (clases, paquetes, métodos, etc.) deben estar abiertas para la extensión, pero cerrado para su modificación.

LSP El Liskov SUSTITUCIÓN Principio Subtipos deben ser sustituibles por sus tipos base.

moje la Dependencia Inversión Principio Las abstracciones no deben depender de los detalles. Los detalles deben depender upons abstracciones.

ISP La interfaz Segregación Principio Los clientes no únicamente deben ser forzados a depender de métodos que no utilizan. Interfaces pertenecen a los clientes, no a las jerarquías.

REP El Release-Reutilización de Equivalencia Principio El gránulo de la reutilización es el gránulo de liberación.

El CCP Común Cierre Principio Las clases de un paquete deben estar cerrados juntos contra los mismos tipos de cambios. Un cambio que afecta a un paquete cerrado afecta a todas las clases del paquete y no hay otros paquetes.

El CRP Común reutilización Principio Las clases de un paquete se vuelven a utilizar juntos. Si vuelve a utilizar una de las clases en un paquete, todos ellos volver a utilizar.

ADP La Acylcic Dependencias Principio Permitir no hay ciclos en el gráfico de la dependencia.

El SDP Estable Dependencias Principio Dependen en la dirección de la estabilidad.

El SAP Estable abstracciones Principio Un paquete debe ser tan abstracto como es estable.

Otros consejos

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

  • La separación de preocupación
  • La responsabilidad individual por la clase
  • Prefiero Composición sobre la herencia
  • Programación de la interfaz
  • Además de todas mencionado por Billybob, ya

Estos principios son OO directamente desde Head First Design Patrones :

  • 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 para el cambio ( Responsabilidad Individual Principio )
  • subtipos debe ser sustituibles por su base ( Liskov Substitition Principio )
  • Las clases shoule abierto a la extensión, pero cerrado para la modificación ( abierto-cerrado Principio )

Estos son conceptos, no reglas. No hay reglas en realidad, sólo decisiones que tomar, algunos diseños son mejores que otros, algunos mucho mejor que otros :-)

Hay un montón de directrices, aunque :-) Algunos son un lenguaje específico (C ++ está plagado de ellas) que otros son específicos OO. Demasiados a la lista aunque: -)

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

  • El acoplamiento flexible, alta cohesión
  • Escribir clases comprobables, que se prueba
  • Uso inheritence con moderación y sólo cuando tenga sentido (prefieren composición)
  • Intenta palo para el 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

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

  • mantenerlo seco (Do not Repeat Yourself)
  • Mantenga SHY (Asegúrese de que las clases tienen una alta cohesión y bajo acoplamiento)
  • y decirle a la otra persona (separación de intereses)

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

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

Hay 4 propiedades del lenguaje que hacen que un lenguaje orientado a objetos o no (estas son las cosas que mencionó en su pregunta).

El resto del material por ahí son directrices. Los mejores guías / más útiles que he leído son GRASP

Muchas de las sugerencias no son de fácil comprensión para los legos (no mayores CS). Pensé GRASP fue pragmático y accesible.

Creo GRASP es agradable, ya que sugiere la parte más crítica de OO en su nombre - Asignación de Responsabilidad (a objetos no programadores).

Los dos conceptos más críticos GRASP de la que todo deriva else son acoplamiento y cohesión. Estos dos conceptos / directores coche todos los demás modelos y enfoques.

Por cierto - ¿acabo de entrevistar? Usted transcribió la pregunta incorrectamente ...

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top