Capítulo 7

UNIVERSIDADE FEDERAL DE SANTA CATARINA
Acesso remoto a horários de ônibus
Uma aplicação para dispositivos móveis utilizando
frameworks e padrões
Ramon Hugo de Souza
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
Acesso remoto a horários de ônibus
Uma aplicação para dispositivos móveis utilizando
frameworks e padrões
Ramon Hugo de Souza
Orientador: Prof. Mario Dantas
Banca Examinadora:
Palavras-Chave: Dispositivos Móveis, Banco de Dados, Frameworks, Padrões de Projeto
Florianópolis, Dezembro de 2004
Um filósofo de estatura imponente não pensa em um vazio. Mesmo suas idéias mais
abstratas são, em alguma medida, condicionadas pelo que é ou não é conhecido na
época em que ele vive.
Alfred North Whitehead
Sumário
RESUMO .................................................................................................................................................... 6
ABSTRACT ................................................................................................................................................ 7
INTRODUÇÃO .......................................................................................................................................... 8
CAPÍTULO 1 - DISPOSITIVOS MÓVEIS ........................................................................................... 10
CAPÍTULO 2 - PROGRAMAÇÃO ORIENTADA A OBJETOS ....................................................... 11
2.1 DEFINIÇÃO........................................................................................................................................ 11
2.2 HISTÓRICO ........................................................................................................................................ 11
2.3 CONCEITOS ....................................................................................................................................... 12
2.3.1 Classificação ............................................................................................................................ 12
2.3.2 Identidade ................................................................................................................................ 13
2.3.3 Encapsulamento ....................................................................................................................... 13
2.3.4 Herança ................................................................................................................................... 13
2.3.5 Polimorfismo ............................................................................................................................ 13
2.3.6 Observações ............................................................................................................................. 13
2.4 LINGUAGENS .................................................................................................................................... 14
2.4.1 Simula ...................................................................................................................................... 14
2.4.2 Smalltalk .................................................................................................................................. 14
2.4.3 C++ ......................................................................................................................................... 15
2.4.4 Objective-C .............................................................................................................................. 15
2.4.5 Java .......................................................................................................................................... 16
2.4.6 CLOS........................................................................................................................................ 17
2.4.7 Eiffel ......................................................................................................................................... 17
CAPÍTULO 3 - FAMEWORKS .............................................................................................................. 19
3.1 DEFINIÇÃO........................................................................................................................................ 19
CAPÍTULO 4 – PADRÕES DE PROJETO ........................................................................................... 20
4.1 DEFINIÇÃO........................................................................................................................................ 21
4.2 ALGUNS EXEMPLOS DE PADRÕES ..................................................................................................... 21
4.2.1 Encapsulamento ....................................................................................................................... 21
4.2.2 Derivação de classes ................................................................................................................ 21
4.2.3 Iteração .................................................................................................................................... 22
4.2.4 Exceções................................................................................................................................... 22
4.3 PADRÕES DE CRIAÇÃO ...................................................................................................................... 22
CAPÍTULO 5 - BANCOS DE DADOS RELACIONAIS ...................................................................... 23
5.1 DEFINIÇÃO........................................................................................................................................ 23
CAPÍTULO 6 - MAPEAMENTO DO PARADIGMA OO PARA O MODELO RELACIONAL .... 24
CAPÍTULO 7 - PROJETO ...................................................................................................................... 25
CAPÍTULO 8 - IMPLEMENTAÇÃO .................................................................................................... 26
CONCLUSÃO .......................................................................................................................................... 27
REFERÊNCIAS BIBLIOGRÁFICAS.................................................................................................... 28
Resumo
Da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da
Palavras-Chave: Dispositivos Móveis, Banco de Dados, Frameworks, Padrões de Projeto.
Abstract
Da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da
Introdução
A utilização de sistemas que possam prover serviços comuns no decorrer do
nosso dia a dia através da utilização de dispositivos móveis é uma realidade que vem
tomando o mercado de forma lenta no Brasil devido à não cooperação das empresas de
telefonia – no exemplo de aplicações com celulares – com medo de uma perda de lucros
por serviçoes que poderiam ser cobrados – mas não existem – dos clientes.
Acredita-se que com o tempo se torne natural uma abertura das empresas quanto
a utilização de tecnologias que facilitem um estudo científico na área de comunicação
entre dispositivos móveis.
Este trabalho se trata de um estudo da utilização de frameworks e padrões tanto
na área de banco de dados como na área de computação móvel. Levando-se em conta
que um equipamento móvel possa se comunicar com um servidor de dados que lhe
provenha o serviço adequado.
Como exemplo para estudo foi tomada uma aplicação para acesso remoto à
horários de ônibus, provendo também alguns outros serviços relacionados a esta
funcionalidade.
Levando-se em conta que os dados referentes à cobrança e direção da linha estão
armazenados no ônibus, poderíamos no caso de uma rede de transmissão sem fio,
também supor que o ônibus transmitisse para a central quando da mudança de direção –
quando da chegada no bairro por exemplo. Assim haveria a possibilidade do cliente
saber se quando o oniobus do referido horário que ele gostaria de pegar chega no bairro,
mesmo que ele se atrasasse ou no caso de um adiantamento, evitando assim que o
cliente perdesse o ônibus.
Começando com uma abordagem sobre os dispositivos móveis que se pretende
utilizar no estudo referido, passase por uma breve explanação sobre programação
orientada a objetos, com um histórico – apenas demonstrativo – sobre as linguagens
OO, passando-se a explanação de frameworks e padrões, para então abordar as
tecnologias que serão utilizadas no estudo.
É então colocada a necessidade de mapeamento de uma abordagem orientada a
objetos para um banco de dados relacional.
A parte principal trata-se do projeto e da implementação do sistema em si.
Capítulo 1 - Dispositivos Móveis
Da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da
Capítulo 2 - Programação orientada a
objetos
2.1 Definição
Programação Orientada a Objetos pode ser definida como “a programação que é
implementada pelo envio de mensagens a objetos” [3].
2.2 Histórico
As linguagens orientadas a objeto foram originadas a partir da necessidade de se
organizar o processo de programação em uma linguagem. A programação orientada a
objetos é por si, só uma técnica. Uma linguagem é dita uma linguagem orientada a
objetos, se ela suporta o estilo de programação orientada a objetos [2].
Um dos objetivos da engenharia de software é particionar o projeto de um
programa em diversos módulos, de tal forma que o desenvolvimento do software e sua
manutenção possam ser implementados com baixo custo. No passado, os paradigmas da
engenharia de software derivavam os módulos baseados na funcionalidade de um
sistema. Esses módulos correspondiam basicamente a módulos procedimentais, que
eram alimentados por dados, gerando novos dados. O paradigma de orientação a objeto
mudou essa concepção, idealizando a idéia de objetos, como módulos que se
comunicam por meio de mensagens, encapsulando ao mesmo tempo dados e funções,
por meio de um mecanismo conhecido como tipo de dados abstratos [2].
A primeira linguagem orientada a objetos que se tem notícia foi o Simula,
desenvolvido em 1967. Posteriormente veio o Smalltalk em 1970. Atualmente, existe
uma enorme diversidade de linguagens orientadas a objeto, abrangendo desde
linguagens de propósito geral, até linguagens para multimídia e programação em lógica
[2].
2.3 Conceitos
A nossa teia de relações com o mundo se dá em boa parte por meio do
conceito de objetos, temos a tendência natural de identificar o que são estas diferentes
entidades, observando como aparentam ser e qual seu comportamento para o nosso
ponto de vista, podemos definir quais são. Exemplo: um simples usuário de uma TV ou
um técnico que vai concertá-la [1].
Ao observar um rádio, nós reconhecemos sua forma retangular, seu tamanho
usual, colorido típico e aplicação. O rádio que observamos não é o único existente,
existem diversos como tipos de rádios como o radio portátil, de mesa, etc. Um tipo
específico de rádio carrega consigo uma utilização reservada, mesmo que apresente
algumas características idênticas a outros rádios, tem outras utilizações. O termo rádio
portátil caracteriza mais do que a identidade do objeto, é um tipo de objeto que
apresenta características próprias. Devemos lembrar que existem diversos tipos de
rádios que transmitem diferentes tipos de informações por outros canais (privado ou
público) e com diversas utilizações (militar ou doméstico) [1].
Agora analisando por outro ponto mais particular. Como utilizamos o rádio?
Podemos ligar por meio de um botão on/off na parte inferior esquerda, temos o controle
de volume na superior direita e o seletor de estações na parte direita superior, conforme
o modelo outras opções. Mesmo sem conhecer sua estrutura interna, as pessoas podem
utilizar este objeto ligando e desligando, aumentando ou diminuindo o volume ou
sintonizando na sua estação predileta. Os detalhes da sua estrutura ficam ocultos,
podemos então utilizar apenas o que o projetista julgou necessário [1].
Por meio deste exemplo de relação com objetos que utilizamos no nosso dia-a-dia,
podemos descrever informalmente as principais características da programação
orientada por objetos [1].
2.3.1 Classificação
É a categorização daquilo que nos rodeia. Criamos classes de objetos para
identificar objetos que compartilham de características em comuns, embora distintas,
em cada objeto. Como os seres humanos que tem características em comum, mas podem
ser distinguidos pela altura, idade, peso, etc [1].
2.3.2 Identidade
Nossa relação com os objetos ao nosso redor não se resume a simples
classificação. Por exemplo, nossa teia de relações com outras pessoas fazem elas
assumirem uma posição singular, assumindo assim uma identificação. Conhecendo mais
alguém descobrimos seu nome e sobrenome, por exemplo [1].
2.3.3 Encapsulamento
Essa característica permite que possamos utilizar um objeto conhecendo apenas
sua interface, sua aparência exterior. Como no exemplo de utilização do rádio que
descrevemos acima. O encapsulamento permite preservar informações consideradas
importantes ou sigilosas dentro do objeto, disponibilizando apenas o que se julgue
conveniente [1].
2.3.4 Herança
É o mecanismo de criação de novas classes de objetos a partir de outras já
existentes. A herança utiliza características do objeto de origem, usando uma forma
especial de compartilhamento de código. Agora podemos criar varias classes,
hierarquicamente relacionadas, especializando as classes [1].
2.3.5 Polimorfismo
Refere-se a capacidade de conhecermos em um objeto um outro mais geral. Por
exemplo, tratamos um radio como um objeto de forma geral podemos classificar o radio
como um eletrodoméstico [1].
2.3.6 Observações
A utilização da orientação à objetos no desenvolvimento de um programa se
baseia na construção de classes e na criação de objetos dessas classes, para que
trabalhem em conjunto no bom funcionamento do programa [1].
O Java é uma linguagem que carrega consigo todas as características necessárias
de orientação a objetos:
a definição de classes;
a construção de objetos contendo dados internos não acessíveis;
a disponibilidade de um mecanismo de herança.
Mesmo sendo complexa, esta forma de programação é a mais apropriada para o
desenvolvimento de sistemas, pois permite tratar problemas nos aproximando da nossa
realidade de entendimento do mundo, em vez de dirigir a solução para as características
de funcionamento dos computadores, tal como faz a tradicional linguagem procedural
[1].
2.4 Linguagens
2.4.1 Simula
A linguagem Simula foi desenvolvida por O-J Dahl, B. Myhrhaug e K. Nygaard,
no Centro Norueguês de Computação, em Oslo, em 1967, como uma extensão do
ALGOL 60. A linguagem Simula mantém algumas propriedades do ALGOL 60, além
de extensões tais como os conceitos de classe e co-rotina, bem como os conceitos
associados de variável de referência, manipulação de textos e facilidades de
entrada/saída [2].
Um dos problemas com o Simula é que ela não provê proteção para uma classe,
o que foi resolvido posteriormente no Smalltalk [2].
2.4.2 Smalltalk
A linguagem Smalltalk foi desenvolvida em 1970. No Smalltalk, não se chama
uma função, mas manda-se uma mensagem para um objeto. Dessa maneira, nada do
mundo externo pode enxergar a definição de uma classe, o que protege essa classe de
qualquer interferência [2].
Um fator característico do Smalltalk é que qualquer dado é visto como um
objeto, mesmo um número. Assim, até mesmo cálculos aritméticos simples beneficiamse da técnica de orientação a objeto [2].
Entretanto, mandar mensagens para objetos pode significar um aumento de custo
computacional que as vezes se torna um desperdício. Algumas otimizações foram
efetuadas, portanto, para evitar a passagem de mensagens em funções simples, tais
como operações aritméticas [2].
2.4.3 C++
O C++ é uma linguagem de programação de propósito geral, desenvolvida por
Bjarne Stroustrup, nos laboratórios da AT&T Bell, no início dos anos 80, como uma
evolução do C, incorporando, dentre outras, as seguintes extensões: suporte para a
criação e uso de tipos de dados abstratos, suporte ao paradigma de programação
orientada a objeto, além de diversos outras pequenas melhorias nas construções
existentes no C. Algumas de suas características são o uso de tipos estáticos, a definição
de classes, funções virtuais e overload de operadores para o suporte à programação
orientada a objeto, o uso de templates para programação genérica, além de prover
facilidades de programação de baixo nível (a exemplo do C) [2].
Depois de seu “release” inicial pela AT&T, em 1985, diversas implementações
do C++ tornaram-se disponíveis, em mais de 24 tipos de sistemas, desde PCs até
mainframes. Em 1989, o número de usuários e diferentes implementações do C++
demandaram a geração de uma norma, sem a qual seria inevitável o surgimento de
diversos dialetos. Em 1995 os comitês de normalização da ANSI e ISO C++ chegaram a
um nível de estabilidade na linguagem. Basicamente, o C++ corresponde à linguagem
descrita em “The C++ Programming Language (2nd edition)” , de Bjarne Stroustrup, ed.
Addison Wesley, 1991. A norma que regula o C++ está atualmente em fase de “draft”,
sendo catalogada como X3J16/95-0087 pela ANSI e WG21/NO687 pela ISO [2].
2.4.4 Objective-C
Objective-C é uma linguagem de programação orientada a objetos, que
corresponde a um superconjunto do ANSI-C, provendo classes e passagem de
mensagens de um modo similar ao Smalltalk. A linguagem inclui, quando comparada ao
C, alguns termos e construções adicionais. Por ser também uma linguagem derivada do
C, assim como o C++, ela é frequentemente comparada a esta. O desenvolvimento do
C++ se baseia no estilo de programação orientada a objetos iniciado pela linguagem
Simula 67. O Objective-C, por seu lado, é originário do estilo de programação
encontrado no Smalltalk. No C++, o tipo estático de um objeto determina quando ele
pode receber uma mensagem, ao passo que no Objective-C, seu tipo dinâmico é
utilizado. O estilo de programação oriundo do Simula 67 é mais seguro, uma vez que
mais erros podem ser detectados ainda em tempo de compilação. O estilo desenvolvido
pelo Smalltalk é mais flexível [2].
Algumas das vantagens do Objective-C incluem a possibilidade de se carregar as
definições das classes e métodos em tempo de execução, o fato de os objetos serem
tipados dinamicamente, a possibilidade de se utilizar objetos remotos, a persistência e a
existência de protocolos de delegação e meta-ação. Alguns de seus principais problemas
são a inexistência de herança múltipla e a inexistência de variáveis de classe [2].
2.4.5 Java
A linguagem Java foi desenvolvida a partir de 1990 pela Sun Microsystems,
como uma linguagem que pudesse executar o mesmo programa em múltiplas
plataformas de hardware e software. Seu uso imediato seria a execução de programas
pela Internet. Para tanto, não poderia haver nenhum vínculo da linguagem com o
hardware e/ou o sistema operacional utilizado, de modo que em princípio qualquer
computador conectado à Internet e capaz de entender a linguagem, fosse capaz de
executar os programas. Outra especificação básica da linguagem seria a segurança, ou
seja, como as máquinas executando os programas em Java estariam em princípio
executando programas sem garantias de confiabilidade e procedência, um programa em
Java não poderia de modo algum influir na execução de outros programas e o próprio
sistema operacional. Com isso, alguns recursos como alocação dinâmica de memória e
acesso a arquivos foram sistematicamente eliminados. A linguagem Java foi
desenvolvida a partir de um subconjunto do C++, gerando uma linguagem que
originalmente foi chamada de Oak. Em 1995, a linguagem foi re-batizada como Java e
introduzida na comunidade Internet [2].
O Java é uma linguagem parcialmente compilada e parcialmente interpretada.
Um compilador Java transforma o programa fonte, escrito em Java, em arquivos-objeto
chamados bytecodes. Esses bytecodes precisam ser executados então por interpretadores
Java que são desenvolvidos para cada plataforma de hardware/software. Os bytecodes
podem ser basicamente de dois tipos. O primeiro tipo tem acesso completo à máquina,
ou seja, é capaz de manipular a memória, o console e o sistema de arquivos. Programas
desse tipo são chamadas de aplicações Java. O segundo tipo de bytecode sofre uma série
de restrições quanto ao acesso de memória, console e sistema de arquivos. Essas
restrições são colocadas em nome da segurança, visto que seu destino é a elaboração de
programas que serão distribuídos pela Internet, e por isso não provém de fonte
conhecida ou confiável. Esses bytecodes são chamados de Java applets. Os applets têm
uma capacidade de atuação bem restrita, de modo que não possam causar danos ao
sistema durante sua execução. Normalmente sua atuação se restringe a animações e
interações mínimas com o usuário, sendo que seu uso é marcadamente em browsers do
WWW (World Wide Web). Para executar applets, os browsers necessitam interpretar os
bytecodes Java. Browsers com essa capacidade são chamados de Java aware. Uma outra
variante da linguagem Java é o JavaScript, que são programas colocados em forma de
código fonte, incluídos nos textos das páginas HTML. Programas escritos com o
JavaScript não precisam ser compilados, nem geram bytecodes, sendo interpretados
diretamente pelos browsers quando a página HTML é interpretada [2].
2.4.6 CLOS
CLOS (Common Lisp Object System) é um padrão de programação orientada a
objetos desenvolvido a partir do Common Lisp. A maioria das implementações do
Common Lisp incluem atualmente uma implementação também do CLOS, por
exemplo: MCL, {A}KCL, Allegro CL (incluíndo-se Allegro CL\PC), Ibuki, Lucid,
Medley, Symbolics Genera, CLOE, e Harlequin LispWorks [2].
2.4.7 Eiffel
A linguagem Eiffel é uma avançada linguagem de programação orientada a
objetos, que enfatiza o projeto e a construção de “software” reutilizável de alta
qualidade. A linguagem Eiffel não corresponde a um sub-conjunto ou extensão de
nenhuma outra linguagem. É uma linguagem que enfatiza o uso de técnicas de
programação orientada a objeto, impedindo algumas práticas que podem ser
potencialmente perigosas, e que são encontradas em outras linguagens. Entretanto, ela
permite um interfaceamento com outras linguagens, tais como o C ou o C++. A
linguagem Eiffel suporta o conceito de “design by contract”, para garantir a consistência
do software gerado [2].
A linguagem Eiffel foi criada por Bertrand Meyer, e desenvolvida por sua
companhia, a “Interactive Software Engineering (ISE)”. Seu design é inspirado por
algumas preocupações levantadas por engenheiros de software, diante da criação de
sistemas mais complexos. Como linguagem, vem evoluindo continuamente, desde sua
concepção, em 1986 [2].
Compiladores para a linguagem Eiffel podem ser encontrados para diversos
sistemas operacionais e plataformas de hardware, destacando-se as seguintes:
PC: DOS, OS/2, Windows 3.1, Windows 95, Windows NT, PC Unix
(Interactive, SCO, and ESIX), Nextstep, Linux [2].
Outras plataformas de Hardware: Sparc (SunOS & Solaris), NeXTStep,
HP9000, DEC 5xxx, Sony News, DG Aviion, DEC Alpha OSF-1, DEC OpenVMS,
RS6000, Pyramid, QNX, Silicon Graphics, Macintosh (Motorola & PowerPC) [2].
Capítulo 3 - Fameworks
3.1 Definição
Frameworks são ambientes de desenvolvimento pré-concebidos que oferecem
uma estrutura comum para aplicações em um dado domínio.
Neste tipo de aplicação a estrutura é reaproveitada apenas completando-se os
detalhes específicos do problema.
Esta técnica assume que uma análise OO do domínio já foi feita para criar um
framework apropriado, normalmente exigindo um domínio maior dos conceitos de OO
antes da sua aplicação.
Frameworks podem ser classificados como White Box quando são compostos
apenas por especificações da estrutura de uma aplicação, como Black Box quando já
possuem as funcionalidades implementadas, ou ainda, mais comum, o tipo Gray Box
que é uma mescla dos dois tipos anteriores.
Capítulo 4 – Padrões de Projeto
Quando um projetista é inexperiente à tecnologia orientada a objetos, esse
projetista, freqüentemente tenta entender como os conceitos trabalham dentro do espaço
da solução do próprio problema que está sendo analisado. As várias metodologias de
desenvolvimento de software orientado a objetos mostram ao leitor como aplicar um
processo de desenvolvimento particular utilizando um conjunto de diagramas para
representar tais processos, o que restringe o leitor na aplicação dos conceitos [6].
A solução computacional é, portanto, passível de manutenção. A manutenção de
um produto de software nos anos 70 era responsável por aproximadamente 40% de todo
o esforço despendido por uma organização de produção de sistemas. Nos anos 80, esse
esforço passou para 60% e atualmente chega a 80%. É importante salientar que a
manutenção de um produto de software não resume-se somente à correção mas,
também, aplica-se as modificações e ampliações necessárias ao perfeito funcionamento
do sistema [6]. Portanto, na adaptação ou aperfeiçoamento de um sistema de software
deve-se determinar novos requisitos, reprojetar, gerar código e testar o sistema
existente. Estas tarefas são definidas como manutenção[4].
Outro ponto a ser considerado é que em muitos casos o projetista que fará a
manutenção no produto de software nem sempre é o mesmo que o criou, ou nenhuma
metodologia de projeto foi aplicada, ou ainda quando a documentação é incompleta e o
registro das mudanças passadas é superficial. Certamente, este projetista, irá despender
um esforço de entendimento do software existente para posterior processo de
modificações e correções. Assim deve-se avaliar a manutenibilidade que caracteriza o
grau de facilidade com que um software pode ser entendido, corrigido, adaptado e/ou
aumentado[5].
Possivelmente, a melhor idéia para projetar e entender sistemas de software
orientado a objetos seja a criação de padrões de projeto [7]. Os padrões em geral
mostram como representar a comunicação da informação sobre abstrações e soluções
apresentando um potencial para representar as abstrações comuns que projetistas
experientes de software utilizam para resolver problemas básicos de projeto[4].
4.1 Definição
Os padrões de projeto são estruturas de colaboração de classes identificadas
freqüentemente em projetos de software orientados a objetos. Utilizando textos e
diagramas, um padrão descreve, como um problema específico, que acontece
repetidamente em um projeto maior, pode ser resolvido [8].
Um padrão visa resolver um problema comum de programação de forma a tornar
o código mais flexível satisfazendo a alguns critérios. Padrões servem de conexão entre
componentes de programas.
4.2 Alguns Exemplos de Padrões
4.2.1 Encapsulamento
Problema: campos expostos podem ser manipulados diretamente a partir de
código externo, levando a violações da invariante de representação ou a dependências
indesejáveis que impedem a alteração da implementação [9].
Solução: esconda alguns componentes, permitindo apenas acessos estilizados ao
objeto [9].
Desvantagens: a interface pode não (eficientemente) fornecer todas as operações
desejadas. O acesso indireto pode reduzir a performance [9].
4.2.2 Derivação de classes
Problema: abstrações similares possuem membros similares (campos e
métodos). Esta repetição é tediosa, propensa a erros, e uma dor de cabeça durante a
manutenção [9].
Solução: derive membros padrão de uma super classe; em tempo de execução,
selecione a implementação correta através de resoluções a respeito de qual
implementação deve ser executada [9].
Desvantagens: o código de uma classe acaba ficando distribuído em várias,
reduzindo o potencial de compreensão. A utilização de resoluções em tempo de
execução introduz overhead (processamento extra) [9].
4.2.3 Iteração
Problema: clientes que desejam acessar todos os membros de uma coleção
devem realizar uma varredura especializada para cada tipo de coleção de dados na qual
a iteração irá ocorrer. Isto introduz dependências indesejáveis que impedem a extensão
do código para outras coleções [9].
Solução: implementações, realizadas com conhecimento da representação da
coleção, realizam varreduras e registram o progresso da iteração. Os resultados são
comunicados aos clientes através de uma interface padrão [9].
Desvantagens: a ordem da iteração é fixada pela implementação e não está sob o
controle do cliente [9].
4.2.4 Exceções
Problema: problemas que ocorrem em uma parte do código, normalmente,
devem ser manipulados em outro lugar. O código não deve ser poluído com rotinas de
manipulação de erro, e nem de valores de retorno para identificação de erros [9].
Solução: introduzir estruturas de linguagem para que se jogue e intercepte
exceções [9].
Desvantagens: desta forma o código ainda pode estar cheio de rotinas de
manipulação de erro. Pode ser difícil saber onde uma exceção será manipulada. Os
programadores podem ser tentados a utilizar exceções para o controle do fluxo normal
de execução, o que é confuso e normalmente ineficiente [9].
4.3 Padrões de criação
Capítulo 5 - Bancos de dados relacionais
5.1 Definição
Da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da
Capítulo 6 - Mapeamento do paradigma OO
para o modelo Relacional
Da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da
Capítulo 7 - Projeto
Da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da
Capítulo 8 - Implementação
Da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da
Conclusão
Da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da da da da da da da da
da da da da da da da da da da da da da da da da da da da da da da
Referências Bibliográficas
[1] THOMAZ, Igor. Programação Orientada a Objetos e o Java. Viva o Linux, 23/10/2003. Disponível
em: http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=421. Acesso em: 13 de junho de 2004.
[2] GUDWIN, Ricardo R. . Linguagens de Programação. UERJ. 1997.Disponível em:
http://www.eng.uerj.br/~araujo/disciplinas/Caract/ling_prog.pdf. Acesso em: 13 de junho de 2004.
[3] PINSON, L. An Introduction to Object-Oriented Programming and Smalltalk. [S.l.]: Addison-Wesley
Publishing Company, 1988.
[4] FREITAS, Andre Luiz Castro. Inspeção de Aplicações Java Através da Identificação de Padrões de
Projeto. Congresso Brasileiro de Computação. 2003. Disponível em:
http://www.cbcomp.univali.br/anais/pdf/2003/eng121.pdf. Acesso em: 13 de junho de 2004.
[5] PETERS, J. Engenharia de Software. teoria e prática. Rio de Janeiro: Campus, 2001. p. 602.
[6] PRESSMAN, R. Software Engineering: a practitioner's approach. [S.l.]: McGraw-Hill, 2001.
p. 850.
[7] GAMMA, E. et al. Design Patterns: reusable elements of object oriented design. Reading: AddisonWesley, 1994, p. 416.
[8] APPLETON, B. Patterns and Software: essential concepts and terminology. Disponível em:
http://www.enteract.com/~bradapp/. Acessado em 13 de Junho de 2004.
[9] Padrões de Projeto. Disponível em: http://www.universiabrasil.net/mit/6/6.170/pdf/6.170_lecture12.pdf. Acesso em: 13 de Junho de 2004.