¿Cómo abordas el diseño de clase en OOP?

Cuando intento diseñar una solución OO, generalmente uso el modelo CRC en el que enumero los nombres de clase (sustantivos), lo que hacen (verbos) y cómo colaboran con otras clases.

Este blog tiene lo siguiente que decir sobre este enfoque de sustantivo-verbo

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

Mi pregunta es, ¿existe una mejor técnica de modelado para usar el enfoque OO?

Para ser justos, él agregó "En diversión" a esa afirmación.

Hasta el día de hoy, tiendo a comenzar modelando sistemas utilizando el enfoque de "sustantivo y verbo", pero a lo largo de los años he descubierto que TDD nos enseña que este enfoque atrae su atención hacia lo incorrecto. En este sentido, el blogger tiene un punto. Sin embargo, no estoy seguro de que sea el enfoque el culpable, más que la forma en que funcionan nuestras mentes.

Si quieres probar un pequeño desafío aquí, deja de leer e intenta modelar el juego Monopoly, usando el idioma inglés, luego vuelve aquí.

Sospecho que la tentación será mirar de inmediato los objetos con los que interactuamos mucho: el tablero, los espacios, las cartas, los dados, las piezas, pero esa no es la mayor parte de la lógica. La mayoría de estos objetos son completamente tontos. Datos, si quieres.

Pero tan pronto como comienzas a escribir pruebas, te das cuenta de qué objeto es, con mucho, el más importante en cualquier juego: las reglas.

¿Recuerdas esa pequeña hoja de papel que leíste una vez la primera vez que obtuviste el juego y no interactúas de nuevo hasta que hay una disputa? La versión computarizada no funciona de esa manera. Cada cosa que el jugador intenta hacer, una computadora consultará las reglas y verá si puede hacerlo o no.

Cuando lo piensas, haces lo mismo, pero como lleva tiempo leer las reglas en papel y tu cerebro tiene un sistema de almacenamiento en caché razonable, consulta las reglas en tu cabeza. Es probable que a una computadora le resulte fácil leer las reglas nuevamente, a menos que estén almacenadas en la base de datos, en cuyo caso también podría almacenarlas en caché.

Y esta es la razón por la que TDD es tan popular para conducir el diseño. Debido a que tiende a conducir su proceso de pensamiento rápidamente a los lugares correctos:

Cuando pienso que voy a escribir algunas pruebas para mi juego Monopoly. Podría mirar mi set e intentar encontrar los objetos. Entonces, tenemos estas piezas. Escribiré algunas pruebas para eso.

Tal vez tendré un MonopolyPiece de clase base y cada tipo de pieza derivará de ellos. Comenzaré con el DogPiece. Primera prueba ... ahh. En realidad, no hay lógica aquí. Sí, cada pieza se dibujará de manera diferente, por lo que podría necesitar un DogDrawer, pero mientras estoy desarrollando el juego, solo quiero escribir "D" en la pantalla. Voy a darle vida a la interfaz de usuario al final.

Encontremos alguna lógica real para probar. Hay muchas de estas casas y hoteles, pero no necesitan pruebas. Dinero no. Tarjetas de propiedad, no. Y así. Incluso la placa no es más que una máquina de estado, no contiene ninguna lógica.

Rápidamente descubrirá que le quedan tres cosas en la mano. Las cartas de Oportunidad y Cofre comunitario, un par de dados y un conjunto de reglas. Estas serán las partes importantes para diseñar y probar.

¿Lo viste venir cuando escribiste los sustantivos y los verbos?

De hecho, hay un gran ejemplo en los patrones y prácticas de principios ágiles de Robert Martin en el que intentan desarrollar una aplicación Bowling Score Card usando TDD y encuentran todo tipo de cosas que pensaban que eran clases obvias con las que no valía la pena molestarse.

Nunca he encontrado tales métodos útiles para mí. De hecho, descubrí que usarlos simplemente me confunde peor. Echa un vistazo a la cafetera de Robert C. Martin , no creo que use este tipo de enfoque tampoco.

Una cosa que me molesta de inmediato es la solución a la que llega la persona en el artículo de CRC al que se vincula. La colaboración Cliente / Pedido no es algo que considero que valga la pena, no como está escrito de todos modos. No hay nada particularmente interesante en ese modelo sobre un Cliente que merezca el estado de la clase. Lo único interesante de ser un "cliente" es que hay una o más órdenes asociadas con esa Persona .

El modelo de la universidad también. Hay muchas cosas que pueden, y probablemente deberían compartirse entre el Estudiante y el Profesor. Además, ¿qué sucede cuando un profesor toma una clase, ya que a menudo se permite de forma gratuita en los campus universitarios?

Supongo que podría ser una práctica valiosa, un elemento en el kit de herramientas de diseño. Sin embargo, no creo que deba ser la única forma de abordar el diseño. Francamente, encuentro que el enfoque de análisis de variación / comunidad es más útil. Me parece modelar muy de cerca lo que hacemos al clasificar las abstracciones durante la vida cotidiana.

Editar: Acabo de leer la mitad de ese segundo blog y tengo que decir que estoy bastante de acuerdo. Tendré que leer el resto y ver qué ofrece en términos de aprendizaje.

Mi opinión es que las clases deben agregarse (y eliminarse) a medida que codifica para separar las preocupaciones y reducir las dependencias. Tener fluidez en los patrones de diseño es probablemente una buena apuesta para ver las posibilidades de refactorización y simplificación.

Las clases en general, en mi experiencia, no caen perfectamente en las categorías de sustantivo / verbo, sino que terminarás con una mezcla de clases de sustantivo / verbo junto con diferentes clases de patrones (fábricas, singletons, patrones de estrategia, etc.) y otras clases de gerentes que aborda un aspecto de su aplicación.

La clave es que su objetivo debe ser poder mirar una clase y deducir lo que hace y modificarla solo cambiando esa clase. Cuanto más código para un aspecto de su aplicación se distribuya entre las clases, más difícil será seguirlo, administrarlo y extenderlo.