¿Cuál es el proceso de pensamiento orientado a objetos? [cerrado]

He estado estudiando OOP en conjunto con la implementación MVC de Zend durante los últimos meses. Soy bastante nuevo en la programación, en general, pero creo firmemente que debería aprender las cosas de la manera "correcta", lo que para mí significa asegurarme de entender por qué las cosas se hacen como están. Es decir, descubrí que al aprender a hacer algo (cualquier cosa, digamos música), la mejor manera de aprender a hacer algo es saber por qué se hace de esa manera en primer lugar.

De todos modos, he estado luchando mucho para comprender cómo desarrollar mis propios modelos de negocio (es decir, la M de MVC), y he decidido que no es porque no entiendo la POO en general, porque lo he estudiado durante varios años. meses y no creo que los conceptos sean muy difíciles de entender. Los ejemplos que he estudiado me parecen muy intuitivos, en realidad. Creo que el problema para mí radica en el proceso de traducir mis propios problemas en soluciones orientadas a objetos. Los ejemplos en los libros (que he leído hasta ahora) son demasiado obvios, por lo que el proceso de traducir el problema en objetos no es muy difícil. Lo que creo que podría estar perdiendo es un proceso abstracto de alto nivel. Algún tipo de lista de pasos o preguntas que toda solución orientada a objetos debe responder al más alto nivel.

Si tuviera que describir dicho proceso en no más de cinco pasos, ¿cuáles serían y por qué? ¿Cuál es el proceso más efectivo para traducir cualquier problema en una solución orientada a objetos?

Encontrar un modelo adecuado no siempre es sencillo. Es una de estas cosas que requieren más experiencia que el simple conocimiento. Sin embargo, la siguiente receta simple podría ayudarlo a superar un bloqueo mental inicial.

Originalmente fue descrito en este artículo por Abbott y frecuentemente se lo denomina "análisis textual de Abbott".

1. Escribe una especificación de texto plano.
2. Identificar clases: los sustantivos son buenos candidatos.
3. Encuentra los atributos: los adjetivos / adverbios son buenos candidatos.
4. Encuentra las operaciones: los verbos son buenos candidatos.
5. Encuentra las asociaciones entre clases.
6. Refinar.

Ejemplo:

Los sustantivos , verbos y adjectivesestán marcados.

La biblioteca contiene libros y revistas . Puede tener varias copias de un libro dado . Algunos de los libros son solo para short-term préstamos . Todos los demás libros pueden ser prestados por cualquier miembro de la biblioteca durante tres semanas. Los miembros de la biblioteca normalmente pueden pedir prestados hasta seis artículos a la vez, pero los miembros del personal pueden pedir prestados hasta 12 artículos a la vez. Solo los miembros del personal pueden tomar prestadas revistas .

Una primera iteración de análisis produciría:

Clases

• Biblioteca
• Libro, diario
• Copiar
• Préstamo
• Miembro de la biblioteca
• Articulo
• Miembro del equipo

A partir de aquí, puede pensar qué clase necesita qué atributos y métodos para implementar el comportamiento y luego refinar cada vez más ese modelo.

En mi opinión, adoptar el enfoque TDD es natural y eficiente:

1. Escriba los requisitos específicos (Dado, Cuándo, Entonces)
2. Traduzca cada requisito (el más importante primero) en una prueba unitaria.
3. Escriba la menor cantidad de código para aprobar la prueba escrita en el n. ° 2.
4. Después de pasar la prueba, refactorice su código de acuerdo con los principios de diseño de SOLIDD.
5. Después del # 4, asegúrese de que su código aún pase todas las pruebas escritas.
6. Repita 2-5.

Con este proceso, puede producir gradualmente código comprobable con diseño de sonido. Puede pensar al principio que la prueba de escritura es innecesaria, pero esa actividad realmente lo ayuda a construir una arquitectura de sonido.

Aquí están los pasos que uso en el código c ++:

1. decidir el nombre de la clase
2. decidir parámetros de constructor y miembros de datos.
3. decidir los nombres y prototipos de funciones miembro
4. hazlo independiente de otras clases
5. El diseño está hecho, y todo lo demás es solo la implementación.

La razón de (1) es que define el alcance de qué funcionalidad pertenece a la clase. La razón de (2) es que define cómo se comunica la clase con el mundo exterior. La razón de (3) es que define cómo elegir qué funcionalidad de la clase se necesita en cada situación. La razón de (4) es que permite que la clase se use en muchas situaciones diferentes. La razón de (5) es que define el límite entre diseño e implementación.