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

9

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?

Ingeniero mundial
fuente
1
OOP no es siempre todo eso ...
Job
Al estudiar OOP, ¿ya has leído algo sobre patrones de diseño ?
Zoredache
1
Te recomiendo que leas el libro de Eric Evan sobre Diseño impulsado por dominio cuando tengas dificultades para crear modelos. Ver también la respuesta de @Simon Stellings. El libro cubre este proceso con bastante detalle.
Falcon
@Zoredache Me he encontrado con el concepto de patrones de diseño, así como algunos ejemplos de algunos, como singleton, factory y MVC (que, en la implementación de Zend, también es controlador frontal). Sin embargo, ese fue mi próximo movimiento, por así decirlo. Recogí el libro de Martin Fowler sobre patrones empresariales y hasta ahora solo he leído una parte de la introducción. ¿Es una introducción clara y fácil de leer que recomendaría?
@Falcon Tenía una pregunta sobre php / MySQL y el formato de fecha en SO el otro día, y hubiera elegido su respuesta, pero fue solo un comentario, por lo que vale.

Respuestas:

10

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.

blubb
fuente
1
Buena respuesta. Además del artículo de Abbott, recomiendo el libro de Eric Evan sobre diseño impulsado por dominio . Enseña cómo crear un lenguaje ubicuo para el proyecto y cómo extraer un modelo poderoso de él.
Falcon
Me atrae esta respuesta porque estudié un poco la lingüística y tiene mucho sentido intuitivo para mí sin mucho esfuerzo, sin embargo, me da miedo por las mismas razones porque descubrí que demasiada analogía puede llevarme por mal camino. .
@Falcon +1 por recomendar un libro con la portada de Kandinsky.
@ tbj1982: Tienes toda la razón. Es una heurística simple, y los resultados deben tratarse con eso en mente. No es la bala de oro, pero puede ser un buen comienzo.
blubb
4

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.

Tae-Sung Shin
fuente
3

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.

tp1
fuente
+1 para nombrar. Es sorprendente cuánto solo el agregar nombres puede organizar los procesos de pensamiento, ya que implícitamente traes todo el conocimiento del "mundo real".
Mark Brackett