POO1 - Aula 2 - Apresentação e Contexto

Prévia do material em texto

1 
 
2 INTRODUÇÃO 
Abaixo serão apresentados diferentes paradigmas de programação, 
tem como objetivo apresentar diferentes técnicas existentes e identificar o 
contexto a ser estudado nesta disciplina. 
2.1 PROGRAMAÇÃO MODULAR 
Assim como ocorre quando precisamos solucionar um problema de 
Matemática ou Física, ao nos depararmos com situações de programação 
difíceis de serem resolvidas, a melhor opção é decompor o problema em 
porções menores, mais fáceis de trabalhar. Com isso dividimos a complexidade 
de forma a simplificar o problema. 
Cada parte em que o problema é dividido resulta em um fragmento de 
código que denominamos de módulo ou subprograma. Essa divisão de um 
programa maior em diversos subprogramas é uma técnica denominada de 
programação modular. 
Dividir o programa não se resume simplesmente em pegar todo o 
código e quebrá-lo em diversas partes indiscriminadamente. O processo 
envolve análise detalhada de cada função que o programa deve desempenhar. 
Muitas vezes pode ocorrer de, após o programa todo ter sido dividido, 
percebermos que um ou outro módulo ainda pode ser fragmentado, uma 
operação denominada de refinamento de código. 
Quando dividimos um programa em diversas partes, devemos nos 
preocupar em obter módulos que possuam um fraco acoplamento (pouca 
dependência um do outro) e uma forte coesão (dificuldade de separação de 
alguma parte do módulo). 
É importante ressaltar que os módulos precisam possuir uma 
"interface", composta de um único ponto de entrada e uma única saída, e a 
forma como essa interface trabalha não deve depender do resto do programa. 
Essa característica torna possível a construção de verdadeiras bibliotecas de 
módulos para uso geral. 
2 
 
Esses módulos podem ser compostos por arquivos de código-fonte 
completos ou rotinas (procedimentos e funções) que são executadas a partir de 
um módulo principal do programa. 
Não existe um método sistemático para efetuar essa modularização de 
código, mas duas técnicas podem ser empregadas. Na primeira, denominada 
Top-Down (de cima para baixo), um problema é analisado como um todo e 
depois de identificadas todas as partes que devem compô-lo, ele é quebrado 
em problemas menores. Em outras palavras, partimos de um conceito mais 
abrangente em busca de diversos conceitos que possuam um detalhamento 
mais refinado. 
A outra óptica é denominada Bottom-Up (de baixo para cima), que 
consiste num processo inverso, ou seja, parte-se de conceitos mais simples e 
detalhados que são agrupados para formar um conceito mais abrangente. 
A metodologia Top-Down é a mais indicada para obter programas mais 
concisos e maior produtividade. 
Independente da técnica escolhida, a modularização de um programa 
permite que seja possível criar módulos que podem ser utilizados em diversos 
programas. Cada módulo pode ser testado individualmente, tornando possível 
a detecção e correção de erros de forma mais rápida, pois eles são isolados e 
atribuídos a um determinado módulo. 
Mas também existem alguns problemas nessa abordagem. Entre eles 
podem ser mencionados a dificuldade em ligar os módulos que foram 
construídos por diferentes programadores; necessidade de uma documentação 
primorosa; necessidade de criar pequenos programas para efetuar os testes 
dos módulos, que implica em tempo extra. 
2.2 PROGRAMAÇÃO ESTRUTURADA 
A técnica de programação estruturada se fundamenta na construção de 
sistemas com a utilização de blocos como estruturas básicas, que podem ser 
expandidas até o nível de complexidade necessário à resolução de um 
determinado problema. Um bloco é formado por diversas instruções que são 
executadas em conjunto por estarem logicamente ligadas. Como exemplo, 
podemos citar um comando de decisão (como IF) que permite executar várias 
instruções caso uma determinada condição que está em teste seja verdadeira. 
3 
 
Essas estruturas permitem que sejam definidas sequências bastante 
claras das operações que o sistema deve executar. Desta forma, é possível 
diminuir a incidência de erros de programação e quando eles ocorrerem, 
podem ser facilmente detectados e corrigidos. Nessas estruturas são 
empregadas uma entrada e uma saída simples, que não permitem 
ambiguidades. 
 
O código final obtido pela programação estruturada é muito claro e de 
fácil entendimento, mesmo por outras pessoas que não sejam as que 
desenvolveram o código. 
Entre as principais vantagens da programação estruturada temos: 
 possibilidade de padronização devido ao número reduzido de 
estruturas; 
 as estruturas podem ser inseridas em módulos distintos; 
 programas estruturados geralmente já possuem uma 
autodocumentação interna; 
 aumento na produtividade dos programadores. 
E uma técnica em que o programador é forçado a ter uma disciplina 
que resulta em sistemas mais organizados. 
As linguagens Pascal e C são fortes exemplos de linguagens de 
programação estruturada. Elas trabalham com base no conceito de sub-rotinas 
com variáveis locais e possuem variadas formas de construção de laços de 
repetição. 
2.3 PROGRAMAÇÃO ORIENTADA POR OBJETO 
A técnica de programação orientada por objeto surgiu no final dos anos 
de 1970 e início de 1980, quando os pesquisadores do Centro de Pesquisas da 
Xerox, em Palo Alto, Califórnia, desenvolveram uma linguagem de 
programação chamada SmallTalk, que utilizava pela primeira vez o conceito de 
classes e objetos. 
A ideia básica por trás dessa técnica é a capacidade de reutilização de 
códigos já prontos, denominados classes, para criarmos as partes vitais do 
4 
 
programa, denominadas de objetos. Com isso é possível economizar um bom 
tempo no processo de desenvolvimento de um programa. 
Nesse tipo de programação, as linguagens empacotam as estruturas 
de dados e as rotinas que trabalham com elas numa única entidade. 
E costume utilizar como metáfora a ideia de uma linha de montagem de 
automóveis. Podemos imaginar uma classe como os componentes das 
diversas partes de um automóvel. O bloco e o cabeçote do motor seriam uma 
classe para o objeto motor. Esse motor (objeto) pode ter alguns atributos, como 
número de cilindros, potência, torque, tipo de combustível (álcool, gasolina, 
gás, diesel) etc. Ele, por outro lado, desempenha uma função útil, que é pôr o 
carro em movimento. A menos que você seja um engenheiro mecânico, não 
precisa saber detalhadamente o funcionamento do motor, apenas é preciso 
saber que, ao girar a chave de ignição, ele deve começar a funcionar. 
Todos os objetos juntos (motor, carroceria, portas, bancos, painel etc.) 
formam o automóvel como um todo. O próprio automóvel pode ainda ter seus 
próprios atributos, como cor, tipo de carroceria ou número de portas. 
Uma característica interessante da programação orientada por objetos 
é que podemos derivar um objeto de outro previamente criado. Em outras 
palavras, significa que podemos criar um objeto que herda alguns atributos e 
ações do antecessor. 
Você poderia, por exemplo, desenvolver uma rotina de uso genérico 
que é responsável pela criação de uma janela principal com menus na parte 
superior. Quando fosse necessário desenvolver outro aplicativo, você recorreria 
a essa rotina para criar sua tela principal, sem ter de escrever uma linha sequer 
novamente. Tudo de que se precisa é passar alguns parâmetros à rotina de 
construção do menu. 
Com essa técnica, cada objeto é autossuficiente, ou seja, é capaz de 
executar uma tarefa inteira sem precisar se preocupar com o resto do 
programa. 
Entre as principais linguagens de programação orientada por objetos 
temos C++, Object Pascal e Java. A ferramenta de projeto mais utilizada no 
desenvolvimentode aplicações que emprega essa metodologia é a UML 
(Unified Modeling Language -Linguagem de Modelagem Unificada). , 
5 
 
2.4 ELEMENTOS DA PSEUDOLINGUAGEM 
Vamos detalhar neste tópico como é a estrutura da pseudolinguagem 
que utilizaremos na construção dos algoritmos durante todo o estudo. Ela é 
baseada em duas linguagens do mundo real, Pascal e C/C+ + . Assim, quem já 
tem algum conhecimento de uma delas sentir-se-á familiarizado. Essa 
pseudolinguagem possui diversas palavras reservadas, similares a comandos e 
instruções das linguagens tradicionais. Para diferenciá-las de outros 
identificadores, como nome de variáveis ou de procedimentos e funções, essas 
palavras reservadas serão escritas com letras maiúsculas. É importante deixar 
claro que essa pseudolinguagem pode ser definida pelo próprio programador 
para uso em seus trabalhos, da forma que melhor atender suas necessidades. 
O que está sendo utilizado neste livro não deve ser entendido como um padrão 
de fato. 
Como vimos anteriormente, podemos dividir um complexo projeto de 
sistema em diversos módulos e depois agrupá-los através de um módulo 
principal, também denominado programa de controle, que é responsável pela 
chamada de cada um dos módulos. Em nossa pseudolinguagem temos a 
palavra reservada PROGRAMA para definir o módulo principal. Segue essa 
palavra reservada uma cadeia de caracteres que define o nome do programa 
propriamente dito. Veja um exemplo: 
 
PROGRAMA SistemaVendas; 
 
Cada linha que possui um comando ou instrução deve ser finalizada 
com ponto e vírgula, indicando com isso o fim de uma entidade lógica, o que 
permite que uma instrução inteira possa ser quebrada em mais de uma linha de 
código. 
O corpo do programa deve ser inserido entre as palavras reservadas 
INÍCIO e FIM, que delimitam um bloco de comandos/instruções responsáveis 
pelo processamento e/ou execução das operações desejadas. Veja o exemplo 
a seguir: 
6 
 
 
PROGRAMA SistemaVendas; 
INÍCIO 
FIM. 
 
Note que as linhas que contêm as palavras reservadas INÍCIO e FIM 
não terminam com ponto e vírgula por se tratar de uma definição de bloco, e 
não de um comando ou instrução que executa uma operação. A palavra 
reservada FIM seguida de um ponto final (FIM.) indica o fim do módulo inteiro 
ou programa principal. 
Já para módulos, que são arquivos-fonte definidos externamente ao 
programa principal, a estrutura é bastante similar, diferenciando-se apenas pelo 
fato de serem identificados pela palavra reservada UNIDADE, da seguinte 
forma: 
 
UNIDADE EntradaNotaFiscal; 
INÍCIO 
FIM. 
 
Para referenciar um módulo que possui rotinas a serem utilizadas no 
programa principal ou em outro módulo, vamos utilizar a palavra reservada 
USAR, seguida do nome do módulo/unidade. Se for necessário fazer referência 
a mais de um módulo, seus nomes devem ser separados por vírgula. Veja o 
exemplo 
 
PROGRAMA SistemaVendas; 
DSAR EmissaoNotaFiscal,ControleEstoque,EntradaNotaFiscal; 
INÍCIO 
FIM. 
 
 
7 
 
3 PROGRAMAÇÃO ORIENTADA A OBJETOS 
A programação de computadores com orientação a objetos não é 
recente. Sua divulgação ao público data do início da década de 1990. O 
conceito de Programação Orientada a Objetos ou POO (em inglês Object 
Oriented Programming - OOP) surgiu a partir de 1960. Nessa ocasião, já havia 
uma grande preocupação com a qualidade dos softwares desenvolvidos, com o 
reaproveitamento de código escrito e com o tempo de desenvolvimento dos 
sistemas, que começava a ser longo. 
O cenário para a área de software não era nada animador, pois a 
indústria de hardware estava muitos anos à frente. O modo de concepção dos 
programas era muito rústico (BUENO, 2002), pois um programa tinha de ser 
escrito para um computador em específico. Não existia a concepção de 
escrever um programa que pudesse ser executado em qualquer computador ou 
qualquer plataforma computacional. Essa concepção só apareceu muito tempo 
depois. 
A era da computação comercial inicia-se em 1950, quando os 
computadores deixaram de ser ferramentas meramente militares (como 
ocorreu na década de 1940). A única linguagem utilizada era a da máquina, 
formada por códigos binários. Com o tempo surgiu a linguagem Assembly, 
mais fácil do que a linguagem de máquina, pois permite uma proximidade 
maior com a linguagem humana, mas intimamente vinculada com os recursos 
da máquina, o que a torna de difícil compreensão. 
Um programa escrito em linguagem Assembly para um computador X 
não pode rodar em um computador Y. O mesmo programa necessita ser 
novamente escrito, segundo as regras do computador Y. O que, além de 
trabalhoso, é excessivamente dispendioso. Com as linguagens de máquina e a 
Assembly surge a primeira geração de linguagens de programação de 
computadores, que são de baixo nível. 
Por volta de 1954 até 1968, começam a surgir as primeiras linguagens 
de programação de computadores de alto nível (maior proximidade com a 
escrita humana, em inglês) e a primeira a ser lançada foi FORTRAN 
8 
 
(.FORmula TRANslator criada por John Backus para a IBM em 1954). Depois 
vieram o COBOL (COmmon Business Oriented Language criada pela almirante 
Gracy Murray Hopper para o Departamento de Defesa Norte-Americano em 
1959), ALGOL (ALGOrithmic Language criada por um comitê internacional 
formado pela Association for Computing Machinery e German Applied 
Mathematics and Mechanics em 1958) e BASIC (Beginner's All Purpose 
Symbolic Instruction Code criada por J. Kemeny and T. Kurtz em 1964), para 
citar as mais conhecidas, já que existem mais de 2.500 linguagens de 
programação catalogadas. Essas linguagens passaram a definir a segunda 
geração. 
Além de essas linguagens de programação serem mais próximas da 
escrita humana, elas possibilitaram maior portabilidade, pois já era possível 
escrever um programa para um computador X e utilizá-lo (com algumas 
modificações) em um computador Y. 
As linguagens de segunda geração, na sua maioria, são lineares, as 
quais identificam seus comandos com linhas numeradas. Esta característica 
dificulta a adoção de técnicas estruturadas de codificação de programa. Essas 
linguagens não proíbem o uso da técnica, apenas dificultam um pouco, o que 
leva programadores inexperientes a cometerem verdadeiros absurdos na 
codificação de seus programas. Devido a este e outros detalhes técnicos, 
começa a se discutir uma maneira de tentar reaproveitar um código escrito sem 
a necessidade de alterá-lo. 
Esta ideia inicial norteia o conceito de programação orientada a 
objetos, que surge a partir de 1960, com dois pesquisadores: Ole-Johan Dahl e 
Kristen Nygaard3, que apresentaram, em 1965, a primeira linguagem de 
programação orientada a objetos, chamada SIMULA I, para computador 
UNIVAC do The Norwegian Computing Center. Em 1967, apresentaram a 
linguagem SIMULA 67. 
Toda linguagem orientada a objeto é, por definição, uma linguagem de 
programação com forte suporte à programação estruturada de dados a serem 
manipulados. Surgem então as primeiras linguagens de programação 
pertencentes à terceira geração com uma estruturação maior que as 
linguagens de segunda geração, mas não davam inicialmente o suporte à 
programação orientada a objetos, que estava ainda engatinhando. 
9 
 
Entre 1968 e 1972, surgem as linguagens PASCAL e C (que não são 
orientadas a objetos, mas são estruturadas, logo são linguagens de terceira 
geração). Depois, com o tempo, vieram outras linguagens de programação, as 
quais já embutiam de alguma forma os conceitos de orientação a objeto, tais 
como SMALLTALK, EIFFEL, ADA, CLOS, SELF, BETA, OBJECT PASCAL 
(linguagem PASCALorientada a objetos), C++ (linguagem C orientada a 
objetos), entre outros exemplares, muitos dos quais ainda desconhecidos por 
boa parte do público profissional da área de TI (Tecnologia da Informação), que 
não cabe listar neste estudo, e que surgiram a partir de 1980. 
Nota-se, pelo exposto, que a programação orientada a objetos passou 
por um crescimento de 30 anos antes de começar a ser aceita com maior 
intensidade a partir de 1990, quando passou a ser conhecida por uma pequena 
parcela de profissionais e muito requisitada a partir do início do século XXI. No 
entanto, existe ainda muita dúvida sobre a sua utilização e a forma mais 
adequada de implementá-la. 
Atualmente existem diversas linguagens de programação orientadas a 
objetos (como é o caso da linguagem de programação C++) que já rodam em 
várias plataformas, graças aos esforços de padronização de entidades como 
ANSI, ISO e IEC. Já é possível utilizar plenamente o reaproveitamento de 
código (uma das bases da orientação a objetos). Um programa pode facilmente 
ser escrito em um computador X e ser utilizado em um computador Y, com 
praticamente nenhuma alteração, ou quando houver necessidade de 
implementar alguma alteração, que seja muito pequena. Perceba que este 
conceito proporciona aumento de produtividade para a área de 
desenvolvimento de software. 
No entanto, não basta apenas existir o conceito, as ferramentas e a 
vontade para a implementação de sistemas baseados em orientação a objetos. 
É necessário que os desenvolvedores também pensem, que também possuam 
uma lógica de programação orientada a objeto. E preciso reciclar a forma de 
programar e desenvolver, mudar por completo a atitude profissional de 
trabalho. Caso contrário, estar-se-á dando uma bazuca para um desenvolvedor 
matar mosquitos, como infelizmente ocorre com alguma frequência. 
10 
 
3.1 PRINCÍPIOS FILOSÓFICOS 
Programação orientada a objetos é um conceito abstrato, o que 
dificulta um pouco o seu entendimento inicial por grande parte das pessoas. 
Mas a partir do momento em que se entende este conceito, é como apontar um 
refletor para um canto de quarto em penumbra. Tudo fica mais claro. Torna-se 
possível ver coisas que lá existem, mas que estavam ocultas, e então todo o 
conceito se torna trivial. 
A programação orientada a objetos é uma filosofia de trabalho. Não é a 
ferramenta em si, mas a forma de pensar, a forma de usar a lógica de 
programação para a solução computacional de um problema do mundo real. 
Assim sendo, é necessário ao desenvolvedor mudar a sua forma de pensar a 
respeito de um problema computacional. É necessário utilizar a estrutura de 
dados de um programa, baseada no mundo real, e não apenas nos modelos 
computacionais. 
Os primeiros programadores pensavam de forma linear, depois 
aprenderam a pensar de forma estruturada; surgiram as linguagens de 
programação de computadores que deram suporte a essa filosofia de trabalho. 
A partir do início do século XXI torna-se necessário aprender a levar o conceito 
de estruturação de programas para um nível mais abstrato do que vinha sendo 
utilizado. E necessário utilizar conceitos do mundo real para o tratamento dos 
dados que um programa irá processar, e deixar de lado os conceitos 
computacionais tão explorados no passado, mas que se mostram por muitas 
vezes ineficientes. A orientação a objetos é voltada à funcionalidade dos dados 
com base natural dos elementos existentes no mundo real. 
Ao adotar a programação orientada a objetos, deve ser utilizada em 
todas as fases do projeto de desenvolvimento do software. Desde a fase de 
análise até a codificação da última linha de programa. A parte mais delicada 
desse processo é fazer com que analistas e programadores utilizem os 
procedimentos de documentação de sistemas, há muito desprezados. E 
comum ouvir dizer que não é necessário documentar o sistema, pois gasta-se 
tempo com a documentação. Rotinas de trabalho, como levantamento de 
necessidades, projeto físico e projeto lógico, são simplesmente descartadas 
por aqueles que se dizem "profissionais". Para trabalhar com orientação a 
11 
 
objetos, essa atitude necessita ser mudada; caso contrário, é melhor 
permanecer como está, deixar a vaca ir para o brejo e morrer afogada, pois 
será certeza de insucesso. 
A programação orientada a objetos é por si só extremamente abstrata, 
por esta razão necessita fazer uso intenso de ferramentas gráficas (diagramas) 
para representar os objetos e seus elementos de trabalho. Assim sendo, a 
orientação a objetos possui uma forma de notação gráfica peculiar, que deve 
ser plenamente utilizada. 
Um dos métodos de representação gráfica de objetos é denominado 
CRC (Colaboração de Responsabilidade de Classe - Class Responsibility 
Collaborator), o qual utiliza fichas de cartolina para representar os objetos. 
Essa forma de estruturação de objetos é de fácil utilização e compreensão e 
pode ser desenhada sem grandes problemas (WIRFS-BROCK, et al., 1990). 
Outro método de representação gráfica é a linguagem de modelagem 
unificada, conhecida pela sigla UML (Unified Modeling Language), proposta por 
três estudiosos da área de TI: Booch, Rumbaugh e Jacobson, que unificaram 
seus métodos de trabalho e formaram o modelo UML (FURLAN, 1998). 
Na aplicação prática de um sistema baseado na filosofia de orientação 
a objetos não importa o modelo adotado. O importante é ter um modelo para a 
representação gráfica dos objetos que serão utilizados, pois a criação e a 
utilização de orientação a objetos são muito amplas. Imagine que é possível 
desenvolver um modelo de objeto para uma aplicação, e esse mesmo modelo 
pode ser utilizado por outro desenvolvedor em outro local do mundo, sem 
sofrer nenhuma modificação. Segundo Furlan (1998), a tecnologia de 
orientação a objetos proporciona "modularidade de seus elementos, podendo 
tomar um subconjunto existente e integrá-lo de uma maneira diferente em outra 
parte do sistema". Fica a questão, como esse outro desenvolvedor ou você 
mesmo vai saber como usar o objeto que desenvolveu em outro momento, se 
não existir a documentação adequada? 
3.2 A ESSÊNCIA BÁSICA DA POO 
Em sua obra, Ambler (1997) faz uma importante advertência quando 
menciona que "os conceitos de orientação a objetos parecem muito simples, 
mas ninguém deve se deixar iludir por esta aparência". E necessário tomar 
12 
 
muito cuidado para não fazer do seu sistema uma verdadeira panaceia, pois os 
programas desenvolvidos com base nesta filosofia utilizam objetos, que são 
invólucros que armazenam tipos específicos de informações e também 
operações específicas são realizadas com essas informações (JANSA, 1995). 
A orientação a objetos é um trabalho muito bem definido por seus 
idealizadores. É sabido que para manter um teto erguido são necessários, em 
média, quatro pilares mestres. A orientação a objetos é fundamentada nessa 
estrutura, pois possui quatro pilares mestres, que são: classe, objeto, atributo e 
método, os quais serão rapidamente expostos em seguida, juntamente com 
diversos conceitos que norteiam seu uso.