AN02FREV001/REV 4.

0
1
PROGRAMA DE EDUCAO CONTINUADA A DISTNCIA
Portal Educao






CURSO DE
JAVA E O PARADIGMA DA
ORIENTAO A OBJETOS



























Aluno:
EaD - Educao a Distncia Portal Educao


AN02FREV001/REV 4.0
2











CURSO DE
JAVA E O PARADIGMA DA
ORIENTAO A OBJETOS






MDULO I












Ateno: O material deste mdulo est disponvel apenas como parmetro de estudos para este
Programa de Educao Continuada. proibida qualquer forma de comercializao ou distribuio do
mesmo sem a autorizao expressa do Portal Educao. Os crditos do contedo aqui contido so
dados aos seus respectivos autores descritos nas Referncias Bibliogrficas.



AN02FREV001/REV 4.0
3


SUMRIO


MDULO I
1 ORIENTAO A OBJETOS
1.1 CLASSES E OBJ ETOS
1.1.1 Atributos e Estado
1.1.2 Mtodos e Ao
1.1.3 Interfaces
1.1.4 O que UML e seus aspectos bsicos
1.1.5 Diagramas de Casos de Uso
1.1.6 Diagramas de Classe
1.1.7 Diagramas de Sequncia
1.1.8 Ferramentas para modelagem
1.2 ORIENTAO A OBJ ETOS EM J AVA
1.3 HISTRICO DA PLATAFORMA J AVA
1.4 CARACTERSTICAS DA PLATAFORMA
1.4.1 As diferentes verses
1.4.2 Gerenciando a memria: Garbage Colector
1.4.3 Configurando o ambiente para compilar e executar programas J ava
1.4.4 Portabilidade dos programas
1.4.4.1 Comentrios

MDULO II
2 FUNDAMENTOS TECNOLGICOS: PARTE 1
2.1 PRIMEIRO PROGRAMA EM J AVA
2.1.1 Compilando o cdigo fonte
2.1.2 Executando o programa resultante
2.1.3 Conceito e Criao de Construtores
2.1.4 Tipos de dados primitivos
2.1.5 Convertendo tipos primitivos


AN02FREV001/REV 4.0
4
2.1.6 Definindo Atributos
2.1.7 Definindo Mtodos
2.1.8 Tipos de Retorno
2.1.9 Referncia null
2.1.10 Operadores
2.1.11 Operador de instncia
2.1.12 Estruturas de controle: if
2.1.13 Estruturas de controle: ?:
2.1.14 Estruturas de controle: switch
2.1.15 Estruturas de controle: while
2.1.16 Estruturas de controle: do/while
2.1.17 Estruturas de controle: for
2.1.18 Estruturas de controle: foreach

MDULO III

3 FUNDAMENTOS TECNOLGICOS: PARTE 2
3.1 VETORES
3.1.1 A classe String
3.1.2 A classe Object
3.1.3 Herana
3.1.4 Sobrecarga (Overload)
3.1.5 Sobrescrita (Override)
3.1.6 Polimorfismo
3.1.7 Classes Abstratas
3.1.8 Interfaces
3.1.8.1 Excees
3.1.9 Trabalhando com colees
3.1.10 Trabalhando com Generics
3.1.11 Definindo grupos Enumerados





AN02FREV001/REV 4.0
5

MDULO IV

4 TPICOS SELECIONADOS
4.1 IDEIA GERAL DA NECESSIDADE DE UM BANCO DE DADOS
4.1.1 Importando as estruturas necessrias
4.1.2 Criando uma conexo
4.1.3 Exemplo completo comentado
4.1.4 Aplication Program Interface (API)
4.1.5 Editores de texto e IDEs
4.1.6 Desvio return
4.1.7 Desvio break
4.1.8 Desvio continue
4.1.9 Importando um pacote
4.1.10 O pacote java.lang.*
4.1.11 O pacote java.util.*
4.1.12 Modificador: static
4.1.13 Modificador: final
4.1.14 Autoboxing
4.1.15 Varargs
4.1.16 Modificadores de acesso: public
4.1.17 Modificadores de acesso: protected
4.1.18 Modificadores de acesso: private
4.1.19 Modificadores de acesso: default ou friendly
4.1.20 Entrada e Sada: Leitura do teclado
4.1.21 Entrada e Sada: Abertura e leitura de arquivo
REFERNCIAS BIBLIOGRFICAS








AN02FREV001/REV 4.0
6


MDULO I


1 ORIENTAO A OBJETOS


1.1 CLASSES E OBJ ETOS


Tudo em J ava se define por meio de classes e, consequentemente, por
objetos resultantes dessas classes, da a importncia de um bom entendimento
desses conceitos. De modo informal, uma classe a definio de um novo tipo de
dado para a linguagem J ava.
Uma classe em J ava uma unidade do sistema e dentro dela esto
definidos atributos e mtodos, que so, respectivamente, informaes que uma
classe pode armazenar e aes que elas podem desempenhar. Assim, um atributo
possui as mesmas caractersticas de uma varivel e um mtodo, o mesmo que um
procedimento ou funo.
A diferena entre classe e objeto reside no fato da classe conter as
definies do que essa nova unidade ir fazer e o objeto ser um caso especial de
uma classe; ele ser armazenado na memria com as informaes de variveis
preenchidas. Enquanto existe apenas uma definio de classe, podem existir
diversos objetos baseados numa classe.
Em orientao a objetos, tudo fundamentado em termos de classes, ento
os sistemas sero formados de objetos, que de alguma forma interagem entre si,
armazenando informaes e trocando informaes por meio de mensagens (que so
disparadas por chamadas aos mtodos). Em J ava isso no diferente, o sistema
formado por um conjunto de classes.
Por fim, uma classe alm de conter a sua definio, pode fazer uso de
outras classes definidas em outros pontos do sistema. Esse fazer uso significa que
novas cpias sero criadas (sendo, portanto objetos), atribudo valores, chamadas a


AN02FREV001/REV 4.0
7
mtodos definidos dentro delas e operaes realizadas, permitindo que um sistema
possa ser to grande quanto se deseje.


1.1.1 Atributos e Estado


Atributos em J ava so os locais que guardaro as informaes que fazem
sentido para aquela classe em especial. Fazendo um paralelo com outras
linguagens de programao, seriam como variveis. Uma classe, antes de se tornar
um objeto (que um caso especial da classe), possui apenas informaes de como
esses atributos devem se comportar.
Quando um objeto criado a partir de uma classe, nesse momento os
atributos passam a ter informaes especficas, ou seja, eles assumem estados
especiais (de forma geral, so atribudos valores s variveis). Dessa forma, no
estamos tratando mais de uma classe, mas sim de um objeto nico e especial e que
traduzindo para alguma linguagem de programao, seria o equivalente a criar uma
estrutura e definir quais os valores que essa estrutura possuiria durante a sua
execuo.


1.1.2 Mtodos e Ao


Cada uma das classes definidas em um projeto pode possuir diversos
trechos de cdigo que realizam operaes sobre as informaes contidas nos
diversos atributos da classe. Esses mtodos podem tambm passar mensagens
entre diversas classes, tornando possvel que um sistema complexo possa ter
diversos pontos de comunicao.
Em orientao a objetos, esses mtodos podem ser entendidos como
mensagens trocadas entre diferentes objetos, que constituem o sistema. Em J AVA,
tudo fica contido dentro de classes e qualquer execuo de cdigo deve ser feita por
chamada de mtodos, que implementa o comportamento que uma determinada


AN02FREV001/REV 4.0
8
classe e seus objetos devem ter.


1.1.3 Interfaces


O termo interface est muito presente na computao, ento preciso
deixar claro em orientao a objetos, a que ele se refere. Nesse contexto, interface
significa o estabelecimento de um contrato, sem que haja qualquer tipo de cdigo ou
implementao direta. Uma vez que alguma classe venha a utilizar esse contrato,
ela fica obrigada a fornecer implementao para o mtodo, mas levando em
considerao a sua realidade e os demais componentes de sua estrutura.
Esse tipo de estrutura especialmente til para abstrair qual deve ser o
comportamento da classe, trabalhando em um alto nvel e deixando que os detalhes
de como a funcionalidade ser feita, para um segundo momento. Em J AVA, um
exemplo clssico de uso de interface est no conjunto de colees disponveis para
trabalhar com um conjunto de objetos.
Existe todo um conjunto de interfaces que indicam qual o comportamento
mnimo que as classes que a implementarem devero tratar caso queiram assinar
esse contrato de compatibilidade. As classes concretas que a implementarem depois
que traro para a sua realidade cada funcionalidade. Em exemplos:
A interface List representa um conjunto de objetos ordenados em forma de
lista. As classes concretas ArrayList e LinkedList, implementam a interface List,
fazendo com que objetos de ambas possam adicionar e remover objetos da lista, s
que a implementao que cada uma faz disso diferente. Na primeira, existe a
simulao de um vetor, enquanto na segunda, um conjunto de ns ligados por
referncias, mas ambas continuam sendo listas que possuem elementos
sequenciais em uma determinada ordem estabelecida.







AN02FREV001/REV 4.0
9
1.1.4 O que UML e seus aspectos bsicos


J unto com este novo paradigma, veio toda uma preocupao de
documentao de cdigo e maneiras de gerar informaes, de tal forma que toda a
equipe entendesse e que no fosse puramente textual, que normalmente fornece
uma maneira pobre de se passar informaes. Dessa forma, surgiu a necessidade
de um padro de documentao comum.
A UML (Unified Modeling Language) um padro de notao que define um
conjunto de diagramas estticos (que no se modificam com o tempo) e outros
dinmicos (para quando os estados se modificam) de tal forma que o sistema possa
ser descrito com eles. Alm disso, partes no suportadas por ela podem ser escritas
tambm, fornecendo uma ferramenta poderosa.


1.1.5 Diagramas de Casos de Uso


O Diagrama de Caso de Uso descreve a funcionalidade de um sistema.
Segundo Ivar J acobson, podemos dizer que um Caso de Uso um "documento
narrativo que descreve a sequncia de eventos de um ator que usa um sistema para
completar um processo".
Um caso de uso representa alguma unidade que pode ser de alguma forma
traduzida para software por uma equipe. Esse acaba sendo o primeiro momento no
desenvolvimento de um sistema, onde os requisitos so levantados e mapeados
para documentos que podero ser utilizados pela equipe de projeto para
entendimento do futuro sistema.
Em geral, junto com os casos de uso, so mostradas as entidades que de
alguma forma iro interagir com o sistema, os chamados atores. A ligao entre um
caso de uso e um ator indica que todos os usurios que desempenharem aquele
papel tero permisso de acesso ao sistema.



AN02FREV001/REV 4.0
10

Na ilustrao acima, mostrado um diagrama de caso de uso tpico.
Existem dois atores no sistema (papis que usurios de verdade podero assumir):
Funcionrio e Administrador. O ator Funcionrio s pode acessar as funcionalidades
s quais ele estiver ligado (Login Sistema, Emisso de Relatrios e Emisso de
Ordem de Venda) e a mesma coisa vale para o Administrador, que poder acessar
as funcionalidades Login Sistema e Cadastro de Usurios.
Essa acaba sendo uma primeira viso do sistema, mas que traz muita
informao a todos os participantes do projeto, pois d uma viso sucinta e direta de
tudo que o sistema dever fazer. O prximo passo aprofundar cada um dos
bales, determinando a funcionalidade em detalhes. Esse passo normalmente feito
de forma textual, baseada em um fluxo principal e, em alguns casos especiais,
especialmente no tratamento de erros que acontecerem na funcionalidade.
Outro ponto importante listar todas as pr-condies para funcionamento
da funcionalidade (tudo que precisa ser cumprido para que o acesso
funcionalidade esteja disponvel). Segue um exemplo da funcionalidade Login
Sistema:

Pr-Condies:
Acesso ao ambiente por meio da Internet.
Browser compatvel com a verso do sistema.

Ilustrao 1: Exemplo de diagrama de caso de uso


AN02FREV001/REV 4.0
11
Fluxo Principal:
Usurio acessa o sistema por meio de um browser, digitando o endereo do
site.
Usurio preenche as informaes de nome de usurio e senha.
Aperta o boto Entrar
As informaes so verificadas no Banco de Dados.
Todas as permisses do usurio so carregadas.
A tela inicial do usurio montada e carregada.

Fluxo Alternativo 1:
Informaes digitadas incompletas.
Retorna para a tela inicial de login.
Mostra mensagem: Dados Incompletos.

Fluxo Alternativo 2:
Informaes digitadas no existem no Banco de Dados.
Retorna para a tela inicial de login.
Mostra mensagem: Dados Incorretos.

Como pode ser percebido, esse detalhamento feito em alto nvel e sem
entrar no mrito de detalhes de implementao. As pr-condies podem ser de
ambiente, como o caso, ou ento de alguma varivel que precisa estar preenchida
com um determinado valor para que o fluxo possa seguir adiante. Vale destacar que
essa documentao ainda ter que passar pela parte de arquitetura, em que outros
diagramas sero criados, mais prximos da codificao e que traro mais
informaes em um formato totalmente diferente.









AN02FREV001/REV 4.0
12
1.1.6 Diagramas de Classe


Os diagramas de classe representam as entidades (classes e interfaces) do
sistema, bem como seus relacionamentos num nvel bem mais prximo de cdigo,
em que a maioria dos mtodos pblicos j est definida; os mtodos serviro de
ponto inicial para a implementao do cdigo, eventualmente at servindo como
cascas para iniciar a implementao do cdigo propriamente dito.



























AN02FREV001/REV 4.0
13




No exemplo acima, foi criado um conjunto de classes, foram determinados
seus nomes, seus atributos e mtodos caso existam. Outro ponto interessante,
que eventualmente as relaes entre as classes podem ser estabelecidas por
ligaes entre elas, o que fica evidente no exemplo das classes Usuario,
FuncionarioVO e Admin. A primeira pai das outras duas, fazendo com que as
caractersticas definidas nelas sejam herdadas pelas demais, melhorando o nvel de
reaproveitamento de cdigo.
Outra caracterstica marcante e que se deve tentar implementar fazer com
que todos os mtodos principais j estejam estabelecidos no momento em que o
diagrama criado, pois ele ser a base para a equipe de desenvolvimento, uma vez
que nivela o conhecimento que toda a equipe tem e utiliza uma mesma linguagem,
para que problemas de comunicao sejam evitados.



Ilustrao 2: Diagrama de Classes


AN02FREV001/REV 4.0
14

A associao simples mostrada acima indica que as duas classes se
relacionam, mas sem indicar qual a relao de hierarquia entre elas. Durante a
implementao, referncias de cada uma delas devem aparecer na outra, para que
os mtodos de ambas possam ser acessados pelos seus respectivos atributos.


Na agregao mostrada acima, visto que as informaes de uma devem
ser complementadas por outra. Melhorando a ideia, que a ClasseA composta por
um conjunto de objetos de ClasseB.



Na composio mostrada acima, a diferena sutil se comparada com a
agregao, mas a diferena reside no fato de a ClasseB s existir em funo da
ClasseA, e se esta deixar de existir a outra classe tambm no faz sentido (na
agregao, ambas as classes ainda poderiam existir, independente uma da outra).




Ilustrao 3: Associao Simples
Ilustrao 4: Agregao
Ilustrao 5: Composio


AN02FREV001/REV 4.0
15

No diagrama acima, mostrada uma relao de herana entre a ClasseA e
a ClasseB, quer dizer, a ClasseA o pai de ClasseB (o tringulo fica na classe pai),
significando que a segunda um caso mais especfico que a primeira, ainda que ela
traga todo o comportamento e caractersticas da primeira, podendo assim
reaproveitar todo o cdigo da primeira.


1.1.7 Diagramas de Sequncia


Enquanto o diagrama de classe d uma viso esttica do sistema, focando
nas suas classes e relaes, existem diagramas focados na interao dos objetos e
como eles trocam mensagens para se comunicarem e invocarem funcionalidades
entre si. Um dos mais interessantes o diagrama de sequncia, em que as classes
so listadas e seu fluxo mostrado.

















AN02FREV001/REV 4.0
16

No topo do diagrama aparecem as classes que iro interagir no fluxo. No
exemplo, so as mesmas classes do diagrama de classe ( bom que seja assim
para que a consistncia entre os elementos seja mantida e menor trabalho de
entendimento da equipe seja gasto). As barras que descem do centro de cada
classe do o sentido temporal de quanto um mtodo est executando naquele ponto
ou esperando que uma chamada a outro objeto se complete.
As setas partem de um objeto para outro ou dele para si mesmo, indicando
que foi invocado um mtodo definido dentro da prpria classe. O objeto criado est
na base da seta e o mtodo invocado fica no lado da seta. Uma vez que a seta
tenha atingido um mtodo, o ponto onde foi disparada a chamada fica em espera,
aguardado a finalizao do processamento para executar os demais trechos de
cdigo. Ao final das vrias chamadas, pode ser retornado um objeto final,
representando o retorno de todas as chamadas e processando esse retorno final.





1.1.8 Ferramentas para modelagem
Ilustrao 6: Diagrama de Sequncia


AN02FREV001/REV 4.0
17


Ao se desenhar sistemas (especialmente os orientados a objetos) o uso de
ferramentas que auxiliem essa modelagem interessante, pois garante a
consistncia das informaes e facilita nos desenhos necessrios e eventuais links
com recursos externos. Existem diversas ferramentas, desde solues livres (sem
custo de aquisio das ferramentas) at ferramentas pagas, em que todo um
suporte pode ser utilizado.
Dentre as ferramentas pagas que se destacam, podemos listar o Rose da
antiga Rational e que foi incorporado pela IBM e o Enterprise Architect, da Sparx
Systems, cujas licenas possuem altos valores, porm possuem infinitos recursos e
evolues.
Dentre as ferramentas livres, destacam-se o ArgoUML e o J ude, cujo
download gratuito e pode ser feito por qualquer pessoa que tenha interesse em
trabalhar com as ferramentas. Em comum, elas possuem as facilidades de ligao
entre os diagramas e a gerao de cdigo bsico baseado nos diagramas
construdos.


1.2 ORIENTAO A OBJ ETOS EM J AVA


At pouco tempo atrs, a imensa maioria dos projetos de software era
desenvolvida sob a tica de um modelo com uma organizao orientada a dados, ou
estruturada, onde as informaes trafegavam entre camadas, sendo esses o item
principal do sistema. Uma parte de cdigo, que realizava alguma alterao nos
dados, podia ser utilizada a qualquer momento.
Isso acabou gerando grandes sistemas, pouco modularizados e
componentizados, alm de tornar o seu entendimento mais complexo, pois poderia
ser necessrio o conhecimento de todas as funes j implementadas de tal forma a
pod-las reutiliz-las da forma correta em algum outro trecho do sistema.
Tendo esses problemas em mente, novos paradigmas vm sendo
desenvolvidos e testados em projetos de software. O principal deles e que ganha


AN02FREV001/REV 4.0
18
mais fora a cada ano o modelo Orientado a Objetos. Nesse modelo, existe uma
preocupao muito grande em criar componentes e reaproveitar o cdigo desde o
princpio da modelagem do sistema.
Outra caracterstica marcante deste modelo a tentativa de criar uma
abstrao mais bem feita do mundo real, ou ao menos da parte que se deseja
implementar no sistema que se est construindo. Assim, no apenas os dados
ganham importncia, como tambm o comportamento que eles podem ter ou
assumir devem ser levados em considerao.
Pensando nas linguagens de programao, o grande expoente do modelo
estruturado foi a linguagem C, onde a grande maioria dos sistemas operacionais foi
inicialmente concebida. No modelo orientado a objetos, consideravelmente mais
novo, J ava uma das fortes candidatas para este posto, mesmo no sendo
completamente voltada a este modelo.


1.3 HISTRICO DA PLATAFORMA J AVA


A plataforma J ava no livre como muitas pessoas pensam. Ela de
propriedade da Sun Microsystem, que tem total poder sobre a linguagem e
mudanas que podem ser realizadas ou no, nela. Assim, o cdigo da linguagem de
programao pertence a uma empresa e essa pode fazer o que bem entender.
Isso um ponto negativo de alguns crticos, pois eventualmente a Sun pode
comear a cobrar por um produto que at ento no tinha qualquer custo. Isso
uma possibilidade, mas que dificilmente acontecer, devido ao alcance que a J ava
tem hoje. Qualquer tentativa em modificar esse modelo faria com que ela perdesse
participao no mercado.
Dessa forma, o objetivo principal da Sun manter a padronizao do cdigo
nica e sendo um grupo centralizador e principalmente catalisador para o
desenvolvimento da comunidade de desenvolvedores. Isso vem dando certo, ao
contrrio de outras linguagens que so totalmente livres, mas no tm a quantidade
de profissionais trabalhando que a J ava possui hoje.



AN02FREV001/REV 4.0
19

1.4 CARACTERSTICAS DA PLATAFORMA


A linguagem J ava compilada, isso significa que antes de executar o
programa que foi escrito, deve-se submeter o cdigo fonte a um compilador, que ir
verificar a existncia ou no de erros, reportando-os, caso existam ou ento gerando
o cdigo executvel em seguida. Esse procedimento o mesmo utilizado na grande
maioria das linguagens de programao.
O compilador para a linguagem J ava distribudo junto com o pacote de
desenvolvimento J 2SE, que alm do compilador inclui uma mquina virtual, que
executar o cdigo final, depois de compilado, alm de diversas outras ferramentas
para auxiliar no desenvolvimento de projetos utilizando essa linguagem.
Vale destacar que a compilao de um cdigo fonte escrito em J ava no
gera um executvel binrio segundo alguma plataforma em que ela fora compilada
(o que torna os programas escritos em C, por exemplo, pouco portveis de um
sistema para outro), mas gera um cdigo executvel intermedirio, chamado
bytecodes.
Esses bytecodes no podem ser executados diretamente pelo sistema
operacional em questo, da a necessidade de uma mquina virtual, que quem
realmente executa o cdigo binrio resultante, inserindo uma camada de abstrao
entre o programa sendo executado e o sistema operacional, permitindo que o cdigo
se torne portvel.


1.4.1 As diferentes verses


Desde o seu lanamento, no incio da dcada de 1990, a plataforma J AVA
veio mudando e evoluindo constantemente, alterando verses e ganhando novos
recursos e facilidades. As trs grandes verses existentes no momento so a 1.4, a
1.5 e a 1.6. Grande parte dos sistemas mais antigos, com mais de trs anos de


AN02FREV001/REV 4.0
20
criao, deve estar ainda na primeira das trs, principalmente pelos custos de
migrao.
A maioria dos novos sistemas j est sendo desenvolvida na verso 1.5, que
est mais estvel e melhor incorporada pelo mercado. Sistemas novos s so feitos
em verses anteriores para o caso de no ser possvel alterar a mquina virtual para
as verses mais novas. Provavelmente, com a evoluo da tecnologia, a verso 1.4
deve ser descontinuada at a total adoo de verses mais novas, com melhor
suporte e mais recursos.
Vale destacar que j est em fase de construo a verso 1.7 da tecnologia,
ainda que sem data para ser liberada completamente e sem perspectiva de ser
adotada em produo pelas empresas.


1.4.2 Gerenciando a memria: Garbage Colector


Diferente de outras linguagens de programao, o gerenciamento da
memria no de responsabilidade do desenvolvedor, mas sim da prpria mquina
virtual. Dessa forma, esse controle transparente em tempo de desenvolvimento,
facilitando muito a vida da equipe, pois no existem trechos de cdigo que poderiam
consumir memria de forma indefinida.
Sempre que um objeto criado por um trecho do programa (isso ser visto
em detalhes adiante) ele armazenado na memria do computador e fica
disposio para ser acessado quando for necessrio. Enquanto algum trecho do
cdigo puder fazer uma requisio para esse objeto criado, ele ser mantido em
memria pela mquina virtual.
A partir do momento que essa memria reservada (que contm um objeto
J ava) no for utilizada nunca mais por nenhum trecho do programa, um processo de
baixa prioridade, chamado de Garbage Colector (coletor de lixo) executado e essa
memria anteriormente alocada marcada como disponvel para ser utilizada por
outros trechos de cdigo.
Vale destacar que a prioridade desse processo aumenta dependendo da
necessidade de se buscar mais memria ociosa que esteja faltando ao sistema.


AN02FREV001/REV 4.0
21
Outro ponto importante, que no existe nenhuma maneira de explicitamente
executar esse processo (ou ao menos cham-lo), para que ele seja executado no
momento em que desejarmos.
Assim, esse controle todo feito pela prpria mquina virtual. Esse conceito
(que existe em outras linguagens de programao) de coletor de memria no mais
utilizada muito interessante por evitar que memria alocada para um objeto jamais
seja devolvida (ou liberada incorretamente), o que acontece muito para sistemas
escritos em C ou C++.


1.4.3 Configurando o ambiente para compilar e executar programas J ava


Um ponto fundamental da plataforma a utilizao de uma mquina virtual
que responsvel por executar todos os programas escritos na linguagem. Ela a
responsvel pelas chamadas ao sistema necessrias para executar o programa.
Dessa forma, devem-se escrever programas para a mquina virtual e no para um
sistema operacional em especfico.
Assim, existe uma grande variedade de mquinas virtuais, cada uma para
um sistema operacional diferente, pois cada um deles implementa uma arquitetura e
gerenciamento de sistema diferente, porm os cdigos fonte dos sistemas a serem
desenvolvidos, podem ser nicos para qualquer um deles, uma vez que foram
criados para rodar na mquina virtual.
A mquina virtual consegue executar apenas arquivos com a extenso class,
que o formato em que o compilador gera a sada dos arquivos fonte depois de
compilado, que a grosso modo, poderia ser chamado de cdigo binrio. Essa ideia
de portabilidade uma das grandes bandeiras para justificar a utilizao da
linguagem J ava.







AN02FREV001/REV 4.0
22
1.4.4 Portabilidade dos programas


Uma das grandes bandeiras vendidas pela plataforma J ava a sua
portabilidade de cdigo, que significa ter o cdigo escrito em um determinado
ambiente (Intel e Microsoft, por exemplo) e ele pode ser rodado em outros
ambientes de hardware, (como Linux, citando outro exemplo), facilitando
enormemente os esforos de desenvolvimento.
Isso se d por conceitos de mquina virtual e bytecodes. Uma vez que o
cdigo fonte escrito, ele compilado e gera bytecodes. Esses bytecodes s
podem ser executados dentro de uma mquina virtual e no diretamente pelo
sistema operacional do computador. Acessos intermedirios s podem ser feitos
pela mquina virtual.
Para cada ambiente (Linux, Microsoft Windows, MAC) existe uma mquina
virtual especfica e diferente, que far os acessos de forma especfica para o
sistema operacional em que est rodando. Porm a entrada para todas elas a
mesma, ou seja, bytecodes, que depois de compilados podem ser utilizados em
qualquer lugar.
Vale destacar que isso no exatamente verdade para a maioria dos
programas desenvolvidos, especialmente para programas que possuem uma
interface grfica, pois cada sistema operacional trabalha de uma forma com as
informaes que sero exibidas na tela, da a importncia de se testar em diversos
sistemas operacionais para se ver o resultado.


1.4.4.1 Comentrios


Como a linguagem J AVA derivada das linguagens C e C++, ela importa
diversas estruturas dessas linguagens, como o comentrio de uma nica linha,
sendo que os caracteres foram introduzidos pela linguagem C++, neste caso. Um
comentrio desse tipo desconsidera quaisquer palavras aps a digitao do smbolo.



AN02FREV001/REV 4.0
23
publ i c cl ass Test eComent ar i oUmaLi nha {

/ / Nada ser ah consi der ado nest a l i nha
/ / nemnest a par a f i ns de compi l ao

} / / Test eDeComent ar i oUmaLi nha

Assim, o smbolo de duas barras, //, significa que todos os caracteres que
vierem depois delas e na mesma linha sero desconsiderados pelo compilador,
servindo apenas para fins de documentao do cdigo. No exemplo acima, so
colocados dois comentrios dentro da classe e um ltimo no final, para deixar claro
onde a definio da classe termina.
No comentrio de mltiplas linhas, este tipo de comentrio mais antigo,
sendo definido na linguagem C (sendo tambm utilizado na linguagem C++) e define
um bloco de comentrios, podendo englobar uma ou mais linhas, pois possui um
smbolo de incio de bloco e outro smbolo para denotar o final do bloco. O exemplo
abaixo mostra o seu funcionamento.


publ i c cl ass Test eDeComent ar i oMul t i pl asLi nhas {

/ *
Nada do que est i ver ent r e o s mbol o aci ma e
o si mbol o abai xo ser ah consi der ado como cdi go
pel o compi l ador J ava
*/

} / / Test eDeComent ar i oMul t i pl asLi nhas


O smbolo /* indica o incio de um bloco de comentrios que poder ter
vrias linhas de documentao. O bloco encerrado no momento em que for
encontrado um smbolo para fechar o bloco, no caso, denotado por */. Esse tipo de


AN02FREV001/REV 4.0
24
comentrio indicado para trechos extensos de documentao, especialmente para
explicar algum algoritmo em especfico.
Por fim, a linguagem J ava introduz um novo tipo de comentrio, que permite
uma melhor documentao tcnica do sistema, pois no limita a permanncia do
que foi escrito simplesmente no cdigo, mas permite a extrao do que foi escrito,
por uma ferramenta especfica, que acaba por gerar pginas HTML com o extrado
dos arquivos, chamado javadoc.
Essa documentao especialmente til para indicar a finalidade de uma
classe, o funcionamento de um mtodo, os parmetros de entrada e sada de um
mtodo que eventualmente possa ser redistribudo e que por isso precisa ter uma
documentao de fcil acesso e que possa ser atualizada muito rapidamente. Um
exemplo de javadoc segue abaixo:

/ **
Cl asse de exempl o par a J avadoc.

@aut hor Apost i l a J ava
*/
publ i c cl ass Exempl oDeJ avadoc {

/ **
Met odo que ai nda nao f az nada.

@par amst r St r i ng de ent r ada a ser exi bi da
*/
publ i c voi d i mpr i meNada( St r i ng st r ) {

} / / i mpr i meNada

} / / Exempl oDeJ avadoc

Todo bloco de comentrios em javadoc deve comear com o smbolo /** e
terminar com o smbolo */. Tudo que estiver entre esses smbolos poder ser


AN02FREV001/REV 4.0
25
extrado quando desejado. Repare que esse tipo de comentrio sempre de
mltiplas linhas. Uma boa prtica de programao sempre colocar um bloco desse
tipo antes da assinatura das classes, atributos e mtodos.
Por fim, junto com um bloco javadoc, existem algumas marcaes especiais
que podem ser utilizadas para facilitar a documentao de pontos importantes do
cdigo. Todas essas marcas comeam com o caractere arroba, o seu nome
propriamente dito e uma lista de parmetros que descreve as informaes do
parmetro.
No exemplo acima, existe a marca @author, que recebe como argumento
uma cadeia de caracteres falando quem foi o autor da classe e a marca @param,
para indicar o parmetro de entrada do mtodo imprimeNada(), sendo que esta
marca recebe sempre dois argumentos, o nome do argumento de entrada e o
objetivo desse parmetro.
O pacote para desenvolvimento J ava, J 2SE, fornece, junto com o compilador
e a mquina virtual, um aplicativo que extrai os comentrios javadoc e gera
automaticamente os arquivos HTML correspondentes, inclusive com arquivos de
menu. Ambientes de desenvolvimento, como o Eclipse, tambm fornecessem
ferramentas para facilitar essa tarefa.












FIM DO MDULO I