"Olá, amigo! Eu gostaria de falar sobre outro benefício do OOP. Veja bem, os programas são mais como animais do que como edifícios. Eles não são construídos, eles são cultivados. Desenvolvimento significa mudanças constantes. Na construção, você pode tenha um bom plano e siga-o à risca. Mas no desenvolvimento de software, esse não é o caso."

Muitas vezes, você não consegue fazer algo da maneira que pretendia e precisa retrabalhar muito o seu programa. E ainda mais frequentemente, os requisitos do cliente mudam.

"Mas e se o cliente fornecer uma especificação realmente detalhada?"

"Veja o que acontece com o tempo. Se um produto for bem-sucedido, o cliente vai querer lançar uma nova versão, e depois outra, e outra. E, claro, você terá que fazer algumas " pequenas mudanças " para o produto existente. Portanto, o desenvolvimento de software é uma longa série de mudanças. Apenas a cadência difere. Uma nova versão pode ser lançada a cada semana, uma vez por mês ou a cada seis meses."

Java webinar

"Então, o que concluímos de tudo isso?"

"A estrutura interna do produto deve ser mantida de forma a permitir que grandes (e pequenas) mudanças sejam feitas com o mínimo de retrabalho."

"Como você faz isso?"

"Já falamos sobre como um programa consiste em objetos que interagem entre si. Vamos usar pontos grossos para representar todos os objetos do nosso programa no quadro. Desenharemos setas de cada objeto (ponto) para todos os objetos (pontos) com os quais ele interage."

Agora vamos combinar os objetos (pontos) em grupos. Os pontos pertencem ao mesmo grupo se estiverem muito mais conectados entre si do que os outros pontos. Se a maioria das setas de um ponto aponta para pontos em seu grupo, agrupamos os objetos corretamente. Pontos dentro do mesmo grupo são considerados fortemente acoplados, enquanto pontos em grupos diferentes são fracamente acoplados.

Isso é chamado de « princípio do acoplamento flexível ». Um programa é dividido em várias partes, muitas vezes camadas, cuja lógica está fortemente ligada à sua estrutura interna e fracamente ligada a outras camadas/partes. A interação entre as camadas geralmente é altamente compartimentalizada. Uma camada pode chamar outra camada usando apenas um pequeno subconjunto de suas classes.

"O mesmo princípio da 'divisão do trabalho', mas em uma escala maior?"

"Exatamente. Isso nos permite reorganizar um departamento, torná-lo mais eficiente e contratar ainda mais pessoas, e se não mudarmos os protocolos interdepartamentais, todas as nossas mudanças serão locais. Ninguém precisa ser retreinado. Não precisamos t tem que retrabalhar todo o sistema. Cada departamento pode otimizar seus assuntos internos dessa forma se os mecanismos de interação departamental forem bem escolhidos."

"Se forem bem escolhidos. E se não forem bem escolhidos?"

'Então você rapidamente ficará sem " espaço de manobra " para fazer alterações e terá que retrabalhar todo o sistema. Isso acontece de vez em quando. Não podemos prever o futuro, mas podemos minimizar o número de vezes que temos que reescrever o programa."

"Tudo bem. Vejo o benefício de dividir o programa dessa maneira, mas como o OOP entra em cena?"

“Quando escolhemos como estruturar os departamentos e como eles vão interagir, aplicamos o ' princípio da abstração '. Na programação, a abstração é usada para determinar a melhor forma de dividir o programa e como as partes devem interagir. também ser aplicado repetidamente às partes constituintes até que tenhamos dividido o programa em classes individuais."

"E esconder a estrutura interna dessas partes e limitar estritamente como elas interagem com outras partes - isso é encapsulamento , certo?"

"Exatamente. Encapsulamento e abstração são os pilares da OOP. Um bom programa deve aderir a esses dois princípios. Mais tarde, veremos outros princípios e compreenderemos suas vantagens."

"Coisas boas. Mal posso esperar!"