Hasta ahora, en esta serie, hemos analizado la programación orientada a objetos en general y el principio de cohesión OOP. En este artículo, veremos el principio de acoplamiento Y como ayuda en el desarrollo del juego..
Nota: Aunque este tutorial está escrito con Java, debería poder usar las mismas técnicas y conceptos en casi cualquier entorno de desarrollo de juegos.
Acoplamiento es el principio de "separación de preocupaciones". Esto significa que un objeto no cambia o modifica directamente el estado o comportamiento de otro objeto.
El acoplamiento analiza la relación entre los objetos y cuán estrechamente conectados están. Un diagrama de relaciones es una excelente manera de visualizar las conexiones entre objetos. En dicho diagrama, los cuadros representan objetos y las flechas representan una conexión entre dos objetos donde un objeto puede afectar directamente a otro objeto.
Un buen ejemplo de acoplamiento es HTML y CSS. Antes de CSS, HTML se usaba tanto para el marcado como para la presentación. Esto creó un código hinchado que fue difícil de cambiar y mantener. Con la llegada de CSS, el HTML se usó solo para el marcado, y el CSS se hizo cargo de la presentación. Esto hizo que el código fuera bastante limpio y fácil de cambiar. Las preocupaciones de presentación y marcado fueron separadas..
Se dice que los objetos que son independientes entre sí y no modifican directamente el estado de otros objetos son débilmente acoplado. El acoplamiento suelto permite que el código sea más flexible, más cambiante y más fácil de trabajar.
Los objetos que dependen de otros objetos y pueden modificar los estados de otros objetos se dicen que son estrechamente acoplado. El acoplamiento firme crea situaciones en las que modificar el código de un objeto también requiere cambiar el código de otros objetos (también conocido como efecto de onda). El código estrechamente acoplado también es más difícil de reutilizar porque no se puede separar.
Una frase común que escuchará es "esforzarse por un bajo acoplamiento y una alta cohesión". Esta frase es un recordatorio útil de que debemos esforzarnos por obtener un código que separe las tareas y que no dependamos mucho de las demás. Por lo tanto, el acoplamiento bajo (o suelto) es generalmente bueno, mientras que el acoplamiento alto (o apretado) es generalmente malo.
Primero, veamos los objetos de los asteroides y cómo están conectados. Recuerde que los objetos son una nave, un asteroide, un platillo volador y una bala. ¿Cómo se relacionan o conectan estos objetos entre sí??
En los asteroides, un barco puede disparar una bala, una bala puede golpear un asteroide y un platillo volador, y un asteroide y un platillo volador pueden golpear el barco. Nuestro diagrama de relaciones se ve como sigue:
Como se puede ver, todos los objetos están bastante bien interrelacionados. Debido a esto, debemos tener cuidado de cómo escribimos el código, de lo contrario terminaremos con un sistema estrechamente acoplado. Tomemos por ejemplo el barco disparando una bala. Si la nave creara un objeto de bala, mantuviera un registro de su posición y luego modificara el asteroide cuando la bala golpea, nuestro sistema estaría muy estrechamente acoplado..
En su lugar, el barco debe crear un objeto de bala., Pero no te preocupes por eso después de ese punto.. Otra clase sería responsable de hacer un seguimiento de la posición de la bala, así como lo que sucede cuando una bala golpea un asteroide. Con una clase intermedia entre nuestras relaciones, el diagrama se vería de la siguiente manera:
Este diagrama de relaciones se ve mucho mejor y crea un sistema muy débilmente acoplado. En este sistema, si tuviéramos que agregar un objeto, como un meteoro, podríamos hacerlo fácilmente sin tener que cambiar la forma en que funcionan los objetos de la nave o la bala, simplemente dejaríamos que nuestra clase intermedia se encargara de todo..
Dado que solo hay un objeto en Tetris, el Tetrimino, el acoplamiento no es realmente un problema ya que no puede haber ninguna relación con otros objetos.
Para Pac-Man, el acoplamiento apretado podría ocurrir cuando Pac-Man come una bolita de energía. Cuando se consume una bola de energía, Pac-Man puede comer fantasmas y el estado del fantasma cambia a comestible
. Si el objeto Pac-Man tuviera que rastrearse cuando se comió una bolita de energía y luego iniciar el estado de cambio de cada fantasma, el sistema estaría estrechamente acoplado..
Nuevamente, se requiere otra clase para realizar un seguimiento de esta información y procesarla para que nuestros objetos se puedan acoplar libremente. A continuación se muestra un ejemplo de cómo una clase intermedia podría rastrear a Pac-Man comiendo una bolita de energía..
/ ** * Clase intermedia que realiza un seguimiento de los eventos del juego * / clase pública Juego … if (Pac-Man.eats (Power_Pellet)) Ghosts.changeState (); …
El acoplamiento es el principio de reducir la forma en que los objetos afectan directamente los estados y comportamientos de otros objetos. El acoplamiento ayuda a crear un código que es más fácil de leer y más fácil de cambiar.
En el siguiente Consejo rápido, discutiremos el principio de encapsulamiento y por qué ayuda a crear código mantenible. Síganos en Twitter, Facebook o Google+ para mantenerse al día con las últimas publicaciones..