Introdução

Robert L. Glass argumentou que a prática precede a teoria. Especialmente no desenvolvimento de software, a prática é um campo onde a prática precede a teoria, e os desenvolvedores aprendem mais ao sujar as mãos com código concreto. Portanto, vamos deixar a teoria e os conceitos para mais tarde e dar uma olhada em um programa simples.

Implementando uma Aplicação de Venda de Ingressos

• Estamos planejando organizar um pequeno evento para promover um teatro.
  • Conteúdo do evento: Sorteio para enviar convites para os sortudos para assistir ao show gratuitamente.
• Precisamos separar os participantes que ganharam o evento dos que não ganharam.
  • Participantes que ganharam o evento: trocar o convite por um ingresso.
  • Participantes que não ganharam o evento: comprar o ingresso por dinheiro.

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

Qual é o problema?

Robert Martin descreve três funções que um módulo de software (independentemente do tamanho, como uma classe, pacote ou biblioteca, qualquer elemento que compõe um programa) deve ter.

• Funciona corretamente em tempo de execução.
• Existe para ser modificado.
  • A modificação deve ser possível com um mínimo de esforço.
• Comunicar-se com aqueles que leem o código.
  • O desenvolvedor deve ser capaz de ler e entender facilmente.

O aplicativo de venda de ingressos descrito anteriormente atende ao primeiro requisito de execução correta, mas não atende aos objetivos de facilidade de modificação e comunicação.

Código que não atende às expectativas

Vamos analisar o motivo pelo qual o objetivo da comunicação não é atendido.

• O que o método enter() da classe Theater faz?
  • O teatro abre a bolsa do espectador para ver se há um convite dentro.
  • Se houver um convite na bolsa, ele pede ao vendedor para mover o ingresso que está guardado no caixa para a bolsa do espectador.
  • Se não houver um convite na bolsa, ele pega o dinheiro da bolsa do espectador, compra um ingresso e o coloca na bolsa do espectador.
• Do ponto de vista do espectador, o teatro, como um terceiro, deve examinar livremente sua bolsa, pegar o dinheiro e colocar um ingresso nela.
• Do ponto de vista do vendedor, o teatro, como um terceiro, deve examinar livremente os ingressos e o dinheiro no caixa sem permissão.
• Código compreensível significa código que não se desvia muito das nossas expectativas, e o teatro acima desvia-se das nossas expectativas.
  • O espectador deve retirar o dinheiro da sua bolsa e pagá-lo ao vendedor para receber o ingresso.
  • O vendedor deve retirar o ingresso do caixa e entregá-lo ao espectador, e receber o dinheiro do espectador e guardá-lo no caixa.
• Além disso, para entender o método enter(), você precisa se lembrar de vários detalhes.
  • Audience tem Bag.
  • Bag contém dinheiro e ingresso.
  • TiketSellet vende ingressos no TicketOffice, e TicketOffice armazena dinheiro e ingressos.

Código vulnerável a alterações

O método enter() pressupõe duas condições.

• O espectador sempre carrega uma bolsa para guardar dinheiro e convite.
• O vendedor vende ingressos apenas no caixa.

E sobre a situação abaixo?

• O espectador pode não ter uma bolsa.
• O espectador pode usar um cartão de crédito, não dinheiro.
• O vendedor pode vender ingressos fora do caixa.

Por exemplo, para atender ao primeiro requisito, precisamos remover o objeto Bag de Audience e modificar o método enter() da classe Theater. Isso ocorre porque a classe Theater depende muito do fato de que o espectador está carregando uma bolsa e o vendedor está vendendo ingressos apenas no caixa. Se um desses detalhes mudar, precisamos modificar tanto a classe quanto a classe dependente (ex. Theater).

Este é um problema relacionado à dependência entre objetos, e a dependência implica um impacto na modificação. No entanto, o objetivo do projeto orientado a objetos é construir uma comunidade de objetos que cooperam entre si, dependendo um do outro, então, em vez de simplesmente remover a dependência, precisamosmanter o mínimo de dependênciasnecessário para implementar a funcionalidade do aplicativo e remover as dependências desnecessárias.

Chamamos de acoplamentoo caso em que a dependência entre objetos é excessiva. Quanto maior o acoplamento entre dois objetos, maior a probabilidade de eles serem modificados juntos. Portanto, o objetivo do projeto é reduzir o acoplamento entre objetos para criar um projeto que seja fácil de modificar.

Melhorando o projeto

O Theater não precisa saber se o espectador está carregando uma bolsa ou se o vendedor está vendendo ingressos no caixa. O Theater só quer que o espectador entre no teatro. Portanto, devemos permitir que o espectador processe independentemente o dinheiro e o convite dentro da bolsa, e permitir que o vendedor processe independentemente os ingressos e o preço de venda no caixa.

Aumentar a autonomia

Dizemos que um objeto tem alta coesão quando ele executa apenas tarefas intimamente relacionadas e delega tarefas não relacionadas a outros objetos. Criar objetos autônomos que processam seus próprios dados pode reduzir o acoplamento e aumentar a coesão.

Orientação a procedimentos e orientação a objetos

• Orientação a procedimentos
  • O método enter() do Theater é um processo, e Audience, TicketSeller, Bag e TicketOffice são dados.
  • O estilo de colocar processos e dados em módulos separados é chamado de programação orientada a procedimentos.
  • Há muito código que é contrário à nossa intuição. (ex. O espectador gerencia seu próprio dinheiro e convite).
  • É difícil restringir o impacto da mudança de dados.
  • A responsabilidade é gerenciada de forma centralizada. (Theater gerencia tudo)
• Orientação a objetos
  • O estilo de colocar dados e processos dentro do mesmo módulo é chamado de programação orientada a objetos.
  • Podemos escrever código que corresponde à nossa intuição.
  • O impacto da mudança de dados pode ser restrito de forma eficaz por meio de encapsulamento.
  • Cada objeto é responsável por si mesmo.
  • 
    

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

Podemos melhorar ainda mais.

• A classe Bag da classe Audience ainda é um ser passivo arrastado pela classe Audience, então precisamos tornar a classe Bag um objeto autônomo.
• O TicketOffice da classe TicketSeller também é administrado livremente pela TicketSeller. Precisamos tornar o TicketOffice um objeto autônomo.
  • No entanto, após a modificação, TicketOffice acabou sendo acasalado com Audience.
  • Como este é o caso, o projeto deve ser ponderado cuidadosamente. Neste caso, podemos concordar em criar um TicketOffice que seja um objeto passivo em certa medida para reduzir o acoplamento com Audience.

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

É mentira!

• Mesmo que seja uma entidade passiva na vida real, quando entra no mundo da programação orientada a objetos, tudo se torna uma entidade ativa e autônoma.
• É bom usar a personificação para pensar em objetos passivos como se estivessem rindo, falando e brigando.

Projeto Orientado a Objetos

Por que a modelagem é necessária?

• O projeto é a disposição do código.
• Um bom projeto é um que atende totalmente aos requisitos de hoje e aceita mudanças futuras sem problemas.

Projeto Orientado a Objetos

• Código modificável é código fácil de entender.
• O paradigma orientado a objetos nos ajuda a escrever código da maneira como vemos o mundo.
• Os objetos são entidades autônomas que são responsáveis por seus próprios dados.
• Um ótimo projeto orientado a objetos é um projeto que gerencia adequadamente a dependência entre objetos cooperativos.

Fontes

• Objetos