Para implementar un objeto cuyo comportamiento sea igual que el comportamiento de una lista de otros objetos se crea un «Imposter» para el objeto de la lista.
Por ejemplo, una transacción incrementa un valor.
Una cuenta calcula su balance sumando los valores de sus transacciones.
Un cliente podrá tener una o más cuentas y, en cualquier caso, podrá ver el balance general de todas sus cuentas. La implementación más obvia sería crear una nueva clase «OverallBalance» que sume el balance de cada una de las cuentas.
Aunque a primera vista puede ser un poco más difícil de ver, existe duplicación de código. Si una «Account» y «Transaction» implementaran la misma interfaz, por ejemplo «Holding» la duplicación desaparecería ya que el «OverallBalance» podría ser una cuenta que contiene cuentas.
La transacción puede implementar el método «balance()».
Una cuenta está compuesta por una o más «Holding».
El olor de «Composite» viene ilustrado por ejemplo anterior. Las transacciones no tienen un balance en el mundo real pero aplicando el patrón los beneficios para el diseño son sustanciales ya que elimina la duplicidad. La traducción no viene del mundo real pero hace el código mucho más simple.
No siempre es tan obvio en qué caso una colección de objetos es una simple colección o se tiene un «Composite». A medida que se va cogiendo experiencia en la refactorización se podrá apreciar la duplicación de código y se podrá valorar si hay que aplicar el patrón «Composite».
No hay comentarios:
Publicar un comentario