Introducción

Robert L. Glass argumentó que la práctica precede a la teoría. Especialmente en el desarrollo de software, la práctica está adelante de la teoría, y los desarrolladores aprenden más cuando ensucian sus manos creando código concreto. Por lo tanto, vamos a dejar de lado la teoría y los conceptos por un tiempo y echar un vistazo a un programa simple.

Implementar una aplicación de venta de entradas

• Se planea organizar un pequeño evento para promover el teatro.
  • Contenido del evento: enviar invitaciones para ver el espectáculo de forma gratuita a los asistentes elegidos por sorteo
• Los asistentes que hayan ganado el sorteo deben ser separados de los que no.
  • Asistentes que hayan ganado el sorteo: canjear la invitación por una entrada
  • Asistentes que no hayan ganado el sorteo: comprar la entrada por dinero

Código de práctica:https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

¿Qué está mal?

Robert Martin describe tres funciones que debe tener un módulo de software (un elemento arbitrario que compone un programa, independientemente de su tamaño, como una clase, un paquete o una biblioteca).

• Funciona correctamente durante la ejecución.
• Existe para ser cambiado.
  • Debería ser posible cambiar con poco trabajo.
• Se comunica con las personas que leen el código.
  • Los desarrolladores deben ser capaces de leerlo y entenderlo fácilmente.

La aplicación de venta de entradas anterior satisface la primera restricción, que es ejecutar correctamente, pero no satisface los objetivos de facilidad de cambio y comunicación.

Código que no cumple las expectativas

Veamos por qué no se satisface el objetivo de comunicación.

• Lo que hace el método enter() de la clase Theater
  • El teatro abre el bolso del asistente para ver si hay una invitación.
  • Si hay una invitación en el bolso, se le dice al vendedor que mueva la entrada que está en la taquilla al bolso del asistente.
  • Si no hay una invitación en el bolso, se le dice al asistente que saque dinero en efectivo del bolso por el precio de la entrada, compre la entrada y la ponga en el bolso.
• Desde el punto de vista del asistente, un tercero, el teatro, debe buscar en su bolso, tomar dinero y poner una entrada.
• Desde el punto de vista del vendedor, un tercero, el teatro, debe manipular las entradas y el efectivo de la taquilla sin permiso.
• Un código comprensible es un código que no se desvía mucho de nuestras expectativas. El teatro anterior no cumple nuestras expectativas.
  • El asistente debe sacar el dinero de su bolso y pagárselo al vendedor para recibir la entrada.
  • El vendedor debe sacar la entrada de la taquilla y dársela al asistente, y cobrar el dinero al asistente y guardarlo en la taquilla.
• Además, para comprender el método enter(), se debe recordar toda una serie de detalles.
  • Audience tiene un objeto Bag.
  • Bag contiene efectivo y entradas.
  • TicketSellet vende entradas en TicketOffice, y TicketOffice contiene dinero en efectivo y entradas.

Código vulnerable a cambios

El método enter() asume dos condiciones.

• El asistente siempre lleva un bolso para guardar dinero en efectivo y una invitación.
• El vendedor solo vende entradas en la taquilla.

¿Qué pasa con las siguientes situaciones?

• El asistente puede no tener un bolso.
• El asistente puede usar una tarjeta de crédito en lugar de dinero en efectivo.
• El vendedor puede vender entradas fuera de la taquilla.

Por ejemplo, para satisfacer el primer requisito, debemos eliminar el objeto Bag de Audience y modificar el método enter() de la clase Theater. Esto se debe a que la clase Theater depende demasiado de la información detallada de que el asistente lleva un bolso y el vendedor solo vende entradas en la taquilla. Si uno de estos detalles cambia, debemos modificar tanto la clase como las clases que dependen de ella (por ejemplo, Theater).

Este es un problema relacionado con las dependencias entre objetos. Las dependencias implican un impacto en los cambios. Sin embargo, el objetivo del diseño orientado a objetos es construir una comunidad de objetos que colaboren entre sí, por lo que no debemos eliminar las dependencias sin más, sino que debemos mantener solo lasdependencias mínimas necesariaspara implementar las funciones de la aplicación y eliminar las dependencias innecesarias.

Se dice que un caso en el que las dependencias entre objetos son excesivas tiene unalto acoplamiento. Cuanto más alto sea el acoplamiento entre dos objetos, mayor será la probabilidad de que se cambien juntos. Por lo tanto, el objetivo del diseño es reducir el acoplamiento entre objetos para crear un diseño que sea fácil de cambiar.

Mejorar el diseño

Theater no necesita saber que el asistente tiene un bolso y que el vendedor vende entradas en la taquilla. Theater solo quiere que el asistente entre en el teatro. Por lo tanto, debemos hacer que el asistente sea una entidad autónoma que procese su propio efectivo e invitación, y que el vendedor maneje sus propias entradas y tarifa de venta.

Aumentar la autonomía

Se dice que un objeto que realiza solo las tareas estrechamente relacionadas y delega las tareas no relacionadas a otros objetos tiene un alto grado de cohesión. Al crear objetos autónomos que procesen sus propios datos, podemos reducir el acoplamiento y aumentar la cohesión.

Orientación a procedimientos y orientación a objetos

• Orientación a procedimientos
  • El método enter() de Theater es un proceso, y Audience, TicketSeller, Bag y TicketOffice son datos.
  • La forma de colocar procesos y datos en módulos separados se denomina programación orientada a procedimientos.
  • Hay mucho código que va en contra de nuestra intuición. (por ejemplo, el asistente administra su propio dinero e invitación).
  • Es difícil limitar el impacto de los cambios de datos.
  • La responsabilidad se gestiona de forma centralizada. (Theater lo gestiona todo)
• Orientación a objetos
  • La forma de colocar datos y procesos en el mismo módulo se denomina programación orientada a objetos.
  • Podemos escribir código que coincida con nuestra intuición.
  • Podemos limitar eficazmente el impacto de los cambios de datos a través de la encapsulación.
  • Cada objeto es responsable de sí mismo.
  • 
    

Código de práctica:https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

Se puede mejorar aún más.

• La clase Bag de la clase Audience sigue siendo una entidad pasiva arrastrada por la clase Audience, por lo que debemos hacer que la clase Bag sea una entidad autónoma.
• TicketOffice de la clase TicketSeller también está controlado por TicketSeller a voluntad. Debemos hacer que TicketOffice sea una entidad autónoma.
  • Sin embargo, después del cambio, TicketOffice se ha unido a Audience.
  • Este tipo de diseño debe considerar cuidadosamente las compensaciones. En este caso, podemos llegar a un acuerdo para hacer que TicketOffice sea una entidad algo pasiva para reducir el acoplamiento con Audience.

Código de práctica:https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

¡Sí, es una mentira!

• Aunque sea una entidad pasiva en la realidad, en el mundo de la orientación a objetos, todo se convierte en una entidad activa y autónoma.
• Es una buena idea usar la personificación para pensar en los objetos pasivos como si fueran seres que ríen, hablan y se enfadan.

Diseño orientado a objetos

¿Por qué es necesario el diseño?

• El diseño es la forma de organizar el código.
• Un buen diseño es aquel que cumple plenamente con los requisitos de hoy y es capaz de adaptarse suavemente a los cambios de mañana.

Diseño orientado a objetos

• Un código cambiable es un código fácil de entender.
• El paradigma de la orientación a objetos nos ayuda a escribir código de la misma manera que vemos el mundo.
• Los objetos son entidades autónomas que son responsables de sus propios datos.
• Un buen diseño orientado a objetos es aquel que gestiona adecuadamente las dependencias entre objetos colaborativos.

Fuentes

• Objetos