1. História da empresa
Quero contar uma história que demonstra como OOP ajuda a combater a complexidade de grandes sistemas. Isso é necessário para você entender o propósito do OOP .
Era uma vez uma pequena empresa que fornecia serviços de transporte intergaláctico...
Vamos chamá-lo de Galaxy Rush. Empregava 5 pessoas. Um trabalhava nas finanças, o segundo trabalhava em um depósito, o terceiro fazia as entregas, o quarto cuidava da publicidade e o quinto administrava toda a empresa.
Eles eram muito trabalhadores e tiveram sucesso em tudo. A empresa tinha uma boa reputação e ganhava muito dinheiro. Mas a cada ano havia mais e mais pedidos, então o chefe teve que contratar mais funcionários. Vários outros para o depósito, vários outros para entregas, mais um para finanças e um especialista em publicidade adicional para expandir a participação de mercado da empresa.
E foi aí que os problemas começaram. Havia mais pessoas e eles começaram a atrapalhar uns aos outros.
O profissional de marketing esgota a conta bancária em uma nova campanha publicitária, portanto, não há dinheiro para comprar produtos que precisam ser enviados com urgência.
O armazém tem 10 hyper drives novinhos em folha que são enviados a um cliente uma vez por mês. Um mensageiro chegou e levou um hiperdrive para um cliente diferente, fazendo com que o pedido normal de 10 hiperdrives fosse atrasado em um mês. O primeiro correio simplesmente não sabia que o outro pedido estava sendo atendido pelo segundo correio.
O novo gerente assistente envia um mensageiro em uma nave espacial para comprar mais mercadorias. Enquanto isso, todos os outros esperam que uma nave disponível apareça. Há toneladas de entregas urgentes, mas esta assistente apenas supervisiona as compras e está tentando fazer bem o seu trabalho. Quanto melhor um funcionário desempenha suas funções, mais ele interfere no trabalho dos outros.
Analisando a situação, o patrão percebe que recursos importantes como a nave, o dinheiro e os produtos não estão sendo utilizados da melhor forma. Em vez disso, eles estão sujeitos à regra "você adia, você perde". Qualquer funcionário pode pegar um recurso que todo mundo precisa para seu trabalho, colocando em risco os outros funcionários e a empresa como um todo.
Algo precisava ser feito, então o chefe decidiu dividir a empresa monolítica em alguns departamentos. Ele criou um departamento de expedição, um departamento de marketing, um departamento de compras, um departamento financeiro e um departamento de estoque. Ninguém mais poderia simplesmente pegar a nave espacial. O chefe do departamento de expedição recebeu todas as informações sobre as entregas e enviou o navio ao correio com o pedido mais lucrativo. Além disso, o depósito não permitia que os correios simplesmente pegassem as mercadorias que desejassem. Em vez disso, a coleta de produtos do depósito tornou-se um processo controlado. O departamento financeiro não liberaria fundos para uma campanha de marketing se soubesse que haveria uma compra em breve. Cada departamento tinha uma face pública — o chefe do departamento.A estrutura interna de cada departamento era assunto próprio. Se um mensageiro queria receber produtos, ele ia ao gerente do depósito, não ao depósito. Se um novo pedido chegasse, ele seria recebido pelo chefe do departamento de expedição ( public-facing representative) e não por um mensageiro ( someone not authorized to interact with the other departments).
Ou seja, o chefe consolidava os recursos e as ações envolvendo recursos em grupos (departamentos) e também proibia que outros interferissem nas estruturas internas dos departamentos. As interações interdepartamentais tinham que passar por uma pessoa específica.
Do ponto de vista da OOP , isso nada mais é do que dividir o programa em objetos. Um programa monolítico de métodos e variáveis torna-se um programa composto de objetos. E os objetos têm variáveis e métodos.
O problema era que qualquer funcionário podia trabalhar com qualquer recurso e dar ordens a qualquer outro funcionário, tudo sem supervisão ou controle. Impusemos uma pequena restrição, mas conseguimos mais ordem. E também conseguimos controlar melhor tudo.
Isso é dividir e conquistar em sua forma mais pura.
2. Como os programas são criados
Quero abordar mais um ponto importante que revela outra vantagem do OOP . Você vê que os programas são mais parecidos com animais do que com edifícios? Eles não são construídos. Eles são crescidos. Desenvolvimento é mudança constante. Na construção, você pode ter um bom plano e segui-lo com precisão. Este não é o caso do desenvolvimento de software.
Muitas vezes, na programação, você não pode fazer algo da maneira que pretendia originalmente e deve retrabalhar muito. Os requisitos do cliente mudam ainda mais frequentemente.
Mas e se o cliente fornecesse uma especificação muito precisa? Isso torna as coisas ainda piores. Veja o que acontece com o produto ao longo do tempo.
O sucesso do produto levará o cliente a querer lançar uma nova versão, depois outra e outra. E, claro, tudo o que você precisa fazer é adicionar "pequenas alterações" ao produto existente. Então você pode ver que o desenvolvimento de produtos é uma sequência de mudanças constantes. Apenas a escala de tempo é diferente. Uma nova versão pode ser lançada uma vez por semana, uma vez por mês ou uma vez a cada seis meses.
E que conclusão podemos tirar de tudo isso? A estrutura interna do produto precisa ser mantida de forma a permitir que mudanças significativas (e pequenas) sejam feitas com o mínimo de retrabalho.
Coesão de objetos
Mas fazer isso é mais difícil do que decidir fazê-lo. Já dissemos que um programa consiste em objetos que interagem entre si. Vamos desenhar todos os objetos do nosso programa no quadro, representando-os por pontos. E vamos desenhar setas de cada objeto (ponto) para todos os outros objetos (pontos) com os quais ele interage.
Agora vamos combinar os objetos (pontos) em grupos. Os pontos devem ser agrupados se as conexões entre eles forem muito mais intensas do que com outros pontos. Se a maioria das setas de um ponto for para outros pontos em seu próprio grupo, então os grupos foram formados corretamente. Dizemos que os pontos dentro de um grupo têm alta coesão , enquanto pontos em diferentes grupos têm menor coesão.
Princípio de acoplamento frouxo
Existe um "princípio de acoplamento fraco". Um programa é dividido em várias partes, que geralmente são camadas. A lógica dessas camadas/partes é fortemente acoplada à sua estrutura interna e muito vagamente acoplada a outras camadas/partes. As interações entre as camadas geralmente são muito reguladas. Uma camada pode se referir à segunda camada e usar apenas um pequeno subconjunto de suas classes. Esse é o princípio de "dividir a empresa em departamentos" que vimos anteriormente, mas em escala maior.
O resultado é que podemos reorganizar um departamento conforme necessário para aumentar sua eficácia e podemos contratar ainda mais pessoas para o departamento e, desde que não mudemos o protocolo de interação com nossos outros departamentos, todas as alterações feitas serão permanecem locais. Ninguém precisa reaprender nada. Você não precisa retrabalhar todo o sistema. Cada departamento pode fazer esse tipo de otimização interna se os mecanismos de interação interdepartamental forem bem escolhidos.
Bem escolhido. Mas e se eles não forem bem escolhidos? Então a capacidade de mudança rapidamente se esgota e você terá que refazer todo o sistema. Isso tem que ser feito de vez em quando. Você não pode prever o futuro, mas pode manter o número de refeitos no mínimo.
Princípio da abstração
Escolher como os departamentos são estruturados e como eles interagem é o " princípio da abstração ". Na programação, é usado para determinar a melhor maneira de dividir um programa em partes constituintes e como essas partes devem interagir. Podemos reaplicar o princípio, dividindo as partes resultantes em partes, até dividirmos o programa em classes individuais.
Ocultar a estrutura interna dessas partes e limitar estritamente as interações com outras partes é encapsulamento . Encapsulamento e abstração são pilares da OOP . Um bom programa deve seguir esses dois princípios. No futuro, veremos o restante dos princípios e exploraremos os benefícios que eles oferecem.