Todas a linguagens de programação provêem abstrações. Pode-se argumentar que a complexidade dos problemas passíveis de solução está diretamente ligada ao tipo e à qualidade da abstração. Por “tipo” quero dizer, “O que é que você está abstraindo?”. A linguagem assembly é uma pequena abstração da máquina que a suporta. Muitas das chamadas linguagens “imperativas” que a seguiram (tais como FORTRAN, BASIC, e C) eram abstrações da linguagem assembly. Estas linguagens são melhorias consideráveis em relação à linguagem assembly, mas sua abstração primária ainda requer que se pense em termos da estrutura do computador em vez da estrutura do problema que se tenta resolver. O programador precisa estabelecer a associação entre o modelo da máquina (no “espaço de soluções,” que é onde se modela o problema, no caso um computador) e o modelo do problema que está efetivamente sendo resolvido (no “espaço de problemas,” que é onde o problema existe). O esforço requerido para realizar este mapeamento, e o fato de ele ser extrínseco à linguagem de programação, produz programas difíceis de escrever e caros para manter, e como efeito colateral criou toda a indústria dos “métodos de programação”.
A alternativa à modelagem da máquina é modelar o problema. Linguagens antigas, como LISP e APL, escolheram visões particulares do mundo (“Todos os problemas são, no final das contas, listas” ou“Todos os problemas são algoritmicos,” respectivamente). PROLOG transforma todos os problemas em cadeias de decisões. Algumas linguagens foram criadas para programação baseada em restrições, outras para programação exclusivamente através da manipulação de símbolos gráficos. (A segunda provadamente restritiva demais.) Cada uma dessas estratégias apresenta uma boa solução para a classe de problemas para a qual são projetadas, mas quando se pisa fora desse domínio, elas ficam complicadas e ineficazes.
A estratégia da orientação a objetos vai um passo adiante, provendo ferramentas para o programador representar elementos no espaço de problemas. Esta representação é geral o suficiente de forma que o programador não fique restrito a nenhum tipo particular de problema. Referimo-nos aos elementos no espaço de problemas e às suas representações no espaço de soluções como “objetos.” (Você também precisará de outros objetos que não têm análogos no espaço de problemas.) A idéia é que o programa pode se adaptar à linguagem do problema adicionando-se novos tipos de objetos, de forma que, quando se lê o código descrevendo a solução, lê-se palavras que também expressam o problema. Essa é uma abstração de linguagem mais flexível e poderosa do que o que tivemos antes.[2]Assim, a POO permite que se descreva o problema em termos do problema, em vez de fazê-lo em termos do computador onde a solução rodará. Mas ainda há uma conexão com o computador: cada objeto parece um pouco com um pequeno computador—ele tem um estado, e tem operações que se pode pedi-lo para realizar. No entanto, isto não parece uma analogia assim tão ruim a objetos no mundo real—eles têm características e comportamentos.
Alan Kay resumiu as cinco características básicas do Smalltalk, a primeira líguagem orientada a objeto de sucesso e uma das línguagens no qual o Java foi baseado. Estas características representam a pura aproximação a programação orientada a objeto : Comentários (em inglês)
1- Tudo é um objeto. Pense num objeto como uma variável imaginária; este armazena dados, mas você pode fazer requisições para o objeto, requisitando a ela para efetuar operações em si mesmo. Em teoria, você pode se apropriar de qualquer componente conceitual do problema que você esta tentando resolver (cachorros, predios, serviços, etc.) e representar este como um objeto em seu programa.
2- Um programa é um conjunto de objetos que se comunicam entre eles através da emissão de mensagens. Para fazer a requisição a um objeto, você envia uma mensagem para aquele objeto. Mais concretamente, você pode pensar numa mensagem como a requisição de uma chamada a um método que pertence a um objeto em particular.
3- Cada objeto é composto por outros objetos. De outro ponto de vista, você cria um novo tipo de objeto fazendo um pacote contendo objetos já existentes. Assim, você pode construir uma complexidade num programa enquanto esconde esta através da simplicidade dos objetos.
4- Cada objeto tem um tipo. Usando o jargão, cada objeto é uma instância de uma classe, em que “classe” é o sinônimo de “tipo”. A mais distinta característica de uma classe é “Que tipo de mensagens você pode enviar para ela?”
5- Todos os objetos de um tipo em particular podem receber as mesmas mensagens. Este é atualmente a indicador carregado, como você irá ver mais tarde. Por isto um objeto do tipo “círculo” é também um objeto do tipo “figura”, um círculo garante a aceitar as mensagens da figura. Isto significa que você pode escrever código que fala para a figura e automaticamente interpretar qualquer coisa que se comporte na descrição da figura. Esta substituição é um dos conceitos mais poderosos da POO.
Trecho retirado de "Thinking in Java, 3rd ed. Revision 4.0" de Bruce Eckel
Nenhum comentário:
Postar um comentário