Desconstruindo a Orientação a Objetos (ou esquecendo o que você aprendeu na escola) - Parte 1

Lembro-me como se fosse ontem (que poético isso) a primeira vez que eu ouvi sobre a orientação a objetos. Depois de muito tempo lidando com linguagens puramente procedurais (C, COBOL, Visual Basic), eu ouvi falar sobre esse novo paradigma e é claro, sobre uma das linguagens que usa ele, o Java. A primeira coisa que eu ouvi foi "a orientação a objetos é ótima para construir interfaces gráficas", e eu sei, que se você tem o mínimo de noção sobre o que é orientação a objetos, sabe que isso foi uma enorme canelada*.

Já na faculdade, eu tive aulas de orientação a objetos, iniciando com C++ e no final, em Java. Eu já tinha estudado por conta um pouco sobre orientação a objetos e vi como destacavam os mecanismos de herança, e até hoje muitas literaturas ainda dão a maior ênfase na herança. Porém uma aula que me fez ver como a orientação a objetos é poderosa foi sobre o polimorfismo e a capacidade de chamar métodos de maneira dinâmica durante a execução. E é claro, para não dizer que não falei das flores, aprendemos sobre o encapsulamento, o que era basicamente usar private no que queria esconder e public no que queria exibir.

Hoje, depois de muito tempo e um pouco de experiência, eu vi que aprendemos tudo ao contrário.

A orientação a objetos serve para muito mais do que o reaproveitamento de código. Hoje existem algumas literaturas (que vou indicar nas próximas partes) que dizem que a prioridade da orientação a objetos é a qualidade e legibilidade do nosso código, e os mecanismos de herança devem ser usados com muito cuidado.

Dentre a tríade de poderes da orientação a objetos (daqui para frente, apenas OO), a prioridade que devemos tratar deve ser contrária ao que costumamos aprender, devendo ser o encapsulamento tratado como prioridade, o polimorfismo e todo o seu dinamismo em segundo, e a herança usada apenas em momentos que realmente faz sentido uma classe ser filha de outra. Essa ordem permite que o software seja desenvolvido de maneira defensiva, ou seja, cada parte do seu código está protegida e fazendo apenas o que deve, seguindo diversos princípios que tornam fácil essa manutenção,diminuindo o acoplamento do código e a dependência entre módulos.

Reconsiderar o que já sabemos pode ser estranho, principalmente se você tem apenas o conhecimento da faculdade ou cursos como base, porém é necessário entender o que cada recurso prove para podermos assim trabalhar da maneira correta e menos desgastante. Nas próximas partes, vamos tratar assunto por assunto da OO, vendo através de exemplos como ter um código mais limpo, bonito e elegante.

*Na verdade, a orientação a objetos realmente facilita o tratamento de objetos gráficos, pois com ela fica mais simples definir propriedades e ações dos mesmos, criando uma ligação direta entre o código e os eventos dos objetos.