Lorem Ipsum (bom dia em inglês) meus caros. Hoje vou falar sobre duas coisas mais interligadas do que goiaba e bicho de goiaba: Projeto de interfaces e encapsulamento! É recomendável que você ao menos finja que tenha lido os outros artigos da série.
Na OOP é muito mais importante conhecer a parte teórica do que a prática. Você pode saber como declarar classes, instanciar objetos, executar métodos e ainda sim fazer uma bosta de projeto totalmente inútil. Bom senso é a regra clássica, mas existem uns bons conceitos para estudar e melhorar seu intellisense mental.
Encapsulamento
Esse é um dos princípios na OOP que separam os bons programadores dos programadores inexperientes, ruins ou até mesmo dos palmeirenses (kkkk zuei). A regra é simples: Você deve colocar os métodos nas classes que contém a informação que eles processam. Exemplo maroto:
Em muitas linguagens visuais orientadas a objetos (COF COF DELPHI POR EX COF) cada elemento na tela é um objeto de uma classe distinta. Botões, por exemplo, tem um método responsável pelos cliques que o usuário certamente fará compulsivamente nesses botões. A idéia seria que dentro desse método, você fizesse chamadas para outros objetos que realizam as ações necessárias. Um botão “zipar” por exemplo seria responsável apenas por chamar o(s) objeto(s) que controlam um arquivo zip.
~encasulamento rs nadav~
Mas é claro que muitos programadores ignoram essas boas práticas “totalmente desnecessárias” e vivem na Programação Orientada a Botão, que significa enfiar sorrateiramente toda a lógica e algoritmos de zipar o arquivo dentro do método do botão. Se você entendeu o motivo pelo qual isso é ruim, parabéns, você pode começar a usar seu sabre de luz no próximo artigo. Do contrário, apenas continue lendo que eventualmente o dharma iluminará sua consciência.
Colocar um algoritmo de compressão dentro de um método de um botão não faz o mínimo sentido porque não é a responsabilidade do botão. A única coisa que o botão deve fazer é iniciar uma ação, não ser responsável por como essa ação é executada. Pense no princípio do reúso: se você separar o botão da ação que ele executa, você poderá reutilizar aquela ação em outros contextos. Poderá não ter apenas um botão que zipa coisas. Você poderia por exemplo criar um serviço de backup automático que zipa e envia por email sem intervenção humana.
O encapsulamento é agrupar os dados e métodos por suas responsabilidades.
Interfaces
Uma interface é o conjunto de métodos que você pode executar em um determinado objeto. Se você quiser aprender melhor o termo ou simplesmente impressionar seus amigos, olha só as frases nas quais você poderia encaixar a palavra:
- “A interface do objeto X é muito confusa, os métodos não fazem sentido.”
- “Projetamos a interface desse objeto para ter apenas três métodos: abrir, fechar e salvar.”
- “Melhor usar uma interface parecida com o objeto Y, assim os programadores que já conhecem tal classe se sentirão em casa.”
A interface é o que vai definir se quem lê o seu código fonte vai te achar um trouxa ou um cara bacana. É por ela que as pessoas (incluindo você) vão reutilizar seu código, é a interface que será documentada, é ela que define se o fio vermelho ou o fio azul serão cortados e por aí vai.
mixmax
Encapsulamento e projeto de interface andam juntinhos e tem tudo a ver com definir bem as responsabilidades das classes de objetos. Dicas picantes:
- Evite classes com mais de uma responsabilidade (“minha classe conecta ao banco, trata HTML e xinga muito no twitter”).
- Não faça métodos canivete suíço (“esse método que tem 26 parâmetros faz qualquer coisa, os valores padrão são…”).
- Cuidado com as dependências escrotas (“O objeto que filtra HTML depende da conexão do banco de dados porque tem um método de limpar strings mó legal por lá”).
