1 - O Paradigma da Programao por Objectos

1.1 Introduo
Robert Floyd, um dos grandes cientistas da computao, recebeu em 1979 o ACM Turing Award, tendo ento proferido uma palestra intitulada Os Paradigmas de Programao, na qual paradigmas de programao so definidos como modelos e abordagens que permitem conceptualizar o que se deve entender por computaes, bem como devem ser estruturadas e organizadas as tarefas que se pretendem ver realizadas por um computador. Contrariamente ao que muitos pensam, o paradigma da Programao Por Objectos (PPO) ou Programao Orientada aos Objectos, as duas tradues mais comuns da expresso em lngua inglesa object-oriented programming, no um paradigma de programao nascido nos anos 90, sendo na verdade dcadas mais antigo. Este paradigma, que serve de base s tecnologias de objectos hoje em dia usadas em praticamente todas as reas da Informtica, tem na sua gnese um conjunto de desenvolvimentos realizados ao longo de muitos anos em reas do conhecimento bastante distintas, designadamente, a Simulao e a Engenharia de Software. Pela via da Simulao, a maioria dos conceitos fundamentais do paradigma da PPO surge nos anos 60. Pela via da Engenharia de Software, surgem nos anos 70 as primeiras implementaes de relevo tendo por base tal paradigma, ainda que, por vrias razes, apenas nos anos 90 tenham de facto tido impacto tecnolgico. No entanto, curiosamente, alguns dos conceitos fundamentais do paradigma dos objectos remontam filosofia grega, em particular a Scrates e ao seu discpulo Plato, nos sculos V e IV a.C., a propsito da forma ideal de realizar a catalogao ou classificao do conhecimento, j ento visto como podendo ser dividido em ideias individuais e em classes de ideias. Estas duas correntes deram tambm origem, no incio, a linguagens de PPO baseadas em modelos diferentes, tal como se ir referir mais adiante.

1.1.1 A via da simulao

De facto, a primeira linguagem a ser desenvolvida tendo por base a maior parte dos conceitos que iremos posteriormente estudar, e que so os conceitos principais que caracterizam e tornam diferente este paradigma de todos os outros, surgiu no final dos anos 60, foi desenvolvida por Dahl em Oslo e designava-se SIMULA67. Como o prprio nome indicia, a linguagem destinava-se a ser no propriamente uma linguagem de programao, mas antes uma linguagem na qual pudessem ser desenvolvidos modelos do mundo real e sobre estes executadas simulaes. O problema a resolver nesta rea consiste em encontrar formas simples de representar (modelizar) em computador, para mais fcil estudo, entidades do mundo real cujo comportamento se pretende analisar, sendo reconhecido que tais entidades possuem atributos caracterizadores muito prprios, isto , valores associados a propriedades que representam a sua estrutura interna. As entidades do mundo real so, neste contexto da simulao, consideradas modelveis, desde que sobre as mesmas se possuam as seguintes informaes:
O Paradigma
1

JAVA5 E PROGRAMAO POR OBJECTOS (F. MRIO MARTINS 2006)

Identidade (nica); Estrutura (via atributos, ou seja, as propriedades estticas); Comportamento (as aces e reaces respectivas); Interaco (forma de relacionamento com outras entidades). A estas entidades abstractas, modelos de entidades reais atravs de um processo de abstraco (simplificao), caracterizadas pela informao anteriormente indicada, a linguagem SIMULA-67 deu o nome de objectos. Dada a necessidade de modelar por vezes inmeros objectos diferindo apenas na sua identidade, mas que em tudo o resto possuam caractersticas iguais, por exemplo, pontos no plano 2D, logo, todos com coordenadas X e Y e com iguais comportamentos (por exemplo todos podem ser incrementados ou decrementados em X e Y), SIMULA-67 introduz a noo de classe como entidade definidora e geradora de todos os indivduos que obedecem a um dado padro comum de estrutura e comportamento. Seguindo o exemplo, teramos ento que definir uma Classe Ponto2D, a partir da qual todos os pontos individuais poderiam ser criados, s desta forma podendo haver a garantia de que todos possuem a mesma estrutura e comportamento, ainda que, naturalmente, possuindo valores diferentes nos seus atributos, para alm de terem, naturalmente, diferentes identificadores. Os objectos assim definidos em SIMULA-67 eram considerados, do ponto de vista da simulao, como entidades reactivas, ou seja, entidades capazes de responder a solicitaes exteriores realizando operaes sobre o seu estado interno, e enviando uma resposta entidade solicitadora. As classes funcionavam como fbricas de . Sendo programas em computador simulaes digitais quer de modelos conceptuais quer de modelos fsicos, os resultados obtidos na rea da Simulao usando tal abordagem foram sempre de grande interesse para a Engenharia de Software.

1.1.2 A via da engenharia de software

Nos anos 60 e 70, a Engenharia de Software havia adoptado um conjunto de princpios relativos ao processo de desenvolvimento de aplicaes e construo de linguagens, genericamente designados como anlise e programao estruturadas e procedimentais. A ideia geral consistia em considerar-se que, quer nas tarefas de anlise quer nas tarefas de programao, as entidades de interesse deveriam ser inicialmente pouco definidas, sendo quer estrutural quer funcionalmente pouco concretas, por forma controlar-se a sua intrnseca complexidade. Em seguida, em passos sucessivos, cada um destes nveis de abstraco funcional, ou seja, de processos (na anlise) ou instrues (na programao), era individual e separadamente refinado at se atingir o limite do seu detalhe. Porm, sempre com a mxima ateno focada na componente funcional, ou seja, processos, procedimentos e instrues. Os dados acompanhavam o processo de refinamento quase que por simpatia, sendo claramente entidades de segundo plano. O processo era designado por Anlise Estruturada ou Programao Estruturada, conforme a fase do desenvolvimento e o produto final pretendido, tratando-se de facto de um processo em rvore de desenvolvimento de cima (nvel mais abstracto) para baixo (nvel mais concreto), por isso por muitos designado por metodologia top-down (Figura 1.1). Este modelo estruturado funcional e top-down, em que as aces representavam as entidades computacionais de 1 classe e os dados as entidades computacionais de 2, quer pelas suas virtudes quer pelas suas ineficincias, um modelo muito importante dado que esteve na base de todos os grandes desenvolvimentos na rea da Engenharia de Software dos ltimos 35 anos, e tambm porque foi com base no mesmo que a Informtica foi mundialmente sendo realizada nas organizaes mais diversas.

O Paradigma

O PARADIGMA DA PROGRAMAO POR OBJECTOS

Nvel 1

Nvel 2

Nvel 3

Figura 1.1 Refinamento progressivo dos processos

Como prova fundamental desta tendncia orientada s instrues e aos algoritmos, Niklaus Wirth, que em 1971 havia concebido a linguagem PASCAL desenvolvendo ideias inovadoras apresentadas na linguagem ALGOL de 1968, entre elas a necessidade de os dados serem rigorosamente associados a tipos verificveis pelo compilador, usa, em 1975, a linguagem PASCAL para apresentar, em obra de programao clebre de igual nome, a frmula em tal momento fundamental: Algoritmos + Estruturas de Dados = Programas. Notese que os Algoritmos vm primeiro e em segundo lugar surgem as Estruturas de Dados. Note-se ainda que a semntica do + nunca foi ento claramente definida, ou seja, como deveria ser realizada estruturadamente a juno entre algoritmos e dados. Mas o mais importante a realar o facto de que instrues e dados foram durante muitos anos vistos como entidades importantes, mas com tratamentos separados. Estes princpios serviram igualmente de guio ao desenvolvimento das principais linguagens ento largamente utilizadas, designadamente, o Basic, o Fortran e o Cobol, linguagens caracterizadas por possurem um conjunto de instrues com poucas formas de estruturao do controlo da execuo, o que causava muita dificuldade de leitura e compreenso do cdigo dos programas. Alm disso, os programas eram muito inseguros por no existir qualquer verificao esttica de tipos (static type checking). De facto, ao contrrio do que se verifica actualmente com linguagens mais modernas, como PASCAL, MODULA, C, C++, JAVA, etc., muitas variveis no eram declaradas, isto , associadas a tipos de dados. No o sendo, o compilador no poderia realizar uma verificao esttica de tipos, isto , verificar em tempo de compilao e no em tempo de execuo se todas as variveis estavam a ser bem usadas, no sentido de lhes serem associados os valores compatveis com o seu tipo. As primeiras tentativas de melhoria destas linguagens de programao surgiram naturalmente medida que os projectos de software se iam tornando de maior dimenso, onde passou a ser inaceitvel, at pelos custos envolvidos, que todo o projecto de software tivesse que comear sempre do zero, ou seja, que nada do que havia sido feito em projectos anteriores pudesse ser reaproveitado. Surge assim a noo muito importante de reutilizao de software, ou seja, de garantir que qualquer programador deveria desenvolver cdigo posteriormente reutilizvel noutros projectos. Porm, nos anos 70, a nica soluo prtica existente para garantir tal possibilidade, dada a inexistncia de construes nas linguagens de programao que auxiliassem a tal objectivo, consistia em instruir e solicitar aos programadores que documentassem de forma clara o seu cdigo, usando o que as linguagens de ento aceitavam para documentao dos programas. Sentindo que o seu poder poderia estar em jogo nas organizaes, os programadores adoptaram a prtica contrria, ou seja, ou no documentavam programas ou os documentavam de forma dbia, de forma a garantirem que as organizaes, do ponto de vista informtico, deles continuavam dependentes. O constante aumento da complexidade dos problemas a resolver, entretanto sentida por todos os envolvidos em Informtica, conduziu necessidade de criao de mecanismos de abstraco capazes de facilitar as tarefas quer de anlise quer de programao, ainda que sob um ponto de vista procedimental, ou seja, procurando sempre responder questo de como especificar a funcionalidade das aplicaes de forma a que a mesma ou partes delas possam ser to claras que possam ser facilmente corrigida (erros), mantida (mudanas de requisitos) e reutilizada (noutras aplicaes). Este tem sido o grande e final desiderato da Engenharia de Software. As linguagens de programao, ou seja, as tecnologias de base da programao, acabaram por mais tarde dar
O Paradigma
3

JAVA5 E PROGRAMAO POR OBJECTOS (F. MRIO MARTINS 2006)

resposta a algumas exigncias, no apenas desenvolvendo esquemas de controlo da execuo dos programas muito mais compreensveis, tais como as estruturas for, repeat, while e case, como tambm diferentes mecanismos de abstraco de controlo (ou de instrues), tais como as subrotinas (subroutines), as funes (functions) e tambm os procedimentos (procedures). Estes primeiros mecanismos de abstraco de controlo implementam uma forma simples de reutilizao de software, ao permitirem que um bloco de instrues seja escrito independentemente do programa principal, tendo a si associado um identificador nico, pelo qual tal conjunto passa a ser referido (ou invocado). Em geral, este bloco de instrues relativamente genrico, pois aceita parmetros de entrada sobre os valores dos quais as instrues so executadas, sendo produzidos resultados que so comunicados para o exterior. A estrutura de um programa deixa assim de ser monoltica, passando cada vez mais a ser composta por um programa principal e por um conjunto de procedimentos e funes por este utilizveis atravs de mecanismos simples de invocao.
array[int] MaxListaInt int

10 -2

0 11 5

11

MaxListaInt

Figura 1.2 Abstraco de controlo ou procedimental

A abstraco de controlo associada aos procedimentos ou funes resulta do facto de que, tal como se pretende ilustrar na Figura 1.2, para que os mesmos sejam utilizados no necessrio que se conhea o seu interior (o seu cdigo), mas apenas a sua forma correcta de invocao e o resultado por este eventualmente devolvido. Ou seja, os procedimentos so vistos como black boxes, cujo interior desconhecido, o que no impede a sua utilizao desde que se compreendam as relaes das entradas com as sadas, ou seja, a transformao realizada. Por exemplo, uma simples funo Maior, que dados dois valores de entrada de um dado tipo d como resultado o maior dos valores parmetro, teria que ter tantas diferentes verses quantos os possveis tipos de dados simples dos seus parmetros de entrada. A soluo seria criar uma funo de nome diferente para cada caso, como MaiorInt, MaiorReal ou MaiorFloat, o que, como se compreende, se tornava pouco eficaz. Qualquer outra soluo mais inteligente teria que ser completamente programada. Por outro lado, ao ser definido pelo programador um novo tipo de dados, havia que ter em ateno que, a menos que o programador definisse igualmente um conjunto de procedimentos e funes que implementassem as operaes que com tal tipo de dados se pretendiam realizar, por exemplo, operaes bsicas, tais como a igualdade de valores do tipo, a comparao entre valores do tipo e outras, muito pouco se poderia fazer com os valores de tal tipo. Por exemplo, se o programador necessitasse de desenvolver uma Stack de inteiros, no s deveria criar uma representao da stack, por exemplo usando um array de inteiros, como tambm programar os procedimentos de criao, pop, push, etc.. Se tal no fosse feito, a stack teria uma representao mas no poderia ser manipulvel. De facto, e de um ponto de vista matemtico, definir um tipo de dados com sendo apenas um conjunto de valores que variveis de tal tipo podem assumir redutor, dado que associa um tipo a um conjunto matemtico. Definir um tipo de dados como tal conjunto de valores, bem como todas as operaes que sobre o mesmo se podem realizar, associa um tipo de dados a uma lgebra, noo matemtica muito diferente da noo de conjunto. Esta distino definicional trouxe s Cincias da Computao conceitos novos, sendo a noo de Abstract Data Type ou Tipo Abstracto de Dados (TAD) uma das mais importantes, at porque, como veremos adiante, se liga directamente com algumas caractersticas da PPO. No foi ainda este o passo
4

O Paradigma

O PARADIGMA DA PROGRAMAO POR OBJECTOS

seguinte. Cronologicamente, o passo seguinte das linguagens, ainda no sentido de melhorar os mecanismos de abstraco de controlo, foi o aparecimento em algumas delas, por exemplo, em UCSD PASCAL, MODULA, PL/1, etc., de unidades de computao designadas por mdulos. Os mdulos continham declaraes de dados e declaraes de diversos procedimentos e funes que podiam ser invocados do exterior, mas possuam a importante propriedade de poderem ser compilados isoladamente e posteriormente poderem ser ligados a qualquer programa que deles necessitasse. A abstraco continuava, portanto, a ser de controlo ou de funcionalidade, mas os mdulos facilitavam largamente a to desejvel reutilizao de cdigo, ainda que, em geral, via importaes completas dos mesmos. Com este mecanismo, a maior parte das linguagens passou a ser fornecida com um enorme conjunto de mdulos guardados em bibliotecas, que auxiliavam muito os programadores, j que, no sendo necessrio conhecer o seu cdigo, ofereciam uma funcionalidade, por vezes, de grande utilidade. Na Figura 1.3 apresenta-se um exemplo tpico de um mdulo que oferece funcionalidades relacionadas com clculos matemticos.
MDULO MATH; real sqrt(real x) real sin(real x) real cos(real x) real exp(real x) real random() int round(real x)

Figura 1.3 Mdulo como abstraco procedimental

Device drivers, mdulos de gesto de ficheiros, mdulos de tratamento de strings, etc., passaram a ser as novas black boxes da programao, desta vez porm com a evidente vantagem de serem facilmente reutilizveis por serem unidades de compilao em separado. No entanto, e para alm dos anteriormente referidos problemas relacionados com a falta de generalidade dos procedimentos e funes por serem tipados, tal como mais uma vez pode ser visto no mdulo MATH, o outro problema que conduziu falncia relativa deste modelo, que j permitia uma programao modular, mas ainda orientada s instrues, que a utilizao dos dados continuava a ser descurada, por continuar a ser considerado um problema de segunda ordem de importncia. Em resultado, os dados definidos num dado mdulo poderiam ser acessveis a vrios outros mdulos, como a Figura 1.4 procura ilustrar, ou seja, os procedimentos de um dado mdulo poderiam ter acesso s estruturas de dados de outros mdulos utilizados pelo programa. Porm, admitindo tais acessos, um grave problema surge ento. Se o objectivo dos mdulos encontrarmos unidades de programao que sejam independentes e reutilizveis em qualquer contexto, isto , em diferentes programas, ento, tais mdulos deveriam ser construdos em completa independncia de todos os outros, ou seja, sendo completamente autnomos e, portanto, no devendo construir a sua funcionalidade custa do acesso directo s variveis de outros mdulos, apenas realizando computaes que utilizam unicamente o seu estado interno.

O Paradigma

JAVA5 E PROGRAMAO POR OBJECTOS (F. MRIO MARTINS 2006)

Mdulo A Mdulo B Mdulo C

Dados

Dados

Dados

Figura 1.4 Mdulos interdependentes

De facto, se um mdulo A depende das variveis de um mdulo B e, por sua vez, B depende de outros mdulos (ver Figura 1.4), ento, onde quer que se necessite de A, o mdulo B e todos os de que B depende, e assim sucessivamente de forma transitiva, teriam que ser importados tambm para que A pudesse ser compilado e usado. A complexidade de controlar todas estas dependncias em situaes usuais de erro ou de simples manuteno seria para o programador uma tarefa de grande complexidade. Assim, a nica forma de se garantir que um mdulo completamente independente do contexto, ou seja, utilizvel em qualquer programa, ser torn-lo independente de todo e qualquer outro mdulo, ou seja, tornlo absolutamente autnomo. Para tal haver que garantir que os seus procedimentos apenas acedem s variveis que so locais ao mdulo e, adicionalmente, o que muito relevante, que no cdigo dos procedimentos no existem instrues de input/output.

1.2

Abstraco de dados e data hiding

Com base em tais requisitos, os mdulos passam a ser vistos como definindo uma estrutura de dados interna e contendo um conjunto de procedimentos e funes que devem ser o nico cdigo com acesso s suas variveis internas, sendo igualmente de garantir que tais funes e procedimentos no acedem a quaisquer outras variveis que no faam parte dos dados locais do mdulo (Figura 1.5). Deste modo, a entidade fundamental de um mdulo, que passa a estar protegida e escondida (da a expresso data hiding) e que, idealmente, deve ser inacessvel do exterior, a estrutura de dados local ao mdulo. Os procedimentos e funes passam a representar o papel de servios disponibilizados pelo mdulo para que do exterior se possa aceder estrutura de dados. Assim sendo, os mdulos passam a ser vistos, finalmente, como mecanismos de abstraco de dados e no de abstraco de controlo. A Figura 1.5 representa este tipo de modularidade baseada em mecanismos de abstraco de dados.
Mdulo A Dados de A

Figura 1.5 Mdulo independente do contexto

Se todos os mdulos forem programados tendo por base estes princpios, o que apenas depender dos programadores dado que, em geral, as linguagens no fazem qualquer tipo de verificao e validao destas
6

O Paradigma

O PARADIGMA DA PROGRAMAO POR OBJECTOS

regras, ento, os mdulos passam a ser no s unidades de programao completamente autnomas, portanto de facto independentes do contexto onde vo ser usados e assim sempre reutilizveis, como ainda passam a poder ser vistos como cpsulas, no sentido em que escondem do exterior detalhes de implementao, quer de dados quer de procedimentos, com benefcios para ambas as partes. A Figura 1.6 ilustra o encapsulamento dos dados, tornados privados e apenas acessveis aos mtodos programados no interior do mdulo, dos quais alguns sero invocveis do exterior.
Mdulo = Abstraco de Dados Mdulo = Interface + Implementao
I N T E R F A C E ou A P I

Estrutura de Dados Privada

IMPLEMENTAO

Figura 1.6 Mdulo como Abstraco de Dados

O acesso do exterior funcionalidade do mdulo garantida, dado que o mdulo declara como pblicos, isto , invocveis do seu exterior, um conjunto de procedimentos e funes. A este conjunto de procedimentos e funes invocveis do exterior de um mdulo d-se em geral o nome de interface, ou at de API, do ingls application programmers interface. Estes devero ser, de facto, dentro deste conjunto de regras que temos procurado estabelecer com vista obteno de objectivos muito importantes no mbito da programao, os nicos mecanismos de acesso exterior ao mdulo. Assim, um mdulo passa a ser uma abstraco de dados que se pode dividir em duas camadas distintas: uma interface e uma implementao (Figura 1.6). Esta viso de um mdulo de software como sendo uma cpsula, ou seja, uma entidade apenas acessvel do exterior pelo que de si define como sendo de uso pblico, ou seja, os procedimentos que fazem parte da sua interface, necessita agora de ser analisada com base em exemplos concretos, para que melhor se compreendam tais vantagens. Vejamos um exemplo: consideremos o mdulo seguinte programado numa linguagem fictcia semelhante a PASCAL.
MODULE COMPLEXO; TYPE COMPLEXO = RECORD real: REAL; // parte real img : REAL; // parte imaginria END; (* --- Procedimentos e Funes ---*) PROCEDURE criaCmplx(r: REAL; i: REAL) : COMPLEXO PROCEDURE getReal(c: COMPLEXO): REAL; PROCEDURE getImag(c: COMPLEXO) : REAL; PROCEDURE mudaReal(dr: REAL; c: COMPLEXO) : COMPLEXO; PROCEDURE iguais(c1: COMPLEXO; c2: COMPLEXO) : BOOLEAN; PROCEDURE somaComplx(c: COMPLEXO; c1: COMPLEXO) : COMPLEXO; END MODULE.

O Paradigma

JAVA5 E PROGRAMAO POR OBJECTOS (F. MRIO MARTINS 2006)

Este mdulo, de nome COMPLEXO, em estreita obedincia s regras apresentadas guarda um representao do tipo de dados Complexo como sendo um RECORD com dois REAL, e define um conjunto de funes disponibilizadas na sua interface para que do exterior do mdulo possam ser criados e manipulados nmeros complexos, designadamente, consultas, modificao da parte real, comparao e soma. Note-se que os nmeros complexos a tratar no so interiores ao mdulo. Existem em espaos de variveis de programas que usam este mdulo. Torna-se agora fundamental compreender, com base neste exemplo, a importncia do encapsulamento e da obedincia a certas regras por parte de quem quem programa. O que est encapsulado neste mdulo , antes de mais, a representao de um nmero complexo. Por isso, que uma abstraco de dados, como o prprio nome do mdulo indica. Vamos agora considerar dois exemplos distintos de utilizao deste mdulo COMPLEXO e verificar o que acontece em cada caso perante uma situao de alterao do cdigo interno do mdulo, em especial da representao do tipo complexo. Consideremos um primeiro programa obedecendo rigorosamente s regras bsicas de utilizao de um mdulo, ou seja, fazendo acesso ao mdulo usando apenas o que este exporta, isto , torna pblico (a sua API), que sero sempre procedimentos e nomes de tipos de dados, mas nunca representaes internas. Todo o cdigo est escrito usando apenas as funes da API, sem nunca utilizar a representao interna do tipo de dados que, apesar de tudo, o programador sabe (basta-lhe ler o cdigo fonte) ser um RECORD com dois campos REAL. No entanto, o programador respeitou as regras do encapsulamento tendo apenas usado a interface do mdulo.

IMPORT COMPLEXO;

// PROGRAMA A

VAR complx1, complx2 : COMPLEXO; preal, pimg : REAL; BEGIN complx1 = criaComplx(2.5, 3.6); preal = getReal(complx1); writeln("Real1 = ", preal); pimg = getImag(complx1); writeln("Imag1 = ", pimg); complx2 = criaComplx(5.1, -3.4); complx2 = mudaReal(5.99, complx2); preal = getReal(complx2); writeln("Real2 = ", preal); complx2 = somaComplx(complx1, complx2); preal = getReal(complx2); writeln("Real2 = ", preal); pimg = getImag(complx2); writeln("Imag2 = ", pimg); END.

Consideremos, em seguida, um segundo programa que realiza exactamente as mesmas operaes bsicas que este primeiro, mas que, no entanto, as vai realizar usando o conhecimento que o seu programador tem sobre a representao interna do tipo de dados Complexo e que usa explicitamente. Ou seja, conhecendo a representao interna do tipo Complexo, usa-a directamente no seu cdigo para fazer acesso aos valores da mesma que pretende manipular (os campos do RECORD):

O Paradigma

O PARADIGMA DA PROGRAMAO POR OBJECTOS

IMPORT COMPLEXO;

// PROGRAMA B

VAR complx1, complx2 : COMPLEXO; preal, pimg : REAL; BEGIN complx1 = criaComplx(2.5, 3.6); preal = complx1.real; writeln("Real1 = ", preal); pimg = complx1.img; writeln("Imag1 = ", pimg); complx2 = criaComplx(5.1, -3.4); complx2.real = 5.99; preal = complx2.real; writeln("Real2 = ", preal); complx2.real = complx1.real + complx2.real; complx2.img = complx1.img + complx2.img; preal = getReal(complx2); writeln("Real2 = ", preal); pimg = getImag(complx2); writeln("Imag2 = ", pimg); END.

Naturalmente que o programa no vai gerar erros de compilao e vai executar de forma correcta, produzindo at os mesmos resultados que o primeiro. Porm, este segundo programa, contrariamente ao primeiro, no independente do contexto e a qualquer momento poder tornar-se num programa errado e que no executa. De facto, porque usa directamente a representao interna do tipo de dados, que deveria ser protegida, mas que de facto no o na maioria das linguagens pois o compilador aceita a sintaxe utilizada, este programa passar a conter erros caso a representao do tipo de dados no mdulo seja modificada, numa prxima verso, por exemplo. Imagine-se que o programador do mdulo COMPLEXO altera a representao interna do tipo de dados Complexo para um array de reais com duas posies, e reprograma o cdigo dos procedimentos em conformidade com esta nova representao. O que acontecer a cada um dos dois programas anteriores? O primeiro programa, porque apenas usou os mecanismos de acesso ao mdulo que fazem parte da interface deste, no sofreria qualquer tipo de problema. Porm, o segundo programa deixaria de estar correcto porque usa a representao antiga de forma explcita e directa, e esta foi entretanto alterada. Todas as instrues a cinzento passariam a estar erradas, gerando erros de compilao. Finalmente, uma outra regra de programao muito importante e que deve ser respeitada sempre que pretendermos escrever cdigo independente do contexto e, portanto, reutilizvel, nunca introduzir cdigo de leitura e escrita (input/output) junto do cdigo que implementa a camada computacional. H muitos anos que na rea das interfaces com o utilizador foi definido um princpio fundamental para o correcto desenvolvimento e articulao entre as duas camadas, designado por princpio da separao, que advoga exactamente a completa separao das instrues que implementam a interface com o utilizador das que implementam a funcionalidade das aplicaes, ou seja, a separao da camada interactiva da camada computacional. A justificao , cada vez mais, muito fcil de compreender. Antes de tudo, para a mesma camada computacional poder ser necessrio ter mais de um tipo de interface com o utilizador, dependendo dos ambientes de execuo. Por exemplo, sem componentes grficos, com componentes grficos, como janelas e botes, de um dado sistema de janelas ou de outro, etc. Se introduzirmos cdigo de input ou de output na camada computacional, evidente que a funcionalidade desta ficar dependente do tipo de interface com o utilizador que tal cdigo representa. Deixa de imediato de ser uma camada computacional independente do
O Paradigma
9

JAVA5 E PROGRAMAO POR OBJECTOS (F. MRIO MARTINS 2006)

contexto e, assim, no reutilizvel ou, no mnimo, no facilmente reutilizvel. Em concluso, tendo sido durante muitos anos uma das grandes preocupaes da Engenharia de Software a criao de unidades de programao que oferecessem a quem desenvolve aplicaes no apenas um grau de abstraco que permitisse que a complexidade dos projectos fosse diminuda, mas tambm que permitissem reduzir custos de projecto caso pudessem ser unidades reutilizveis, e tendo-se pensado inicialmente que a soluo estava nas abstraces de controlo ou procedimentais, a prtica veio a demonstrar que a evoluo de tais mecanismos se deveria centrar nos dados e no nas instrues, o que conduziu definio, actualmente em vigor, de que tais unidades de abstraco, independentes do contexto e reutilizveis, devem ser de facto mecanismos de abstraco de dados. Estes assumem a estrutura de uma cpsula cujo acesso exterior dever apenas ser realizado atravs do que tal cpsula disponibiliza para o exterior pela definio da sua interface ou API. Atravs de pequenos exemplos, foram apresentadas regras, quer para a construo quer para a utilizao de tais mdulos, regras que so essenciais para que tais mecanismos sejam no s bem programados como tambm bem utilizados. A noo de objecto, crucial PPO, que se apresenta na seco seguinte, assenta fundamentalmente em tais conceitos e regras, que so ainda complementadas em PPO pela existncia de mecanismos adicionais de abstraco, de generalizao e de extensibilidade.

1.3 O que um objecto?

A noo de objecto uma das noes cruciais ao paradigma da PPO, dado que tal conceito pretende em si concentrar todas as virtudes de um modelo de concepo e desenvolvimento de software baseado nas propriedades anteriormente estudadas e vistas como fundamentais, e que so: a independncia de contexto (que permite reutilizao); a abstraco de dados (que garante abstraco); o encapsulamento (que garante abstraco e proteco); a modularidade (que garante composio das partes). Um objecto , no contexto da PPO, o mdulo computacional bsico e nico, e, por definio, corresponde representao abstracta de uma entidade autnoma sob a forma de: Uma identidade nica; Um conjunto de atributos privados (o estado interno do objecto); Um conjunto de operaes que so as nicas que podem aceder de forma directa a tal estado interno. Destas operaes algumas podem ser definidas como invocveis a partir do exterior do objecto (pblicas), constituindo a sua interface, enquanto que outras podero ser declaradas como apenas acessveis a partir de outras internas ao objecto (privadas); tais operaes representam, no seu conjunto, o designado comportamento total do objecto. As operaes que um objecto capaz de realizar e que so por si definidas como acessveis ou invocveis do seu exterior, constituem aquilo que normalmente se designa por interface do objecto, ou apenas API, no sentido de que quem pretender utilizar a funcionalidade oferecida pelo mesmo apenas o poder fazer usando as operaes definidas por tal objecto como pblicas. Dadas estas caractersticas e propriedades de acesso e visibilidade, um objecto de facto uma entidade cuja estrutura interna deve ser desconhecida do exterior e, por isso, no directamente acessvel, e que apenas divulga para o exterior um conjunto de operaes que capaz de executar quando externamente invocadas, operaes essas que podero, ou no, devolver a quem as invocou um resultado. comum at associar este comportamento dos objectos noo de prestao de servios s entidades que os solicitem via interface, sendo tais entidades vistas como seus clientes. Assim, um objecto pode ser visto como sendo uma black box, ou cpsula, que disponibiliza alguns botes que, quando so accionados, realizam uma computao interna no objecto e devolvem, ou no, um resultado. O conjunto de servios que um objecto capaz de prestar coincide com a sua interface ou API.

10

O Paradigma

O PARADIGMA DA PROGRAMAO POR OBJECTOS

Passaremos a designar os identificadores que guardam os valores dos atributos de um dado objecto por variveis de instncia, e as operaes que representam o seu comportamento, ou seja, as computaes que capaz de realizar internamente, por mtodos de instncia.

1.4

O Encapsulamento: propriedade fundamental

A Figura 1.7 procura reforar visualmente esta perspectiva de que um objecto deve ser visto como uma cpsula (uma capsulao de dados, ou ainda, usando um neologismo informtico de origem anglosaxnica, um encapsulamento de dados).
objectoX

Dados privados

mtodo pblico1 mtodo pblico2 ...... ...... mtodo privado

Figura 1.7 Objectos como cpsulas

Em termos genricos, ou seja, independentemente de qualquer paradigma e tendo apenas em ateno propriedades desejveis do software, demonstrou-se na seco anterior que o encapsulamento dos dados uma propriedade fundamental para que se possa atingir a to desejada independncia de contexto, que vai, por sua vez garantir propriedades importantes, tais como a facilidade de reutilizao, a facilidade de deteco de erros e a modularidade. Note-se portanto que esta noo de objecto est completamente de acordo com a noo de mdulo de dados elaborada anteriormente. Tal como a figura permite analisar, um objecto em PPO possui uma estrutura de dados interna e privada, que corresponde sua representao definida, em geral entre vrias possveis. A Figura 1.8, que se apresenta a seguir, representa a estrutura e o comportamento de um objecto complexo1:
complexo1 Variveis de Instncia double pReal; double pImag;

Mtodos de Instncia
real getReal() real getImag() void mudaReal(real dr)

................................... real calcAngulo()

O Paradigma

11

JAVA5 E PROGRAMAO POR OBJECTOS (F. MRIO MARTINS 2006)

Figura 1.8 Um objecto

Os mtodos privados, dado apenas poderem ser invocados do cdigo de outros mtodos do objecto e no a partir do exterior do objecto, funcionam como mtodos auxiliares. Um objecto apresenta-se deste modo como uma unidade computacional fechada e autnoma, ou seja um mdulo, capaz de realizar operaes sobre o seu prprio estado interno e devolver respostas para o exterior sempre que os seus mtodos definidos como pblicos sejam solicitados, isto , invocados. Ou seja, um objecto capaz de prestar servios atravs da activao dos mtodos que foram tornados pblicos, servios que se traduzem no envio de respostas (ou seja resultados) s activaes realizadas a partir do seu exterior.

1.5 Mensagens
Assim sendo, torna-se desde j importante analisar qual o mecanismo que, em linguagens de PPO, permite que uns objectos possam invocar mtodos de outros, desta forma solicitando resultados do comportamento interno de outros objectos. De facto, por exemplo, em JAVA, os mtodos de um objecto no so invocados de forma directa, isto , no uma usual e directa invocao de um procedimento. Em PPO, a interaco entre diferentes objectos faz-se atravs de um mecanismo de mensagens. Quando um objecto pretende invocar um mtodo de um outro objecto a que tem acesso, tem que a este enviar a mensagem adequada para que tal mtodo seja executado. Assim, em PPO, em cada computao, ou seja, em cada transio de estado do programa, existe um objecto que emissor de uma mensagem e um outro objecto que o receptor da mesma. A computao resulta do facto de que um objecto que recebe uma dada mensagem vai executar, caso tal seja possvel, o mtodo que a tal mensagem por si associado, segundo regras bem definidas, sendo resultados possveis de tal execuo quer a sua alterao de estado interno, quer a devoluo de um resultado ao objecto que lhe enviou tal mensagem (Figura 1.9).

A
mensagem

a1

b1

resposta

Figura 1.9 Interaco entre objectos usando mensagens

Tal como a figura procura representar, o envio de uma mensagem de um objecto a outro realizado durante a execuo de um determinado mtodo do emissor, dado que este necessita de um servio particular do receptor para realizar a sua prpria computao, que ser certamente para ele prprio poder igualmente prestar um servio solicitado por um outro qualquer objecto. A Figura 1.9 mostra-nos uma situao comum em que um objecto A durante a execuo do seu mtodo a1() necessitou de enviar uma mensagem ao objecto B, invocando o mtodo b1(), cujo resultado fundamental para a continuao da execuo do seu mtodo. O objecto B executa o mtodo invocado correspondente mensagem recebida e envia o resultado ao objecto A que s ento retoma a execuo do seu mtodo a1() que entretanto havia ficado suspenso espera da recepo de tal resultado. Desta interaco entre objectos atravs do envio de mensagens entre si, resulta a computao e as necessrias transies de estado interno dos objectos, estados individuais que representam, no seu somatrio, o estado global do programa, que , portanto, neste paradigma, um estado claramente distribudo. Na Figura 1.10 representa-se um objecto que implementa uma stack de inteiros e que torna pblicos os
12

O Paradigma

O PARADIGMA DA PROGRAMAO POR OBJECTOS

usuais mtodos de inicializao de uma stack, introduo de um inteiro, remoo do elemento do topo, consulta do elemento no topo e de determinao da actual dimenso da stack.
stack
Variveis de Instncia
/* uma stack de inteiros !! */

Mtodos de Instncia
init() int top() pop() push(int e) int size()

Figura 1.10 Um objecto stack e a sua interface

As mensagens so, como vimos, um mecanismo de acesso indirecto ao cdigo e estado de um dado objecto. Assim, para cada mensagem enviada a um objecto, e em funo do identificador e parmetros da mensagem, activado, caso exista no objecto receptor, o mtodo de igual identificador ao da mensagem, e compatvel em termos do nmero e tipo dos parmetros de tal mensagem. Para alm desta reaco de um objecto recepo de uma mensagem, se da execuo do mtodo resultar um dado valor resultado, este de imediato utilizvel pelo objecto emissor da mensagem. Ainda que de linguagem para linguagem de PPO possam existir ligeiras variaes de sintaxe, a sintaxe geral para o envio de uma mensagem a um objecto assume sempre uma das seguintes formas simples e genricas: Envio de uma mensagem sem argumentos a um objecto, sem que haja retorno de resultado pelo mtodo correspondente: receptor.mensagem( ); Envio de uma mensagem com argumentos a um objecto, sem que haja retorno de resultado pelo mtodo correspondente: receptor.mensagem(arg1, arg2, ..., argn); Envio de uma mensagem sem argumentos a um objecto, havendo retorno de resultado pelo mtodo correspondente: resultado = receptor.mensagem(); Envio de uma mensagem com argumentos a um objecto, havendo retorno de resultado pelo mtodo correspondente: resultado = receptor.mensagem(arg1, arg2, ..., argn); Note-se que nas expresses anteriores, resultado e receptor representam de forma genrica identificadores de variveis que, em C++ e em JAVA, que so linguagens de PPO com type checking, ao contrrio, por exemplo, de Smalltalk, tm tipos de dados a si associados, ou seja, apenas podem referenciar valores de tais tipos. Quanto expresso mensagem(arg1, arg2, ..., argn), ela representa uma forma de identificao de um mtodo a executar no receptor, mtodo esse que, conforme se disse atrs, deve possuir o mesmo nome, ter igual nmero de parmetros, sendo os seus parmetros compatveis em tipo com os tipos dos argumentos da mensagem, sejam estes valores explcitos (como 10 ou "abc") ou valores contidos em variveis (como s, x).
O Paradigma
13

JAVA5 E PROGRAMAO POR OBJECTOS (F. MRIO MARTINS 2006)

Assim, mensagens e mtodos so entidades distintas, sendo os mtodos invocados atravs do envio das correspondentes mensagens a um objecto. Procurando agora concretizar um pouco mais, atravs de exemplos simples, todo o poder de um mecanismo como o mecanismo de mensagens, nico em PPO, e a sua efectiva diferenciao da noo de mtodo, consideremos um objecto stack tal como apresentado anteriormente na Figura 1.10. Conforme publicitado na sua interface, um objecto stack de inteiros capaz de responder s mensagens seguintes, as nicas compatveis com os mtodos tornados pblicos: push(int e); init(); pop(); int top(); int size(); Admitindo que um qualquer objecto emissor solicitou a um dos vrios possveis objectos que implementam uma stack a determinao do seu tamanho, seja no exemplo tal objecto associado varivel stack1, tal funcionalidade descrita na Figura 1.10, seria implementada pela expresso seguinte: tam = stack1.size(); Caso um emissor apenas pretendesse determinar qual o topo actual de tal stack, ento a mensagem a enviar ao objecto particular stack1, deveria ser a seguinte: elem = stack1.top(); sendo o resultado do envio de tal mensagem, ou seja, o resultado da execuo do mtodo top() guardado na varivel designada por elem. Admitindo que um dado objecto emissor possa ter acesso ao objecto stack1, caso o primeiro pretendesse durante a execuo de um qualquer mtodo seu modificar o estado interno de stack1, por exemplo, inserindo em stack1 mais um inteiro, ento, no cdigo de tal mtodo, deveria aparecer a expresso correspondente efectiva execuo de tal objectivo, ou seja: stack1.push(12); O facto de o mecanismo de mensagens ser independente dos prprios mtodos dos objectos, confere a este mecanismo um grau de abstraco e generalizao de grande interesse, dado que a mesma mensagem poder ser reconhecida por vrios objectos distintos, cada um executando depois o seu prprio mtodo. Tal confere uma flexibilidade invulgar, muito difcil de conseguir na programao imperativa. Por exemplo, se tivermos objectos distintos que so tringulos, rectngulos ou crculos, faz todo sentido que todos eles respondam mensagem desenha(): triangulo1.desenha(); rectang1.desenha(); circulo2. desenha(); cada um deles activando o mtodo especfico para que se obtenha tal resultado. O valor da mensagem a invocao do mtodo , dado pelo receptor. Num paradigma imperativo deveramos ter uma funo para cada tipo de objecto desenhvel. Por outro lado, ao invs do modelo imperativo, se mais tarde criarmos objectos que so, por exemplo, trapzios, quadrados, hexgonos, etc., ento estes objectos tambm podero responder mensagem desenha(), desde que nas suas classes seja implementado o seu mtodo especfico desenha(). As mensagens so igualmente um mecanismo de suporte abstraco, dado que do exterior de um objecto apenas a sua interface dever ser visvel, representando esta o conjunto de mensagens que o objecto
14

O Paradigma

O PARADIGMA DA PROGRAMAO POR OBJECTOS

reconhece. No exemplo anterior da stack, seramos capazes de a utilizar sem saber como est efectivamente representada. O facto de as mensagens serem independentes dos mtodos, para alm da necessria coincidncia nos nomes e argumentos, tambm positivo para que os vocabulrios das linguagens, ainda por cima de linguagens extensveis pelo utilizador, sejam de certa forma reduzidos. Por exemplo, se, numa dada linguagem de PPO, for usual que a mensagem enviada a um objecto para se determinar a sua dimenso seja, por exemplo, size(), torna-se natural que o programador de novos objectos que possuam caractersticas dimensionais siga a regra, e programe um mtodo size() que responda a tal mensagem. Desta forma, passa a existir no s uma reduo do vocabulrio de mensagens e mtodos, como tambm uma natural normalizao, o que tem grandes vantagens, principalmente tendo em considerao que estas so em geral linguagens com bibliotecas extensas e que, existindo um claro objectivo de reutilizao, tal significa um esforo inicial de conhecimento do que j existe implementado, em geral, muito grande.

1.6

Objectos em PPO: instncias e classes

Introduzimos anteriormente a noo de objecto em PPO como sendo uma entidade encapsulada, protegida e unicamente acessvel atravs do que torna pblico pela sua interface e cujo comportamento definido acessvel do exterior atravs de um mecanismo de envio de mensagens. Racionalmente, as nicas formas de garantir que todos os objectos do tipo Complexo so realmente iguais em estrutura (possuem as mesmas variveis de instncia) e em comportamento (possuem o mesmo conjunto de mtodos que implementam as eventuais respostas s mensagens recebidas), so as seguintes: 1. Qualquer novo objecto de um dado tipo que se pretenda criar construdo a partir de um outro objecto do mesmo tipo usando um mecanismo de copy & paste, dando-se, em seguida, os valores desejados s variveis de instncia do novo objecto; 2. Objectos de um dado tipo possuem a sua representao estrutural, ou seja, as suas variveis de instncia, e comportamental, ou seja, os seus mtodos, guardados num objecto especial que representa a definio de todos os objectos desse tipo, definio padro que reproduzida sempre que um novo objecto de tal tipo tem que ser criado. Ainda que tenham existido linguagens de PPO que tenham implementado a primeira soluo, de facto, as principais linguagens de PPO, como Smalltalk, C++ e JAVA, adoptaram a segunda soluo. Nestas linguagens, a forma encontrada para se garantir que todos os objectos de um dado tipo tm igual estrutura e comportamento, foi criar uma espcie particular de objectos que guardam a definio de tal estrutura e de tal comportamento. Estes objectos especiais designam-se em PPO por Classes. Assim, as classes so, numa primeira definio, objectos particulares que servem para: Conter a descrio da estrutura e comportamento de objectos similares; Criar objectos particulares possuindo tal estrutura e comportamento. Assim, passaremos a designar por classe todos os objectos que guardam a estrutura e o comportamento comuns a todos os objectos que a partir de si so identicamente criados, objectos individuais esses que designaremos por instncias (traduo discutvel mas estabelecida da respectiva palavra inglesa instance). Metaforicamente apenas, as classes sero de momento vistas como as fbricas ou moldes das instncias, mas ser com as instncias que iremos realizar as computaes. Isto , a nica evoluo relativamente a tudo o que at ao momento havia sido dito relativamente ao paradigma da PPO que ficamos agora a saber que os objectos a que at agora nos havamos referido so de facto instncias de uma classe, sendo tal classe representada por um objecto especial que garante que todas as instncias a partir de si criadas so coerentes, ou seja, tm igual estrutura e comportamento. Portanto, se num dado programa necessitarmos de objectos do tipo Ponto2D, que possuem duas variveis de instncia para representar as suas coordenadas inteiras e alguns mtodos para a sua manipulao, ento,
O Paradigma
15

JAVA5 E PROGRAMAO POR OBJECTOS (F. MRIO MARTINS 2006)

deveremos construir a classe de nome Ponto2D e, a partir desta, as instncias de Ponto2D que necessitarmos. Ser com estas instncias, atravs do mecanismo de envio de mensagens que invocam os respectivos mtodos de tipo pblico, que realizaremos as computaes, quer modificando o estado internos de tais instncias, quer enviando mensagens que activam mtodos que consultam tal estado interno e devolvem resultados. Tal como definida, numa notao j muito prxima de JAVA, esta classe Ponto2D especifica que qualquer objecto instncia de Ponto2D que a partir da mesma possa vir a ser criado, deve conter duas variveis de instncia de nome x e y, variveis que apenas podero conter valores do tipo inteiro e, ainda, que qualquer instncia de Ponto2D dever ser capaz de responder s mensagens coordX() e coordY(), que tero como resultado, respectivamente, os valores inteiros das coordenadas em x e em y dos pontos receptores das mesmas, bem como sero capazes de incrementar os seus valores internos em dx e dy unidades ao receberem as mensagens incX() e incY(), em cujo caso apenas alterado o estado interno do objecto, no sendo pois devolvido qualquer resultado, conforme se especifica usando a palavra reservada void (Figura 1.11).
CLASSE Ponto2D
Variveis de Instncia int x ; int y;

Mtodos de Instncia int cx() int cy() void incX(int dx) ................................... boolean impar()

Figura 1.11 A Classe Ponto2D

Definida a classe Ponto2D, poderemos a partir de agora criar objectos que so de facto as instncias desta classe. Em JAVA tal realizado usando expresses da forma seguinte:
Ponto2D pt1 = new Ponto2D(); Ponto2D pt2 = new Ponto2D();

que sero mais tarde completamente analisadas, mas que, conforme facilmente se pode compreender, criam duas instncias de Ponto2D referenciadas por pt1 e pt2, variveis que foram declaradas como tendo tal tipo. Possuindo um objecto do tipo Ponto2D referenciado pela varivel pt1, poderemos, a partir de ento, e tal como vimos atrs, enviar a tal objecto, que uma instncia da classe Ponto2D, as mensagens que na sua classe foram definidas como sendo as mensagens a que este capaz de responder, por exemplo, as seguintes:
cx = pt1.coordX(); cy = pt1.coordY(); pt1.incX(); pt1.incY();

Pela estrutura de cada uma das expresses que se apresenta, torna-se imediato compreender se a mensagem corresponde a uma modificao do estado interno do objecto, tal como incX() e incY(), em que no h resultado devolvido, ou se se trata da invocao de um mtodo de consulta, em cujo caso devolvido um resultado (Figura 1.12).

16

O Paradigma

O PARADIGMA DA PROGRAMAO POR OBJECTOS

mensagem

pt1
-7 6

resposta

Figura 1.12 Mensagem/resposta como computao

Torna-se tambm de imediato claro que, em PPO, qualquer instncia possui um s tipo, isto , instncia de uma e uma s classe. Como veremos nos captulos seguintes, as variveis de instncia definidas numa classe podem no s ser de tipo simples, mas tambm definidas como sendo instncias de uma dada classe j existente, desta forma permitindo que classes possam ser usadas na criao de outras classes. Por exemplo, tendo a classe Ponto2D poderamos definir uma classe Circulo custa de duas variveis de instncia: uma do tipo Ponto2D (o centro) e outra do tipo double, o raio.

1.7 Sntese do Captulo

Apresentou-se neste captulo a gnese do paradigma da Programao Orientada aos Objectos, com especial incidncia, dada a sua importncia para a compreenso do paradigma, na evoluo dos conceitos na Engenharia de Software que vieram a conduzir noo de abstraco de dados, da qual deriva a definio de objecto, a entidade fundamental em PPO. Foram introduzidos alguns princpios de programao que visam garantir que os objectos que desenvolvemos, bem como quem deles faz uso, so unidades que, por serem independentes do contexto, facilitam a manuteno e a reutilizao. Duas regras foram consideradas como fundamentais: Um objecto no deve manipular directamente os dados internos de outro; Um objecto genrico no deve ter instrues de input/output no seu cdigo. Assim, a viso de criao e utilizao de um objecto a de uma cpsula contendo dados privados e que disponibiliza, atravs da sua interface, um conjunto de mtodos que so accionveis do exterior atravs de um mecanismo de mensagens. Esta perspectiva favorece uma outra comum interpretao do que se deve entender por objectos, apresentando-os como caixas pretas que prestam um conjunto de servios ao exterior ao receberem mensagens que lhes sejam apropriadas. Esta viso permite ainda que, por vezes, se refira o objecto que envia a mensagem como objecto-emissor ou objecto-cliente, e o que a recebe e, eventualmente, responde mesma como receptor ou servidor. A computao num sistema de objectos decorre da troca de mensagens entre os vrios objectos, dessa troca resultando alteraes nos seus estados internos e, consequentemente, do estado global do programa, que, neste modelo computacional, um estado distribudo por todos os objectos que o constituem. Finalmente, foi realizada a distino entre dois tipos de objectos, instncias e classes. Classes so objectos especiais onde se definem estrutural e comportamentalmente todos os objectos instncia criados a partir de tal classe. As instncias sero as nossas entidades activas, computacionais, pois respondem a mensagens activando mtodos e realizando as computaes programadas em tais mtodos. No prximo captulo, introduziremos a tecnologia JAVA e o ncleo bsico da linguagem JAVA5 que iremos posteriormente utilizar e enriquecer nos captulos seguintes. No captulo 3 estudaremos de forma aprofundada como criar classes e instncias em JAVA.

O Paradigma

17