¿Cuáles son las reglas importantes en el diseño del modelo de objetos

Question

Estamos desarrollando una extensión (en C env # .NET.) Para una aplicación SIG, que se ha predefinido tipos para el modelado de los objetos del mundo real, empezar desde GenericObject, y va a tipos más específicos como Pipe y Road con sus propiedades y métodos detallados como BottomOfPipe, Diameter y más.

Seguramente, habrá un modelo de objetos , interfaz s, Herencia y un montón de otras partes esenciales en la TypeLibrary, y por ahora nos fija algunos de ellos. Pero como sabrá, diseñar un Modelo de Objetos es un trabajo muy ambiguo, y (por lo que yo sé), se puede hacer de muchas maneras diferentes y con muchos resultados y debilidades diferentes.

¿Hay reglas distintas en el diseño de O.M.: la Jerarquía , la forma de definir la interfaz s, abstracta y coclasse s enumeración s?

¿Alguna sugerencia, referencia o práctica?

Answer 1

Un par de buenos:

SÓLIDO

S ingle principio de responsabilidad
O pluma/cerrado principio
L principio de sustitución iskoff principio de la segregación
I Nterface
D ependency principio de inversión de

Más información y más principios aquí: http://mmiika.wordpress.com/oo-design-principles/

Answer 2

Consulte los "principios" del diseño orientado a objetos. Estos tienen pautas para todas las preguntas que hace.

Referencias:

• "orientado a objetos de construcción de software" de Robert Martin
• http://www.objectmentor.com/resources/publishedArticles.html

de partida de los artículos "principios de diseño" en el sitio anterior. Son las mejores referencias disponibles.

Answer 3

"BottomOfPipe"? ¿Es esa otra forma de decir la profundidad de la tubería debajo de la carretera?

Cualquier tipo de diseño es difícil y se puede hacer de diferentes maneras. No hay garantías de que su diseño funcione cuando lo cree.

La ventaja que tienen las personas que diseñan rodamientos de bolas es que muchos años más de experiencia y datos determinan qué funciona y qué no. El software no tiene tanto tiempo ni datos duros.

He aquí algunos consejos:

1. Herencia significa IS-A. Si eso no se cumple, no use la herencia.
2. Una jerarquía profunda es probablemente una señal de problemas.
3. De Scott Meyers: Crea interfaces de clases no hoja o resumen.
4. Prefiere la composición a la herencia.

Answer 4

Echa un vistazo Domain-Driven Design: Tackling Complexity in the Heart of Software. Creo que responderá tus preguntas.

Answer 5

lo que dijeron, además de que parece que se está modelando entidades del mundo real, por lo que:

• restringir su modelo de objetos para coincidir exactamente con las entidades del mundo real.

Puede usar la herencia y los componentes para reducir el código/modelo, pero solo de manera que tenga sentido con el dominio subyacente.

Por ejemplo, una clase Pipe con una propiedad Diameter tendría sentido, mientras que una clase DiameterizedObject (con una propiedad Diameter) con una propiedad GeometryType de GeometryType.Pipe no lo haría. Ambos modelos se pueden hacer funcionar, pero el primero corresponde claramente al dominio del problema, mientras que el segundo implementa una perspectiva artificial (no del mundo real).

Una pista adicional: sabes que tienes el modelo correcto cuando descubres nuevas características en el código que no planeaste desde el principio: simplemente 'naturalmente' se salen del modelo. Por ejemplo, su modelo puede tener tuberías y uniones (como adaptadores de conectividad) suficientes para resolver el problema inmediato de (por ejemplo) unir tuberías de diferentes diámetros entre sí y calcular caudales, presiones máximas e integridad estructural. Posteriormente se da cuenta de que, dado que modeló las propiedades estructurales y de conectividad de las Tuberías y Conexiones exactamente (dentro de los requisitos del dominio) también puede crear un objeto JungleGym a partir de tuberías conectadas y calcular correctamente la carga estructural que soportará.

Este es un ejemplo extremo, pero debe aclarar el punto: los modelos de objetos correctos admiten la extensión y a menudo manifiestan propiedades y características inesperadas beneficiosas (¡no errores!).

Answer 6

El Liskov Substitution Principle, a menudo expresado en términos de "is-a". Muchos ejemplos de programación orientada a objetos estarían mejor haciendo uso de "has-a" (en C++ herencia privada o composición explícita) en lugar de la herencia pública ("is-a")

Conseguir derecho de herencia es dura. Hacerlo con interfaces (clases virtuales puras) a menudo es más fácil que para clases base/sub