Pregunta

En mi solicitud, tengo varios componentes que tienen que saber el uno del otro, como una barra de menús y una barra de herramientas que tanto necesitan saber sobre la mesa para añadir o eliminar puestos de trabajo y también para averiguar qué trabajo se ha seleccionado .

Por lo tanto, he creado un objeto llamado guiMediator que me pase a cada objeto y que se registran con él, para que puedan llegar a unos de otros de utilizar ese objeto. También es responsable de disparar eventos cuando se añaden nuevos puestos de trabajo o trabajadores fondo terminan su trabajo.

Ya que sabe mucho sobre el sistema, es este tipo de uso demasiada responsabilidad en un solo lugar, o es el uso correcto del patrón?

¿Fue útil?

Solución

Normalmente me gustaría utilizar el patrón de comandos para algo así:

  1. El usuario hace clic en el botón "Foo" en la barra de menús, que ejecuta el FooButtonClickedCommand.
  2. FooButtonClickedCommand hace lo que tiene que hacer, a continuación, modifica la vista (barra de menús, tablas, etc.) de manera apropiada.

Así que sus comandos saben acerca de todos sus componentes de vista, pero la única cosa que sus componentes de vista que necesita saber es el comando a ejecutar cuando una determinada acción se lleva a cabo por parte del usuario.

Otros consejos

Me gustaría utilizar una vista pasivo, que se puede leer sobre aquí .

  • Usted pondría a cada forma detrás de una interfaz
  • Cada forma podría registrarse con uno o más objetos de interfaz de usuario
  • El objeto de interfaz de usuario debe ser organizado de forma natural, como el programa de instalación, entrada, Display, etc. Un procesador de textos puede solamente tener un objeto de interfaz de usuario para cada documento. Mientras que un controlador de la máquina puede tener objeto múltiple para cada pantalla.
  • La interfaz se implementa como cáscaras delgadas transmisión de eventos a los objetos de interfaz de usuario y la exposición de los controles de presentación, dibujo superficies al objeto de interfaz de usuario.
  • El UIObject luego tomar la entrada y se da cuenta de que comando objeto de ejecutar
  • El objeto de comando va a actualizar el modelo, a continuación, diga uno o más objetos de interfaz de usuario para actualizar la vista.
  • Los UIObjects actualizar los puntos de vista.

Tenga en cuenta que en ninguna parte nada más allá de la interfaz de la interfaz de usuario sabe acerca de los botones, casillas de verificación, y similares. Se utiliza la interfaz de abstraer la implementación real de distancia.

Esto le dará varias ventajas. En primer lugar se documentará cómo el código interactúa con la interfaz de usuario, le dará un lugar para poner en práctica los objetos de imitación que se utilizará para las pruebas automatizadas, y finalmente permitir mucha más libertad en el cambio de la interfaz de usuario.

Por ejemplo la sustitución de los paneles se puede hacer clic en lugar de botones de comando. El formulario a continuación, sólo comenzar a pasar los eventos de clic de los paneles en lugar del botón. La forma puede permanecer ignorante de la orden real de cada widget se supone que debe hacer. El objeto de interfaz de usuario se encarga de eso.

suena mejor que la alternativa ... Pero bueno, se casó con la hermana menos fea; -)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top