Antes de entendermos o que é, precisamos entender como, porque e para que surgiu.

Como

Foi aos poucos. Sempre que lemos textos sobre OO, vemos citações sobre smalltalk[ apesar de pelo menos eu, nunca ter visto uma linha de código nessa linguagem]. Continuamos as leituras e pesquisas, e vemos que outras linguagens, já adotavam alguns principios desse paradigma, algumas outras como C e php, lhe deixam programar tanto em OO, como apenas de forma estruturada, Java somente em OO…

Porque

‘Para aproximar o mundo real do mundo virtual’.

Resumido não ?

O difícil é enfiar isso na cabeça dos programadores de hoje em dia. É isso gente, pronto. Daqui é que derivam as outras coisas de OO, mas o porque é este.

Para que

Para principalmente ajudar a padronizar o desenvolvimento. Discordo das afirmações que dizem que todo código escrito com o paradigma de programação estruturada, é uma bagunça.. Existem programadores e caras que programam..

Para os CQPs, não importa se é orientado a objetos, a eventos, a qualquer outra coisa, vai ficar ruim e pronto. Eu diria até que um CQP fazendo OO, é tão ou mais perigoso do que ele fazendo estruturado.

Entendam por favor:

Para programar OO direito e corretamente, é necessário saber programar de forma estruturada !

[podem comentar, estou pronto para rebater todas as críticas que essa minha frase vai gerar.]

O que não é

OO não é Identação, isso já existia muito antes, e sempre devemos fazer, não importa o paradigma.

OO não é Reutilização, o conceito de function, já existia antes de OO. Okay, OO também provém reutilização, mas isso não é exclusivo desse paradigma.

É possível até conseguirmos um certo nível de poliformismo e herança usando apenas funções de linguagens estruturadas.

OO não é Organização, essa deve ser a obrigação de todo programador.

O que é

Na minha concepção, e com as minhas palavras, o paradigma de orientação a objetos, foi projetado para obrigar programadores diferentes que não se conhecem, e não possuem acesso total ao código um dos outros, a programarem de uma forma organizada, e conforme foi definido no projeto. Vai além do UML.

Para que uma equipe de vários programadores consigam trabalhar juntos, sem interferir, ou comprometer completamente o restante da aplicação com erros pontuais.

Um é capaz de servir funcionalidades e usar as de outro programador, sem conhecer como foram implementadas.

Basicamente, foi isso que os outros paradigmas não conseguiram resolver.

OO possui ferramentas, como Interfaces e Classes Abstratas, que fazem exatamente isso. Definem um padrão a ser seguido.

Foi aqui que ouvi uma crítica: “Ahh, mas se o cara quiser mesmo, ele não vai nem implementar a interface, e nem extender a abstract, e assim então vai conseguir programar da forma dele, fugindo do padrão”.

Só tenho uma resposta para isso: esse cara não deveria estar nessa profissão. Pronto.

O padrão tá alí, e o paradigma, oferece mecanismos muito bons, para auxiliar o desenvolvimento. Se o cara quer realmente fazer merda, então ele não deveria ser programador. Não é questão de ‘pressa’, pois já que seguindo o que está pronto, obteremos ganhos de produtividade, se a base tiver sido bem feita.

Códigos devem ser escritos para humanos

Todos já ouvimos essa frase. É exatamente isso que OO faz. Tem algo mais ‘humano’ e próximo de nós do que os objetos, que nos rodeiam ?

O que deve mudar para que consigamos trabalhar com OO, é a forma de pensar.

Precisamos modelar nossas classes, como objetos reais. Precisamos entender oque deve ou não pertencer a cada Entidade nossa. Numa tradução livre que fiz, no dia em que fui apresentado a este paradigma:

Um objeto possui qualidades(adjetivos mesmo!) e faz coisas. Estou olhando para uma lâmpada agora.

A minha lâmpada é:

-> branca [qualidade]

-> de 50w [qualidade]

-> pequena [qualidade]

-> cilindrica [qualidade]

A minha lâmpada pode:

-> ficar acessa [faz]

-> ficar apagada [faz]

-> queimar [faz]

.. e sei lá até onde o joguinho do pensar simples pode te levar.

As qualidades alí, são os atributos dos nossos objetos, e as coisas que ele faz, são os métodos dele. A minha lâmpada, precisa de um interruptor para funcionar, e esse interruptor, ao ser apertado pelo usuário, vai abrir ou fechar o circuito da rede elétrica.

abrirCircuito, e fecharCircuito são os métodos do meu objeto interruptor. A lâmpada não sabe como o interruptor vai fechar o circuito e fornecer corrente elétrica para ela ficar acessa, ela apenas sabe que se o interruptor fizer uma coisa, a lâmpada terá que fazer outra. O Interruptor, não sabe se a lâmpada tá queimada ou boa, ele vai enviar a informação mesmo assim. Lá na frente é que precisa disparar o Exception.

Dependendo da informação que ele enviar, a lâmpada ficará acesa ou apagada.

Isto é orientação a objetos. Um objeto conversando com o outro.

Okay, exemplo tosco, mas nem todo mundo enxerga isso. E vejo diariamente vários programadores, que não possuem esses conceitos incorporados a eles, e desembestam a escrever classes, achando que estão programando em OO.

Nunca pararam para pensar o porque da palavra orientação, no nome.

OO veio para ajudar, reforçando várias coisas que já existiam, e forçando-nos a sermos coerentes.

Isso é OO.