En la programación de bases de datos hay una técnica llamada "normalización" que usted hace a los datos que desea almacenar.

¿Alguien ha tratado de aplicar este concepto al diseño de objetos? ¿Cómo hizo? Como resulto?

Editar: para ampliar / aclarar, la normalización de la base de datos es más que un conjunto de principios para reducir la redundancia. En realidad, hay pasos y etapas por las que pasas y al menos medidas moderadamente objetivas que te indican en qué etapa te encuentras. El diseño de objetos tiene sus propios principios, y existe el concepto de olor, pero ¿hay alguna manera de hacer algo similar que te diga que estás en XX-form0,1,2 ... etc ... y métodos para pasar al siguiente nivel más "normalizado"?

Si bien algunas de las tensiones subyacentes que impulsan la normalización de la base de datos no están presentes en un sistema OO, algunas sí lo están. Estos han dado lugar a patrones y principios de diseño OO que de alguna manera son análogos a la normalización, al menos en la medida en que los sistemas OO son análogos a las bases de datos relacionales. Por ejemplo:

• Principio de responsabilidad única
• Separación de intereses
• Una vez y solo una vez , también conocido como DRY

En otras palabras, ¿alguien ha intentado aplicar técnicas de normalización de bases de datos a OOP? No, porque OOP ya tiene soluciones para los problemas compartidos que la normalización resuelve para las bases de datos relacionales.

Si, si tengo

Me he mantenido callado sobre este tema durante mucho tiempo; Es hora de hablar.

• ¿Alguien ha tratado de aplicar este concepto al diseño de objetos?

Sí. Llevo más de 20 años trabajando en la formalización de la normalización de objetos (y, por lo tanto, en la teoría subyacente orientada a objetos).

• ¿Cómo hizo?

Al darse cuenta de que los datos y el código son intercambiables, al menos en teoría. Esto significa que los principios de normalización y las operaciones relacionales pueden aplicarse tanto al código como a los datos.

• Como resulto?

Hasta ahora funcionó bastante bien: creo que las ideas obtenidas han sido las "armas secretas" de mis habilidades de diseño, análisis y refactorización.

No he dicho nada al respecto públicamente antes de esto porque pensé que eventualmente tendría tiempo para terminar la investigación, y producir las herramientas implícitas, yo mismo.

Pero he llegado a la conclusión de que con todo lo que sucede en mi vida que es más importante, más divertido y / o más rentable, no voy a tener tiempo para terminar la investigación yo mismo. Siempre. También existe la posibilidad significativa de que simplemente no tenga los fundamentos teóricos de CS necesarios para completar el trabajo solo.

He preguntado en la universidad local acerca de patrocinar a un candidato a doctorado o dos si desean abordar la causa, pero lamentablemente nuestra universidad local no enseña una base adecuada en la programación de la semántica del lenguaje.

Ha habido algunas investigaciones interesantes en esta área, pero todas, que yo sepa, no han alcanzado el objetivo. O supone incorrectamente que, debido a que la normalización proviene de un fondo relacional, no se aplica a los modelos orientados a objetos, o supone que la normalización solo se aplica a los datos definidos por los objetos. Sin embargo, hay algunos proyectos muy interesantes para fallar ...

Las cosas realmente interesantes suceden cuando aplicas la normalización al código, lo que diría que es la base de toda refactorización .

Así que ahora estoy pensando que lo mejor que se puede hacer es correr la voz, tal vez pidiendo hablar en DevDays 2011 en DC, y descubrir si hay una comunidad tan entusiasmada con estas cosas como yo.

Aquí hay un adelanto: la normalización es el proceso de hacer algo mínimo y no redundante. El principio Don't Repeat Yourself (DRY) de la programación orientada a objetos es, por lo tanto, una clara manifestación de los objetivos de la normalización. Creo que puedo demostrar que todos los conocidos principios de diseño / programación / refactorización orientados a objetos son la consecuencia lógica de la normalización de objetos. Creo que también puedo mostrar que hay cosas más interesantes que se pueden hacer con los sistemas en Forma Normal de Objetos (ONF) que la simple refactorización.

Esto comenzó como un comentario sobre la excelente respuesta de Rein Henrich , pero se hizo demasiado largo ...

La normalización se aplica a los datos relacionales. Se utiliza para evitar la duplicación, lo que facilita asegurar la integridad de los datos, ya que cada dato se almacena en un solo lugar. Normaliza una base de datos al encontrar violaciones de un formulario normalizado y corregirlas.

La programación orientada a objetos se aplica a las operaciones con datos. Está destinado a agrupar formas de manipular datos juntos. Puede aplicar técnicas similares a las clases para eliminar métodos duplicados, quizás observando de qué datos manipula o depende la operación. Por ejemplo, 1NF en una perspectiva OO no tendría ninguna operación duplicada dentro de una clase. 3NF podría corresponder con una buena estructura de herencia en la que el código de uso común está en una superclase. Estoy seguro de que también podría encontrar un lugar para la inyección de dependencia. Alcanza un mejor diseño (aunque aún no se han descubierto formas normales) al encontrar violaciones de los buenos principios de diseño y refactorización.

Realmente no hay ningún método algorítmico para alcanzar un buen diseño en ninguno de los dos mundos. Como señala Rein Hendrichs, hay muchos principios que pueden identificar problemas potenciales (también conocidos como olores de código). Los patrones de diseño y las mejores prácticas son algunas de las formas en que las personas han tratado de abordarlos. El desarrollo impulsado por pruebas intenta encontrarlos temprano ejercitando el código como lo hará externamente. Al igual que en el desarrollo de bases de datos, la mejor solución se encuentra con la experiencia y el análisis.

Un enfoque muy bueno para diseñar objetos de modelo de negocio que es similar a la normalización es el modelado en color UML .

Es una estrategia de diseño encontrada por Peter Coad que ayuda a abstraer los objetos del modelo de negocio.

Desafortunadamente el libro - Modelado Java en color con UML: Componentes y procesos empresariales - está agotado y solo puede comprar los usados.

Hay un par de artículos en Internet sobre esta técnica.

Si está familiarizado con el diseño relacional, encontrará que el modelado UML en color es útil para guiarlo:

• 'Modelado en color' de Peter Coad - Notas de Stephen R. Palmer

¿Ha investigado el uso de anotaciones Java ORM en su código al crear su diagrama de clase? Hibernate generaría la base de datos una vez que finalice la etapa de modelado. El diagrama en este ejemplo es solo un visor del código.

Las referencias a objetos o punteros son similares a las claves foráneas. Eso es tan profundo como estoy dispuesto a pensar en esto. :)

En realidad pensaré más profundo. Si modela sus objetos con 0 duplicación de datos y podría "consultar" sus objetos y realizar actualizaciones basadas en conjuntos en ellos, no habría desconexión. De hecho, PUEDES hacer esto haciendo una biblioteca de consumidor de objetos. Microsoft ya ha pensado en esto, pero tomó la dirección de hacer que la sintaxis LINQ basada en conjuntos sea parte de C # sobre una "biblioteca de consultas".