Programação orientada a objetos em um contexto histórico

Para entender o estado atual da POO, você deve conhecer um pouco da história da programação. Ninguém concebeu a POO da noite para o dia. Em vez disso, a POO é apenas outro estágio na evolução natural do desenvolvimento de software. Com o passar do tempo, se tornou mais fácil identificar as práticas que funcionam e as que comprovadamente falham. A POO combina práticas comprovadas e testadas o mais eficientemente possível.

Novo Termo OO é a abreviatura de orientado a objetos. OO é um termo geral que inclui qualquer estilo de desenvolvimento que seja baseado no conceito de ‘objeto’ — uma entidade que exibe características e comportamentos. Você pode aplicar uma estratégia orientada a objetos na programação, assim como na análise e no projeto.

Você também pode dizer que OO é um estado da mente, uma maneira de ver o mundo todo em termos de objetos.

Simplesmente, a OO contém tudo que pode ser denominado como orientado a objetos. Você vai ver o termo OO muitas vezes neste livro.

Precursores da POO

Atualmente, quando usa um computador, você tira proveito de 50 anos de refinamento. Antigamente, a programação era engenhosa: os programadores introduziam os programas diretamente na memória principal do computador, através de bancos de chaves (switches). Os programadores escreviam seus programas em linguagem binária. Tal programação em linguagem binária

era extremamente propensa a erros e a falta de estrutura tomou a manutenção do código praticamente impossível. Além disso, o código da linguagem binária não era muito acessível.

Quando os computadores se tomaram mais comuns, linguagens de nível mais alto e procedurais começaram a aparecer; a primeira foi FORTRAN. Entretanto, linguagens procedurais posteriores, como ALGOL, tiveram mais influência sobre a 00. As linguagens procedurais permitem ao programador reduzir um programa em procedimentos refinados para processar dados. Esses procedimentos refinados definem a estrutura global do programa. Chamadas seqüenciais a esses procedimentos geram a execução de um programa procedural. O programa termina quando acaba de chamar sua lista de procedimentos.

Esse paradigma apresentou diversas melhorias em relação à linguagem binária, incluindo a adição de uma estrutura de apoio: o procedimento. As funções menores não são apenas mais fáceis de entender, mas também são mais fáceis de depurar. Por outro lado, a programação procedural limita a reutilização de código. E, com muita freqüência, os programadores produziam código de espagueti — código cujo caminho de execução se assemelhava a uma tigela de espagueti. Finalmente, a natureza voltada aos dados da programação procedural causou alguns problemas próprios. Como os dados e o procedimento são separados, não existe nenhum encapsulamento dos dados. Isso exige que cada procedimento saiba como manipular corretamente os dados. Infelizmente, um procedimento com comportamento errôneo podería introduzir erros se não manipulasse os dados corretamente. Uma mudança na representação dos dados exigia alterações em cada lugar que acessasse os dados. Assim, mesmo uma pequena alteração podería levar a uma cascata de alterações, por todo o programa — em outras palavras, um pesadelo de manutenção.

A programação modular, com uma linguagem como Modula2, tenta melhorar algumas das deficiências encontradas na programação procedural. A programação modular divide os programas em vários componentes ou módulos constituintes. Ao contrário da programação procedural, que separa dados e procedimentos, os módulos combinam os dois. Um módulo consiste em dados e procedimentos para manipular esses dados. Quando outras partes do programa precisam usar um módulo, elas simplesmente exercitam a interface do módulo. Como os módulos ocultam todos os dados internos do restante do programa, é fácil introduzir a idéia de estado: um módulo contém informações de estado que podem mudar a qualquer momento.

Novo Termo O estado de um objeto é o significado combinado das variáveis internas do objeto.

Novo Termo Uma variável interna é um valor mantido dentro de um objeto.

Mas a programação modular sofre de duas deficiências próprias importantes. Os módulos não são extensíveis, significando que você não pode fazer alterações incrementais em um módulo sem abrir o código a força e fazer as alterações diretamente. Você também não pode basear um módulo em outro, a não ser através de delegação. E, embora um módulo possa definir um tipo, um módulo não pode compartilhar o tipo de outro módulo.

Nas linguagens modulares e procedurais, os dados estruturados e não estruturados têm um ‘tipo’. O tipo é mais facilmente pensado como o formato da memória para os dados. As linguagens fortemente tipadas exigem que cada objeto tenha um tipo específico e definido. Entretanto, os tipos não podem ser estendidos para criar outro tipo, exceto através de um estilo chamado ‘agregação’. Por exemplo, em C, podemos ter dois tipos de dados relacionados: typedef struct { int a; int b;

Nesse exemplo, aDeri vedType é baseado em aBaseType, mas uma estrutura de aDeri vedType não pode ser tratada diretamente como uma estrutura de aBaseType. Uma só pode fazer referência ao membro Base de uma estrutura aDeri vedType. Infelizmente, essa organização leva a código que possui muitos blocos case e if/else, pois o aplicativo deve saber como manipular cada módulo que encontra.

Finalmente, a programação modular também é um híbrido procedural que ainda divide um programa em vários procedimentos. Agora, em vez de atuar em dados brutos, esses procedimentos manipulam módulos. 

ATIVIDADE DE FIXAÇÃO