En este caso, la inclusión de los módulos funcionó como un encanto porque me mostró claramente la responsabilidad de cada papel y supe a primera vista lo que se suponía que debían hacer (antes estaba oculto en las profundidades de la herencia tradicional). Cualquier nuevo desarrollador puede entender inmediatamente lo que está pasando ahora. En mi primer código, las cosas no eran tan obvias (aunque no era imposible comprenderlo).
Los papeles son pequeños y enchufables. Esto permite que sean fácilmente utilizables en otros contextos siempre y cuando se respete el contrato y el cambio de un rol apenas afecte a los otros porque son únicos y aislados. Si están bien diseñados, ni siquiera un gran refactor de sistema romperá ninguno de ellos, lo que significa que invitan a cambios en el sistema, y este es el principal propósito de OO en primer lugar. Como Sandi Metz dijo,
«Estos pequeños objetos tienen una única responsabilidad y especifican su propio comportamiento. Son transparentes; es fácil entender el código y está claro lo que pasará si cambia. Además, la independencia del objeto compuesto de la jerarquía significa que hereda muy poco código y por lo tanto es generalmente inmune a sufrir efectos secundarios como resultado de los cambios en las clases superiores de la jerarquía».
Lo que más aprecio de las preocupaciones es cómo podemos documentar la relación entre las clases en los exámenes. Nuestra única documentación verdaderamente actualizada es el código en sí mismo y los tests son un gran lugar para entender para qué se diseñaron las cosas. Pensando en los roles, hay algunos tests que seguramente se repetirán una y otra vez para cada clase de rol. Por ejemplo, podríamos querer estar seguros de que todos ellos responden a un determinado método (como el método «stop?»).
En lugar de repetirse, podemos crear ejemplos compartidos que sirvan para todos los papeles. Cada clase que incluya nuestro módulo ganará automáticamente estas pruebas sin una sola línea repetida.
123 ejemplos compartidos para $0027un restrictor$0027do it { is_expected.to respond_to($0027stop?$0027)}endrubí
Más que eso, el código que incluirá esas pruebas compartidas sobre los roles también nos dice que la clase se comporta como un rol:
1it_behaves_like $0027a restrictor$0027
rubí
Un consejo: al crear un archivo con ejemplos compartidos, no utilice el sufijo spec en el nombre del archivo, o las pruebas se ejecutarán dos veces.
Con sólo echar un vistazo a la parte superior del archivo de prueba sabemos instantáneamente que se comporta como un restrictor, lo que implica que aceptó una interfaz implícita y, por lo tanto, responderá a un conjunto de métodos esperados. Para eliminar la herencia, todo lo que necesitamos es un cambio muy pequeño. Primero, eliminar la clase de ReglaBase. Luego, podemos crear nuestra preocupación:
123456789moduleRestrictor extender ActiveSupport::Preocupación incluida dodefstop?(list)trueendendend
rubí