oop - responsabilidades - tarjetas crc online
¿Cómo se elabora un diseño usando tarjetas CRC? (6)
Siempre me he estado preguntando cómo las personas usan tarjetas CRC (colaboración de responsabilidad de clase). He leído sobre ellos en libros, encontré información vaga en Internet, pero nunca lo entendí realmente. Creo que alguien debería hacer un video de youtube que muestre una sesión con tarjetas CRC, ya que uno de mis libros lo describió como muy difícil de formular en un texto, que debería ser "enseñado por alguien que ya lo domina". Tristemente, no conozco a nadie por aquí que use tarjetas CRC y me gustaría aprender más.
ACTUALIZAR
Se agradecerá cualquier enlace a videos que muestren a personas que elaboran con esta técnica.
La manera más fácil de usarlos en mi opinión sin meterse en un lío es anotar pequeñas tarjetas CRC en los encabezados de sus archivos de esta manera:
///////////////////////
//* CRC CARD
//* Class: UISliderEvent
//* Responsability: Event that holds the value and id of a Slider''s movement
//* Collaborators: UISlider, UIEvent
//////////////////////
Luego, cada vez que necesite agregar una función, revise su tarjeta y asegúrese de no romper ninguno de los contratos que declaró en ella. Como, de repente, dependiendo de UIMouseEvent, por ejemplo, eso no está en la Tarjeta así que es un no-no incluirlo.
Ve a la fuente : ¿Kent Beck, Ward Cunningham, alguna vez ha oído hablar de ellos?
Es difícil resumirlo en una respuesta SO, pero lo intentaré. Uno de los desafíos del diseño de objetos es equilibrar el pensamiento desde una perspectiva general con el pensamiento desde la perspectiva de un objeto individual. Necesita la perspectiva general para completar el cálculo, pero necesita la perspectiva del objeto individual para subdividir efectivamente la lógica y los datos.
El mantenimiento de este equilibrio es donde entran las tarjetas CRC. Cuando están sentados allí en la mesa, puedes ver el cálculo como un todo. Sin embargo, cuando recoges una sola carta, te animan físicamente, cinestésicamente, a adoptar el punto de vista de ese único objeto. Tengo que hacer una pequeña parte de este cálculo con recursos limitados, ¿cómo lo voy a lograr?
Con el tiempo, la capacidad de mantener simultáneamente ambas perspectivas parece empaparse en el cerebro. Cada vez se escribe menos en las cartas. Entonces las cartas están en blanco. Después de un tiempo, la gente simplemente señala dónde estaría la tarjeta si se molestaran en sacar una en blanco de la pila. Eventualmente, las personas tienen los beneficios del estilo de pensamiento sin necesidad de tarjetas. Sin embargo, cuando se habla con alguien que no domina el equilibrio, sacar tarjetas reales puede ser una ayuda de comunicación útil.
La mayor debilidad que encuentro con las tarjetas es la falta de retroalimentación. Puedes engañarte sobre cómo va a ser el código. Sugeriría usar tarjetas solo hasta que surja una pregunta interesante, pasar a pruebas / código para confirmación y luego reanudar el diseño.
Ward y yo hicimos un video hace unos 15 años de una sesión de diseño, pero no la encuentro en línea en ninguna parte y no tengo una copia. No estoy seguro de que sea útil como herramienta de enseñanza en cualquier caso. No sé de otros videos, pero podrían ser interesantes, especialmente si tienes que comparar varios estilos de diseñadores diferentes.
Trataré de dar una respuesta. Por lo tanto, las tarjetas CRC generalmente se usan para modelar en un entorno orientado a objetos para comprender mejor el sistema que se debe desarrollar (pero creo que ya lo sabrá). Las tarjetas CRC llegan al final, cuando llega justo antes de la implementación real. Los diferentes pasos para alcanzar ese nivel podrían ser los siguientes:
- El punto de partida es hacer el requerimiento de obtención. Involucrar al cliente de manera temprana y continua se sugiere aquí (eche un vistazo a los enfoques ágiles, es decir, programación extrema)
- Los requisitos se pueden modelar con diagramas de caso de uso (UML) o con historias de usuario (enfoque de programación extrema ágil). El problema clave aquí es encontrar los objetos involucrados correctos. Esto depende mucho del dominio en el que te encuentres, por supuesto. Si vas por el camino "difícil", puedes aplicar técnicas como "extracción de sustantivo". Entonces analiza el documento de especificación y extrae todos los sustantivos (incluidos los nombres compuestos y los que tienen adjetivos). Analiza todos y descarta los irrelevantes.
- Una vez que tenga los nombres correctos -> objetos, puede comenzar a crear sus tarjetas CRC. Entonces, ¿qué se hace en una sesión de CRC? La tarea principal es encontrar y asignar las responsabilidades de sus objetos (previamente encontrados) que luego se colocan en fichas pequeñas (nuestras tarjetas CRC). Las "responsabilidades" son principalmente las funcionalidades principales de un objeto específico y la parte de "colaboración" son los otros objetos necesarios para cumplir ciertas funcionalidades (estas son las dependencias entre los diferentes objetos en su modelo). Puntos importantes para asignar las responsabilidades es que las responsabilidades se distribuyen bien en todo el sistema de alguna manera equilibrada. Otro punto muy importante es evitar la duplicación de responsabilidades entre los objetos (aquí es donde las tarjetas CRC ayudan).
Una sesión de CRC debe comenzar con una reunión de intercambio de ideas, tener una discusión activa entre los desarrolladores y debe realizarse en las fichas directamente.
Espero haber podido ayudarte de alguna manera.
Saludos,
Juri
Creo que su afirmación "No conozco a nadie por aquí que use tarjetas CRC" resume bastante bien el estado de las tarjetas CRC en desarrollo. Las tarjetas CRC, en mi opinión, fueron un paso en el camino del desarrollo tradicional, impulsado por el plan, al desarrollo ágil. El mundo ha avanzado. En lugar de centrarme en cómo usar tarjetas CRC, investigaría técnicas como TDD , que puede utilizar técnicas como UML y CRC como artefactos intermedios, pero que se concentra en el código, y más particularmente en las pruebas. Esta es la dirección que tomaron los inventores de las tarjetas CRC y yo recomendaría que también la tomaras.
En su libro Object Design: roles, responsabilidades y colaboraciones publicadas en 2003 Rebecca Wirfs-Brock y Alan McKean discuten las tarjetas CRC con cierto detalle. Enfatizan realmente la diferencia que hace en todo el procedimiento, que esta sea una experiencia muy táctil y afloja el pensamiento de las personas al estar pasando por un objeto físico cuando intentan desarrollar un diseño / requisito.
El subtítulo de ese capítulo sugiere que el uso de las tarjetas es parte de la fase de "diseño exploratorio", por lo que es probable que venga antes de hacer mucha codificación, pero no veo ninguna razón para no volver a consultarlas en cada iteración de un proyecto Ágil y recordándose a sí mismo dónde pensaba que iba y revisándolo si fuera necesario (como grupo por supuesto).
Me parece recordar que incluso sugieren pasar una pelota por la habitación para que solo la persona que tiene la pelota pueda hablar, así que tal vez no sean tanto las tarjetas CRC como las que hagan que todos en una sala hablen de roles y responsabilidades de objetos que importan?
Si desea leer un caso de estudio de tarjetas CRC en acción (además del documento original de Kent y Ward), eche un vistazo al libro de tarjetas The CRC .