INTRODUO A ORIENTAO A OBJETOS Aula 01

Prof. Fbio Tavares Dippold

Reviso 1.6 de 12/1/2013 Disciplina de Programao III Catolica de Santa Catarina campus Joinville e Jaragu do Sul ftdippold@catolicasc.org.br
1

O QUE VAMOS VER?

1. Evoluo tecnolgica 2. Paradigma 3. Motivaes 4. Limitaes da Abordagem Estruturada 5. Programa Estruturado 6. Problemas do Modelo Estruturado 7. Programa Orientado a Objetos 8. Sistemas Orientados a Objetos 9. Padres de Projeto 10.Comparao dos modelos 11.Concluses
2

EVOLUO TECNOLGICA
A medida que o mercado exige informatizao torna-se cada vez mais necessrio o uso de programas mais complexos e pesados.

Podemos medir a evoluo do hardware quantitativamente atravs de seu poder de processamento e da sua capacidade de armazenamento.
3

EVOLUO TECNOLGICA A qualidade do software medida atravs de mtricas relacionadas a sua: Confiabilidade Operabilidade Manutenibilidade Extensibilidade Escalabilidade
4

EVOLUO TECNOLGICA
Grande parte das mtricas de qualidade do software dependem do processo de desenvolvimento. Por isto, para que haja maior produtividade e qualidade de do software existem cada vez mais softwares de apoio, tais como: Compiladores Ambientes de desenvolvimento Servidores de aplicao Bancos de dados APIs e Frameworks
5

EVOLUO TECNOLGICA
Orientao batch Distribuio limitada Software customizado Sistemas distribudos Inteligncia embutida Hardware de baixo custo

1950

1960

1970

1980

1990

2000

Multiusurio Tempo real Produto de software

Sistemas de Desktops poderosos Orientao a objetos Redes neurais artificiais Computao paralela

EVOLUO DAS LINGUAGENS DE PROGRAMAO

1960

1
1950 1980

Cdigo de Mquinas Representa o mais baixo nvel de abstrao com o qual um programa pode ser representado

Assembler

2
1960 1990

Base para todas as linguagens modernas Amplo uso Enormes bibliotecas de software

Fortran, Cobol, Algol, Basic

3
1970 2000

Linguagem de programao estruturada Linguagem Orientada a Objetos

C, Pascal, C++, Smalltalk, Lisp, Prolog

4
2000

Linguagem de consulta Linguagem Orientada a Objetos Geradores de cdigo

SQL, Java

Prximas linguagens reconhecero vozes e gestos

PARADIGMA
Algoritmos privilegiam operaes em detrimento dos dados. Bancos de dados privilegiam dados s operaes. Orientao a Objetos funde em cada Objeto o dado e as operaes.
8

QUAL O PRINCIPAL PROBLEMA?

Verse escrevendo cdigo similar infinitamente, gastando tempo e recursos na programao de rotinas que j forram criadas anteriormente, mas que pela falta de uma metodologia apropriada, no podem ser reutilizadas ou customizadas para suprirem necessidades especficas de cada cenrio.

MOTIVAES Buscar uma soluo baseada nas solues existentes de problemas similares. Quando as solues existentes no so suficientes, busca-se estender essas solues a fim de solucionar um novo problema.
O ser humano tem utilizado a abstrao como forma de lidar com situaes ou problemas de natureza complexa.
10

MOTIVAES
Pode haver diferentes abstraes da mesma realidade, onde cada uma delas oferece uma viso da realidade e serve a propsitos especficos.

medida que sistemas crescem, tambm cresce a complexidade e torna-se mais difcil satisfazer a um nmero cada vez maior de requisitos desses sistemas, muitas vezes conflitantes.
11

MOTIVAES
A abordagem orientada a objetos tem se mostrado mais adequada, comparativamente s demais, para ser empregada no desenvolvimento de sistemas de software complexos e de grande porte. A programao orientada a objetos foi desenvolvida devido s limitaes encontradas nas abordagens anteriores de programao.
12

ABORDAGEM ESTRUTURADA ou PROCEDURAL

Conjunto de instrues organizado em blocos para executar determinada tarefa (funo). Conjuntos de funes agrupadas for funcionalidades em bibliotecas. Modelagem atravs de fluxograma e grande utilizao de algoritmos. Extremamente tcnica. Exemplos: Pascal, C, Perl, Basic
13

LIMITAES DA ABORDAGEM ESTRUTURADA

Um programa em uma linguagem procedimental visto como uma lista de instrues (Pascal, C, Fortran). Para programas pequenos, nenhum princpio organizacional (ou paradigma) necessrio. medida que os programas se tornam maiores, entender e tratar uma nica lista de instrues fica mais difcil.
14

LIMITAES DA ABORDAGEM ESTRUTURADA

Poucos programadores podem compreender um programa que possua mais de poucas centenas de instrues, a menos que o programa seja quebrado ou dividido em unidades menores, denominadas de funes. Vale salientar que o termo funo usado tanto na linguagem de programao C++ quanto C. Em outras linguagens, referido como uma sub-rotina, um subprograma ou um procedimento.
15

LIMITAES DA ABORDAGEM ESTRUTURADA

A ideia de dividir um programa em funes pode ser adicionalmente estendida atravs do agrupamento de vrias funes em uma entidade maior, denominada mdulo. Dividir um programa em funes e mdulos um dos fundamentos da programao estruturada.
16

MODELO ESTRUTURADO:

Invocar
Acessar
17

SUBROTINAS SENDO CHAMADAS EM 2 LUGARES

18

SUBROTINAS SENDO CHAMADAS EM 2 LUGARES

#include<stdio.h> int main(void) { void minhaFuncao(int i); ... minhaFuncao(1); ... minhaFuncao(2); ... } void minhaFuncao(int i) { implementando algo... }

19

SUBROTINAS SENDO CHAMADAS EM 2 LUGARES

public TestarRotina() { public static void main(String[] args) { ... minhaFuncao(2); ... ... minhaFuncao(1); ... } private static void minhaFuncao(int umArgumento) { Implementando algo... } }

20

PROBLEMAS
medida que os programas se tornam maiores e mais complexos, at mesmo a abordagem de programao estruturada comea a mostrar limitaes Por exemplo, considere a situao em que muitas funes tm acesso a um conjunto de dados.
21

PROBLEMAS A forma em que os dados so armazenados torna-se crtica. A organizao dos dados no pode ser modificada sem que todas as funes que tm acesso a eles tambm seja modificadas. Se novos dados so adicionados, ento ser necessrio modificar todas as funes que tm acesso a esses dados. Tornar-se- difcil achar tais funes e at mesmo mais difcil modific-las corretamente.

22

PROBLEMAS
Tais circunstncias exigem uma forma de restringir o acesso ao dado, esconder ele de todas exceto algumas poucas funes crticas. Isto dar proteo aos dados, simplificar a manuteno bem como implicar em outros benefcios. Neste sentido, considera-se importante a introduo de programao orientada a objetos (POO).
23

ORIENTAO A OBJETOS
A ideia por trs das linguagens de programao orientadas a objetos, ou linguagens OO, combinar em uma nica entidade tanto os dados quanto as funes que operam sobre estes dados. Tal entidade denominada objeto. As funes de um objeto, chamadas mtodos, tipicamente, oferecem uma nica forma de acesso a seus dados.
24

ORIENTAO A OBJETOS
Caso torne-se necessrio ler dados em um objeto, ento basta chamar a funo membro desse objeto. Ela ler os dados e retornar o valor a quem invocou a funo.

Perceba que os dados no podem ser acessados diretamente. Os dados so ocultados.

Dados e funes so ditos ser encapsulados em uma nica entidade, denominada objeto.
25

UM OBJETO

MTODOS

ATRIBUTOS

26

UM OBJETO
ContaCorrente
transferir
nr cliente

saldo dtcriacao

27

REPRESENTAO EM UML
Nome da classe

Atributos

ContaCorrente - int : nr - cliente : String - saldo : double - dtcriacao : Date

Visibilidade

Mtodos

+ depositar( double ) : void + sacar( double ) : void + transferir( double, ContaCorrente ) : void + emitirExtrato() : string + pegarSaldo() : double

28

LINGUAGENS COM SUPORTE OO Java Objective C (IOS) C# (.NET) C++ Visual Basic .NET Action Script (Flex) Smalltalk Eiffel Simula Object Pascal (Dephi)
29

MODELO ORIENTADO A OBJETOS

Dados e atributos de cada objeto
mtodo 1
dado1 dado2 dado3 dado4

mtodo 1
dado1 dado2 dado3 dado4

mtodo 1
dado1 dado2

Classes possuem procedimentos chamados em OO de mtodos, e os mesmos encapsulam os dadis

dado3 dado4

30

PROGRAMA ORIENTADO A OBJETOS

Um programa um conjunto de objetos dizendo uns para os outros o que fazer atravs do envio de mensagens. Concretamente, pode-se pensar nas mensagens como sendo chamadas a funes que pertencem a um objeto em particular.

31

PROGRAMA ORIENTADO A OBJETOS

Cada objeto tem a sua prpria regio de memria, que pode ser composta por outros objetos, tambm. Exemplo: o objeto carro pode ser composto pelos objetos lataria, rodas, motor, etc. Cada objeto tem um tipo: isto , pertence a uma classe.

32

SISTEMA ORIENTADO A OBJETOS

Um sistema orientado a objetos uma coleo de objetos que interagem entre si. Um objeto interage com outro atravs de uma mensagem que causa um estmulo.

33

SISTEMA ORIENTADO A OBJETOS

transferir nr cliente saldo criao 2 transferir nr cliente saldo 3

criao

transferir ($100, 1.345-7)

Cliente

34

ABSTRAO

A OO traz como ideia gerenciar a complexidade do mundo atravs do uso de abstraes, criando tipos genricos que serviro como partes para outros tipos.

35

ABSTRAO

36

ABSTRAO
1. o exame seletivo de certos aspectos de problema. 2. O objetivo da abstrao isolar aspectos importantes de alguma finalidade e suprimir os aspectos que no so importantes. 3. Um bom modelo captura os aspectos cruciais de um problema e omite os outros.
37

Evoluo dos modelos de ABSTRAO

1. Todas as linguagens de programao fornecem abstraes. 2. A linguagem Assembly uma pequena abstrao da mquina na qual os programas so executados;

38

Evoluo dos modelos de ABSTRAO

As linguagens imperativas (FORTRAN, BASIC e C) so abstraes da linguagem Assembly. 1. Nestas linguagens, necessrio pensar em termos da estrutura do computador, ao invs de se pensar em termos da estrutura do problema a ser resolvido! 2. O programador deve estabelecer uma associao entre o modelo da mquina (no espao da soluo) e o modelo do problema que est sendo resolvido (no espao do problema). 3. O esforo para fazer este mapeamento pode ser gigantesco ... Uma alternativa ao modelo da mquina modelar o problema no domnio do prprio problema!
39

Evoluo dos modelos de ABSTRAO

A programao orientada a objetos tenta trazer o espao da soluo para o espao do problema: ambos so representados como objetos!! O programa permite se adaptar ao problema, adicionando novos tipos ao espao da soluo que mapeiam os tipos existentes no espao do problema ==> Descreve-se o problema em termos do problema e no em termos da soluo!! Cada objeto funciona como uma pequena parte do problema, possuindo seu estado e suas operaes, que podemos pedir que eles executem ==> isto semelhante ao comportamento dos objetos no mundo real, que tambm possuem caractersticas e comportamentos!! 40

ABSTRAO DE OBJETOS
Alan Kay resume as caractersticas da linguagem Smalltalk (primeira linguagem OO): Em Smalltalk, tudo um objeto; Um programa uma coleo de objetos dizendo um para o outro o que fazer, atravs do envio de mensagens; Cada objeto tem sua prpria regio de memria que pode ser constituda de outros objetos; Todo objeto tem um tipo Todos objetos de um determinado tipo podem receber as mesmas mensagens (tm a mesma interface) Objetos em hierarquias um tipo de podem ter a mesma interface.
41

ABSTRAO DE OBJETOS
Aristteles j identificava a ideia de tipos: Classe das aves e classe dos peixes; Os objetos, apesar de serem nicos, fazem parte de uma classe de objetos que possuem caractersticas comuns A criao de tipos de dados abstratos (classes) um conceito fundamental na programao orientada a objetos Tipos de dados abstratos funcionam praticamente da mesma maneira que os tipos fundamentais: pode-se criar variveis do tipo ==> objetos ou instncias; pode-se manipular estas variveis, enviando mensagens ou requisies para elas
42

OBJETOS e INTERFACES
Os objetos de cada classe compartilham algumas coisas em comum: toda conta possui um extrato, todo caixa pode aceitar um depsito, etc. 1. Ao mesmo tempo, todo objeto tem seu prprio estado: cada conta tem um extrato diferente, cada caixa tem um nome. 2. Ento, os caixas, clientes, contas, transaes, podem, cada um, ser representado por uma nica entidade no programa: esta entidade o objeto. 3. Cada objeto pertence a uma classe que define suas caractersticas e comportamento.
43

CLASSES

44

OBJETOS e INTERFACES
1. A partir do instante que uma classe criada, pode-se criar quantos objetos da classe quanto forem necessrios e manipular estes objetos como se fossem elementos que existissem no problema que est sendo solucionado. 2. A programao orientada a objeto cria um mapeamento nico entre o domnio do problema (local onde o problema existe) e o domnio da soluo (local onde o problema modelado: computador).

45

OBJETOS e INTERFACES
Como fazemos um objeto realizar trabalho til? 1. Cada objeto tem mtodos (funes) para desempenhar suas atividades; 2. Cada objeto pode responder somente a determinadas requisies; 3. O conjunto de mtodos de um objeto conhecido como sua interface.
46

ENCAPSULAMENTO

47

ENCAPSULAMENTO 1. O encapsulamento de dados e ocultao de dados so aspectos importantes na descrio de linguagens orientada a objetos. 2. Alm disso, se o programador precisar modificar o(s) dado(s) de um objeto, ele ter de saber exatamente quais funes interage com aquele objeto.
3. Como resultado, obtm-se simplificao na escrita, bem como na depurao e manuteno do programa.

48

ENCAPSULAMENTO 1. A estratgia utilizada para garantir que determinadas partes de uma classe no so acessveis por seus clientes denominada controle de acesso. 2. A interface no apresenta necessariamente todos os mtodos de um objeto, mas somente aqueles que podem ser acessados pelo pblico em geral, os chamados mtodos pblicos. 3. Existem mtodos internos aos objetos: os mtodos privados.
49

REUTILIZAO DA IMPLEMENTAO
1. Reuso por Herana ou Composio 2. Uma vez que uma classe foi criada e testada, ela pode ser utilizada por outras classes para auxiliar sua implementao. 3. A forma mais simples de reutilizao usar um objeto daquela classe diretamente como base. 4. Porm, pode-se utilizar um objeto de uma classe dentro de uma nova classe: sua classe pode ser composta pelo nmero e tipo de objetos que se fizerem necessrios, uma estratgia que j conhecemos: Composio.
50

OJETOS INTERCAMBIVEIS: polimorfismo 1. Quando trabalhamos com hierarquias de objetos, muitas vezes queremos tratar um objeto, no por seu tipo especfico, mas por seu tipo base.
2. Isto permite escrever cdigo que no depende do tipo especfico. Por exemplo, no caso das Shapes, poderamos escrever cdigo genrico que as manipulasse (mandando-as se desenharem, por ex.), sem se preocupar se so tringulos, crculos ou qualquer outra coisa ...
51

OJETOS INTERCAMBIVEIS: polimorfismo 1. Este cdigo no seria afetado pela adio de novos tipos de Shapes. 2. Adicionar novos tipos a forma mais comum de estender um programa orientado a objetos para gerenciar novas situaes.

52

OJETOS INTERCAMBIVEIS: polimorfismo 1. Isto o polimorfismo: o que possui vrias formas. 2. Propriedade de se usar o mesmo nome para mtodos diferentes, implementados em diferentes nveis de uma hierarquia de classes. Para cada classe, tem-se um comportamento especfico para o mtodo. 3. Sua implementao necessita que se execute ligao entre mtodo e objeto em tempo de execuo (late binding) ou mecanismo de execuo tardia.
53

RESUMO DAS DIFERENAS:

POO Dados e Funes em uma nica entidade
Lida melhor com a complexidade Melhor capacidade de manuteno com o crescimento dos sistemas. Melhores recursos e suporte a tcnicas de reuso

ESTRUTURADA Dados e funes em entidades separadas

Sistemas mais simples so mais fceis de serem resolvidos com estratgias procedurais, mas com sistemas mais complexos as dificuldades so crescentes A medida que os sistemas crescem a capacidade de manuteno se complica. Menor capacidade de reutilizao de cdigo
54

PADRES DE PROJETO
1. Conceito comum na engenharia civil e na arquitetura. 2. Um pattern descreve uma soluo comprovada para um problema de desenho recorrente, dando nfase particular no contexto e forando a aproximao do problema, e as consequncias e o impacto de sua soluo.

55

PADRES DE PROJETO
3. Uma coleo de padres de desenhos de software, que so solues para problemas conhecidos e recorrentes no desenvolvimento de software.

4. Garantem qualidade, reusabilidade, extensibilidade e baixo acoplamento

56

PADRES DE PROJETO - GOF

57

PADRES DE PROJETO (GOF)

58

CONCLUSES
1. A programao orientada a objetos uma abordagem de programao que serve de elo entre os problemas existentes e as solues computacionais apresentadas no campo da programao. 2. Antes da POO havia um obstculo conceitual para os programadores quando eles tentavam adaptar as entidades reais s restries impostas pelas linguagens e tcnicas de programao tradicionais.
59

CONCLUSES
3. Numa situao real, o ser humano tende a raciocinar em termos dos objetos ou entidades reais. 4. Antes da POO, os programadores eram ensinados a raciocinar os problemas em termos de blocos de cdigo ou procedimentos e da forma que esses atuavam sobre os dados
60

CONCLUSES
5. Observe que essas duas abordagens so distintas e constituem um problema se h necessidade de desenvolver um sistema complexo e/ou de grande porte.

6. Tem-se verificado um crescimento tanto na complexidade quanto no tamanho dos sistemas computacionais
61

CONCLUSES
7. Neste contexto, a POO apresenta-se como uma abordagem de programao que permite os programadores raciocinar e solucionar problemas em termos de objetos, os quais esto diretamente associados s entidades ou coisas reais. Como resultado desse mapeamento natural, utilizando a POO, um programador pode concentrar-se nos objetos que compem o sistema, ao invs de tentar vislumbrar o sistema como um conjunto de procedimentos e dados.
62

CONCLUSES
8. Vale salientar que a POO uma forma natural e lgica pela qual os seres humanos e, especificamente, os programadores raciocinam.

9. Os benefcios resultantes de empregar a POO como abordagem de programao no se restringe a raciocinar e resolver problemas em termos de objetos ou entidades reais, mas tambm a reutilizao de cdigo.
63

CONCLUSES
10.Alm disso, so introduzidos conceitos adicionais como: classes, encapsulamento, polimorfismo, e herana. 11.Objetos so fundamentais, por um simples motivo: tudo, isto mesmo, tudo objeto em Java e em .NET 12.Resumindo, as principais vantagens so: o reuso de cdigo e a capacidade de expanso do mesmo.
64

LINGUAGENS x AMBIENTES DE DESENVOLVIMENTO

1. Diversas linguagens possuem ambiente de desenvolvimento associado a elas: 1. Linguagem Basic possui o MS Visual Basic 2. Object Pascal possui o Delphi. 2. Outras linguagens esto desvinculadas de ambiente de desenvolvimento: 1. Java 2. PHP 3. C/C++
65

LINGUAGENS x AMBIENTES DE DESENVOLVIMENTO

1. As principais vantagens da linguagem ser desvinculada so: 1. No h dependncia de um nico fornecedor de ambiente de desenvolvimento 2. Maior controle sobre o cdigo produzido 3. A concorrncia entre fornecedores gera melhorias nas ferramentas. 2. Exemplos: JBuilder, NetBeans, Eclipse, e etc. 3. Todos os ambientes de desenvolvimento dependem do JDK-SE instalado.
66

LINGUAGENS INTERPRETADAS E COMPILADAS

1. Interpretadas, como o prprio nome j diz, so interpretadas linha a linha em tempo de execuo. Exemplos: Perl, ASP, JavaScript, Basic. 2. Compiladas, o compilador traduz o programa fonte apenas uma vez para a linguagem compilada (executvel) no importando quantas vezes o programa ir ser executado. Na compilao o fonte submetido anlise sinttica, lxica e semntica. Exemplos: Pascal, C/C++, e Java
67

REFERNCIAS BIBLIOGRFICAS
James Rumbaugh et al. Modelagem e Projetos Baseados em Objetos. Editora Campus, 1994. ISBN 85-7001-8410-X. Grady Booch. Object-Oriented Analysis and Design with Applications. Second Edition. Addison-Wesley, 1994. ISBN 0-8053-5340-2. Ivar Jacobson. Object-Oriented Software Engineering - a Use Case Driven approach. Addison-Wesley, 1996. ISBN 0-201-54435-0. Peter Coad. Object Models - Strategies, Patterns & Applications. Prentice-Hall, 1997. ISBN 0-13-840117-9. Dennis de Champeaux. Object-Oriented Development Process and Metrics. Prentice-Hall, 1997. ISBN 0-13-099755-2. Jag Sodhi and Prince Sodhi. Object-Oriented Methos for Software Development. McGraw Hill, 1996. ISBN 0-07-059574-7. Chris Zimmermann (Ed). Advances in Object-Oriented Metalevel Architectures and Reflection. CRC Pr, 1996. ISBN 0-84-932663-X. Jonathan Pletzke. Advanced Smalltalk.. John Wiley & Sons, 1996. ISBN 047-116350-3.
68

REFERNCIAS BIBLIOGRFICAS
Al Stevens. C++ Database Development. Mis Pr, 1994. ISBN 1-55-828357-9. Grady Booch and Ed Eykholt (Eds). The Best of Booch: Designing Strategies for Object Technology. Prentice-Hall, 1996. ISBN 0-13-739616-3. PAGE-JONES, Meilir. Fundamentos do desenho orientado a objetos com UML. So Paulo: Pearson Education, 2001. 462 p.2001 ISBN 85-346-1243-9 MEYER, Bertrand. Object-oriented software construction. 2nd ed. Upper Saddle River: Prentice Hall PTR, c1997. 1254 p.1997 ISBN 0-13-629155-4 BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usurio. 2a. Edio, Rio de Janeiro: Campus, 2005. 474 p. ISBN 85-352-1784-3 SIAU, Keng; EBRARY, Inc. Unified modeling language systems analysis, design and development issues. Hershey, Pa.: Idea Group Pub., c2001. 274 p.2001
69

REFERNCIAS BIBLIOGRFICAS
LARMAN, Craig. Utilizando UML e padres : uma introduo anlise e ao projeto orientados a objetos e ao processo unificado. 3. ed. Porto Alegre: Bookman, 2004. 607 p.2004 ISBN 85-363-0358-1 MARSHALL, Chris. Enterprise modeling with UML : designing successful software through business analysis. Reading: Addison-Wesley, 2000. 259 p.2000 ISBN 0-201-43313-3

LINKS
http://www.uml.org/ http://www.cetus-links.org/ http://jude.change-vision.com/jude-web/index.html http://www.visual-paradigm.com/ http://staruml.sourceforge.net/en/
70

PEA REFERNCIAS BSICAS

CATTELL, Roderic Geoffrey Galton; INSCORE, Jim. J2EE: Java 2 Enterprise Edition : criando aplicaes comerciais com a plataforma Java 2, Enterprise Edition. Rio de Janeiro: Campus, 2001. 298 p. ISBN 8535208860 DEITEL, Harvey M.; DEITEL, Paul J.. Java: como programar. 6. ed. atual. So Paulo: Prentice Hall, 2005. 1 CD-ROM (1 disco ptico : digital ; 4 3/4 pol.) ISBN 8576050196 ECKEL, Bruce. Thinking in Java. New Jersey: Prentice Hall, 1998. 1098 p. ISBN 0136597238 LEMAY, Laura; PERKINS, Charles L. Aprenda em 21 dias java. Rio de Janeiro: Campus, 1997. 639 p. ISBN 8535201041 POO, Danny C. C.,; KIONG, Derek Beng Kee,; ASHOK, Swarnalatha. Object-oriented programming and Java. 2nd ed. London: Springer, 2008. 322 p. ISBN 9781846289620.

71

PEA REFERNCIAS COMPLEMENTARES

AHMED, Khawar Zaman; UMRYSH, Cary E. Desenvolvendo aplicaes comerciais em JAVA com J2EE e UML. Rio de Janeiro: Cincia Moderna, 2002. 302 p. ISBN 8573932046. DAVIS, Stephen R.. Aprenda Java agora. Rio de Janeiro: Campus, 1997. 401 p.1 CD-ROM (1 disco ptico : digital ; color. ; 4 3/4 pol.) ISBN 8535201475 HYDE, Paul. Java thread programming: [the authoritative solution]. 3. ed. Indianpolis: SAMS, 2002. 510 p. ISBN 0672315858 LAFORE, Robert. Estruturas de dados e algoritmos em Java. Rio de Janeiro: Cincia Moderna, 2004. 702 p. ISBN 8573933755 SILVA, Ivan Jos Mecenas. Java 2: fundamentos, swing e JDBC. Rio de Janeiro: Alta Books, 2003. 378 p. ISBN 8588745623

72

Fim. Perguntas?

Prof. Fbio Tavares Dippold

Catolica de Santa Catarina campus Joinville e Jaragu do Sul ftdippold@catolicasc.org.br

mtodo 1
dado1 dado2 dado3 dado4

transferir nr

cliente saldo
criao

A linha de cdigo mais barata a linha de cdigo que voc no escreve (Steve Jobs)
73