Este documento discute princípios e padrões de projeto orientado a objetos usando Java. Ele explora valores como simplicidade, flexibilidade e comunicação, e como eles se relacionam com princípios como consequências locais, redução de repetição e expressões declarativas. O documento também discute conceitos como classes, herança, interfaces e estado, e como eles podem ser aplicados para produzir código claro e de fácil manutenção.
7. Os princípios explicam
a motivação
por trás dos padrões
http://www.flickr.com/photos/rxmflickr/3828493521/sizes/l/
quarta-feira, 6 de janeiro de 2010
8. Princípios
Os princípios são baseados nos valores e
são mais concretos
Ajudam a agir conforme os valores e são
mais fácil de serem traduzidos à
práticas
São como guias
http://www.flickr.com/photos/werkunz/3680331543
quarta-feira, 6 de janeiro de 2010
9. Agile Manifesto - Values and Principles
Individuals and Our highest priority is to satisfy the a development team is face-to-face
customer through early and continuous conversation.
interactions
delivery of valuable software.
over processes Working software is the primary
and tools Welcome changing requirements, even measure of progress.
late in development. Agile processes
Agile processes promote sustainable
harness change for the customer's
Working development. The sponsors, developers,
competitive advantage.
software over and users should be able to maintain a
Deliver working software frequently, constant pace indefinitely.
comprehensive
from a couple of weeks to a couple of
documentation Continuous attention to technical
months, with a preference to the
excellence and good design enhances
shorter timescale.
agility.
Customer
Business people and developers must
collaboration Simplicity--the art of maximizing the
work together daily throughout the
over contract amount of work not done--is essential.
project.
negotiation The best architectures, requirements,
Build projects around motivated
and designs emerge from self-
individuals. Give them the environment
Responding to organizing teams.
and support they need, and trust them
change over to get the job done. At regular intervals, the team reflects
following a on how to become more effective, then
The most efficient and effective method
plan tunes and adjusts its behavior
of conveying information to and within
accordingly.
quarta-feira, 6 de janeiro de 2010
10. Vamos aos
Princípios...
quarta-feira, 6 de janeiro de 2010
11. Consequências Locais
Estruture o código de forma que as
consequências sejam locais. Reduza os
efeitos colaterais. Diminua o custo de
fazer alterações.
quarta-feira, 6 de janeiro de 2010
12. Reduza a Repetição
Esse principio contribui para manter as
consequências locais. Quando mais cópias do
mesmo código, mais cara se torna a
mudança.
Quebre o sistema em pequenas partes, pequenos
pacotes, pequenos métodos, pequenos objetos.
quarta-feira, 6 de janeiro de 2010
13. Lógica e Dados
devem andar Juntos
Na maioria da vezes quando se altera a estrutura
dos dados, também se altera a lógica. Se eles
estivem juntos a consequência de alterar será local.
quarta-feira, 6 de janeiro de 2010
14. Simetria
Um método add pede um remove, input, output
Um grupo de métodos recebem os mesmos
parâmetros
Atributos com o mesmo ciclo de vida
Faz o código torna-se mais fácil de se ler
Se você entender uma parte, entende o todo
“A mesma idéia deve ser expressada da
mesma forma em todos os lugares”
quarta-feira, 6 de janeiro de 2010
16. Taxa de Alterações
(Rate of Change)
setAmont(int value, String currency) {
this.value = value;
this.currency = currency;
}
setAmont(int value, String currency) {
this.money = new Money(value, currency);
}
setAmont(Money money) {
this.money = money;
}
Evita Duplicidade e Criar Consequências Locais
quarta-feira, 6 de janeiro de 2010
17. Os padrões expressão um ou mais
valores de comunicação,
simplicidade ou flexibilidade
http://www.flickr.com/photos/rxmflickr/4045972780/sizes/l/
quarta-feira, 6 de janeiro de 2010
18. Motivação
http://www.flickr.com/photos/tambako/3567125378/sizes/l/
quarta-feira, 6 de janeiro de 2010
19. O Custo do Software
Custo Total
=
Custo de Desenvolver
+
Custo de Manter
quarta-feira, 6 de janeiro de 2010
20. Custo de
Manter
é maior!
Consome mais tempo
É mais propenso a erros
Tem que aprender o que o código faz
quarta-feira, 6 de janeiro de 2010
21. Os Padrões tem o objetivo
de gerar Código Claro para
o desenvolvimento futuro,
reduzindo o custo de
manutenção e melhorando
a comunicação de
programador com
programador
quarta-feira, 6 de janeiro de 2010
22. Você passa mais
tempo lendo
do que escrevendo
código
quarta-feira, 6 de janeiro de 2010
23. Classes http://www.flickr.com/photos/tambako/4112153517/sizes/l/
quarta-feira, 6 de janeiro de 2010
24. Classes e
Arquétipos
de Platão
quarta-feira, 6 de janeiro de 2010
25. Classe
“Estes dados vão juntos e essa lógica também”
Dados são alterados mais frequentemente do que
lógica.
Aprender como empacotar lógica em classes e como
expressar suas variações é essencial para se programar
de forma eficaz com orientação à objetos.
quarta-feira, 6 de janeiro de 2010
26. Super-Classe
Use herança cautelosamente
“Sou parecida com a minha superclasse, apenas um
pouco diferente”
Reduzir a quantidade de classes em um sistema é
uma melhora, na condição de as outras classes não
fiquem inchadas
quarta-feira, 6 de janeiro de 2010
27. Simple Superclass Name
Encontrar o nome perfeito é dos momentos
mais satisfatórios da vida de um programador
O nome certo implica em simplicidade e
expressividade
Encontrar o nome certo pode levar horas, dias,
meses ou até mesmo anos
quarta-feira, 6 de janeiro de 2010
28. Qualified Subclass Name
O Nome de uma sub-classe deve comunicar duas coisas
1. Com que classe ela se parece
2. No que ela é diferente
Boleto
BoletoSimples
BoletoRegistrado
quarta-feira, 6 de janeiro de 2010
29. Abstract Interface
“Aumentar o número de interfaces não diminuem o
custo do software.”
Uma nova interface é algo a mais para
compreender, documentar, debugar, organizar,
navegar e nomear.
Pague esse preço quando realmente precisar da
flexibilidade de uma interface.
quarta-feira, 6 de janeiro de 2010
30. Mudança é Ruim?
“Esses dias li uma lista com todas as razões pelas
quais mudanças ocorrem em software, negligência
do levantamento de requistos, bla, bla.... A lista
assumia que todas as mudanças eram ruins.”
quarta-feira, 6 de janeiro de 2010
31. Mudança é Ruim?
Porque a previsão do tempo é realizada para um
ano inteiro de uma só vez? Porque o tempo muda
de maneiras imprevisíveis!
Em Java, Interfaces e Classes abstratas podem te
ajudar a conseguir flexibilidade quando for preciso.
quarta-feira, 6 de janeiro de 2010
32. Interfaces
File < FileImpl
IFile < File
quarta-feira, 6 de janeiro de 2010
33. Interfaces Versionadas
O que você faz quado precisa alterar uma interface
mas não pode?
Crie uma nova interface que extende a anterior e
utilize instanceof para verificar se pode utilizar a
nova operação!
quarta-feira, 6 de janeiro de 2010
34. Interfaces Versionadas
interface Command { void run(); }
interface ResersibleCommand extends Command {
void undo();
}
...
if (recent instanceof ReversibleCommand)
((ReversibleCommand) recent).undo()
...
quarta-feira, 6 de janeiro de 2010
36. Value Object
São objetos que depois de
criados nunca mais tem seus
valores alterados.
Exemplos desse padrão na linguagem Java:
Integer, Float, String, BigDecimal, Double
quarta-feira, 6 de janeiro de 2010
37. Value Object
Transação {
int valor;
(int valor, Conta credito, Conta debito) {
this.valor = valor;
credit.addCredito(this);
debit.addDebit(this);
}
int getValor() { return this.valor; }
}
quarta-feira, 6 de janeiro de 2010
39. Subclass
É um forma de dizer “Esse
objeto é semelhante a aquele
exceto...”
quarta-feira, 6 de janeiro de 2010
40. Cuidado com o Anti-Pattern
de Hierarquias Paralelas
Duplicidade, Complexidade e Acoplamento
Contrato Produto
ContratoDeSeguro ContratoDeSeguro
ContratoDePensão ContratoDePensão
quarta-feira, 6 de janeiro de 2010
41. Inner Class
Static and Non-Static
quarta-feira, 6 de janeiro de 2010
42. Instance
Specific
Behavior
quarta-feira, 6 de janeiro de 2010
43. Condicionais
Cuidado com a Duplicidade
public void display() { public void contains() {
switch(getType()) { switch(getType()) {
case MOUSE_DOWN: case MOUSE_DOWN:
//.. //..
break; break;
case SELECT: case SELECT:
//.. //..
break; break;
case MOUSE_OVER: case MOUSE_OVER:
//.. //..
break; break;
} }
} }
quarta-feira, 6 de janeiro de 2010
44. Imagine que você agora,
precisa adicionar um novo
tipo...
Será preciso alterar todos os
métodos incluindo um nova
entrada no swtich case
statement.
quarta-feira, 6 de janeiro de 2010
45. Delegation
A lógica comum deve fica na
referring class e a especifica
nos delegates.
quarta-feira, 6 de janeiro de 2010
46. Delegation
É comum passar a referência do delegador
// Graphic Editor
public void mouseDown() {
tool.mouseDown(this);
}
// Retangle Tool
public void mouseDown(Editor editor) {
editor.add(new RetangleFigure());
}
Ou Passe o Delegator no Construtor do Delegating Object
quarta-feira, 6 de janeiro de 2010
47. Pluggable Selector
Quando existem poucas implementações
Crie todos os métodos em uma única classe e armazene os
nomes dos métodos em Strings e chame-os através de
reflection. Como é feito no JUnit:
String name;
public void runTest() {
Class[] noArguments = new Class[0];
Method method = getClass().getMethod(name, noArguments);
method.invoke(this, new Object[0]);
}
quarta-feira, 6 de janeiro de 2010
48. Anonymous
Inner Class
public class Pato {
Habilidade andar = new Habilidade() {
public void fazer() {
//...
}
};
}
quarta-feira, 6 de janeiro de 2010
49. Anonymous
Inner Class
Difícil de Testar
Como a classe não possui nome é você não
pode expressar sua intenção facilmente
Pode tornar o código mais difícil de ler
quarta-feira, 6 de janeiro de 2010
50. ?
O que você pode
fazer quando
precisa de alguma
funcionalidade que
não encaixa em
nenhum objeto
quarta-feira, 6 de janeiro de 2010
51. ?
Que tal criar uma
classe cheia de
métodos estáticos
com essas
funcionalidades
quarta-feira, 6 de janeiro de 2010
52. Library Class
public class Collections {
//..
public static <T extends Comparable<? super T>> void sort(List<T> list) {
Object[] a = list.toArray();
Arrays.sort(a);
ListIterator<T> i = list.listIterator();
for (int j=0; j<a.length; j++) {
i.next();
i.set((T)a[j]);
}
}
//..
}
quarta-feira, 6 de janeiro de 2010
53. Library Class
Não têm Estado
Difícil de Testar
Procedural
quarta-feira, 6 de janeiro de 2010
54. Estado
http://www.flickr.com/photos/tambako/2701117725/sizes/l/
quarta-feira, 6 de janeiro de 2010
55. State
Trabalha com valores que que variam ao
longo do tempo
“Olhe para o sol, espere uma hora e olhe
novo, ele já não estará mais no mesmo
lugar“
quarta-feira, 6 de janeiro de 2010
56. Cuidado!
Estado e concorrência
não se dão muito bem.
quarta-feira, 6 de janeiro de 2010
57. Separar Estados
Quando tiver dúvida,
pergunte-se se os atributos
devem nascem e morrem ao
mesmo tempo. Se a reposta
for sim, eles devem ficar
juntos.
quarta-feira, 6 de janeiro de 2010
58. Access
Mantém a Flexibilidade limitando o
acesso ao estado
quarta-feira, 6 de janeiro de 2010
59. Access
A distinção entre acessar dados
armazenados e invocar computações é
uma dicotomia das linguagens de
programação.
quarta-feira, 6 de janeiro de 2010
60. Direct Access
Acessa o estado de um objeto
diretamente.
Geralmente utilizados em métodos
acessores e construtores.
quarta-feira, 6 de janeiro de 2010
61. Legibilidade
numeroDeFilhos = 10;
porta = 1;
abrirPorta();
porta.abrir();
quarta-feira, 6 de janeiro de 2010
62. Indirect Access
Acessa o estado de um objeto através de
métodos para aumentar a flexibilidade
quarta-feira, 6 de janeiro de 2010
63. Indirect Access
“Minha estratégia padrão é permitir
acesso direto à própria classe, incluindo
inner classes, e acesso indireto à classes
clientes”
Kent Beck
quarta-feira, 6 de janeiro de 2010
64. Common State
Armazena o estado comum a todos os
objetos de uma classe.
quarta-feira, 6 de janeiro de 2010
65. Exemplo do Cartesiano
class Point {
int x;
int y;
}
Todos os atributos compartilham o
mesmo ciclo de vida.
quarta-feira, 6 de janeiro de 2010
66. Variable State
Armazena o estado que variam de
instancia para instancia em um mapa
Alta Flexibidade
Comunicação Pobre
quarta-feira, 6 de janeiro de 2010
67. Variable State
public class ObjetoFlexivel {
Map<String, Object> properties = new HashMap<String, Object>();
public Object getProperty(final String key) {
return properties.get(key);
}
public void setProperty(final String key, final Object value) {
properties.put(key, value);
}
}
Use prefixos para representar propriedades
relacionadas: border, borderColor, borderWidth...
quarta-feira, 6 de janeiro de 2010
68. Variable
Variáveis provêem um namespace para
acessar o estado.
Leitores devem entender facilmente o
escopo, o ciclo de vida e o papel de uma
variável.
quarta-feira, 6 de janeiro de 2010
69. Escopo
Local
Atributo
(Field)
Estático
+ Modificadores
(private, default, protected, public)
quarta-feira, 6 de janeiro de 2010
70. Local Variable
Variáveis Locais detém o estado de um
escopo único
quarta-feira, 6 de janeiro de 2010
71. Variável Local Coletora
Coleta Informações para uso posterior.
Geralmente são usadas no retorno de
métodos, neste caso chame de result ou
results.
quarta-feira, 6 de janeiro de 2010
72. Variável Local
Contadora
Um Tipo de Especial de Variável Coletora
que armazena a contagem de objetos.
quarta-feira, 6 de janeiro de 2010
73. Variável Local Explicatória
Quando há um cálculo complexa
armazene suas partes variáveis para
facilitar a leitura.
int top = 10;
int left = 10;
int heigth = 10;
int width = 10;
new Retangle(top, left, height, width);
quarta-feira, 6 de janeiro de 2010
74. Variável Local de Reuso
Quando você precisa utilizar o mesmo
valor mais de uma vez.
long now = System.currentTimeMills();
for (Clock each: getClocks())
each.setTime(now);
quarta-feira, 6 de janeiro de 2010
75. Field
Fields armazenam o estado de vida de
um objeto. Elas nascem e morrem junto
com o objeto.
quarta-feira, 6 de janeiro de 2010
76. Helper Field
Helper Fields guardam referências de
objetos que são usados por vários
métodos.
Se um objeto é passado por parâmetro
para muitos métodos, considere torná-lo
um field
quarta-feira, 6 de janeiro de 2010
77. Flag Field
Flag Fields indicam que o objeto pode ter
dois tipos de comportamentos diferentes.
Se houver um setter para esse field o
comportamento pode ser mudado ao
longo da vida do objeto.
Atenção: Se houver muitas consultas repetitivas a
flag para determinar o comportamento do objeto,
analise a possibilidade de usar o padrão Strategy
quarta-feira, 6 de janeiro de 2010
78. Strategy
Quando você quiser expressar que
existem formas diferentes de realizar
parte do comportamento do objeto crie
um strategy field.
Se ele puder mudar ao longo da vida do
objeto, crie um setter, caso contrário
defina no construtor.
quarta-feira, 6 de janeiro de 2010
79. Components
Atributos componentes contém objetos
ou dados que pertencem ao objeto em
questão.
Carro Motor
quarta-feira, 6 de janeiro de 2010
80. Parameter
Parâmetros comunicam o estado durante
a execução de um único método
quarta-feira, 6 de janeiro de 2010
81. Parameter
Além de variáveis não privadas, a única
forma de comunicar o estado de um
objeto para outro é através de
parâmetros.
quarta-feira, 6 de janeiro de 2010
82. Parameter
O acoplamento introduzido por um
parâmetro é bem menor do que uma
referência de permanente (atributo) de
um objeto para outro.
quarta-feira, 6 de janeiro de 2010
83. Parameter
Quando um parâmetro se repete em
muitos métodos de um objeto, é muito
provável que ele deva ser uma atributo.
quarta-feira, 6 de janeiro de 2010
86. Collection Parametor
Passa um parâmetro para coletar
resultados complicados de múltiplos
métodos
quarta-feira, 6 de janeiro de 2010
87. Collection Parametor
void listar() {
List results = new ArrayList();
addTo(results);
return results;
}
private void adicionar(List elements) {
...
}
quarta-feira, 6 de janeiro de 2010
88. Optinal Parameter
Utilizado em métodos e construtores,
também conhecido como Telescoping
Pattern
public void mascarar() {mascarar(2,2);}
public void mascarar(int decimals) {
mascarar(decimals, decimals);
}
public void mascarar(int min, int max) { ... }
quarta-feira, 6 de janeiro de 2010
89. Parameter Object
Consolida longas listas de parâmetros
usados frequentemente em um objeto
setBordaExterna ( x,y,w,h );
setBordaInterna ( x+2,y+2,w-4,h-4 );
setBordaExterna ( borda );
setBordaInterna ( borda.expandir(-2) );
quarta-feira, 6 de janeiro de 2010
90. Constant
Armazena o estado que não se altera
Utilize variáveis static final com nomes
em uppercase.
Cuidado setAlignment(CENTERED) não
comunica também como center()
quarta-feira, 6 de janeiro de 2010
92. • count: armazena contagens
• each: armazena elemento durante iterações
• result: armazena o valor que a função retornará
quarta-feira, 6 de janeiro de 2010
93. Nomeie variáveis de acordo com seus papéis
• count: armazena contagens
• each: armazena elemento durante iterações
• result: armazena o valor que a função retornará
quarta-feira, 6 de janeiro de 2010
94. Role-Suggesting Name
Nomeie variáveis de acordo com seus papéis
• count: armazena contagens
• each: armazena elemento durante iterações
• result: armazena o valor que a função retornará
quarta-feira, 6 de janeiro de 2010
95. Declared Type
Declara um tipo genérico para variáveis
List<Pessoa> candidatos =
new ArrayList<Pessoas>();
quarta-feira, 6 de janeiro de 2010
97. Eager Inicialization
Inicializa campos de um instancia em
tempo de criação
class Clube {
List<Pessoa> membros = Lists.newArrayList();
}
class Clube { ... Clube() { /* inicialização */ } }
quarta-feira, 6 de janeiro de 2010
98. Lazy Inicialization
Inicializa campos cujo valores são caros
de se calcular apenas antes de serem
usados pela primeira vez
public List<Pessoa> getMembros() {
if (membros == null) {
membros = Lists.newArrayList();
}
return membros;
}
quarta-feira, 6 de janeiro de 2010
99. Métodos
http://www.flickr.com/photos/tambako/4170480368/sizes/l/
quarta-feira, 6 de janeiro de 2010
100. Intetion-Revealing
Method
Métodos devem ter nomes que revelem
seu objetivo e sejam intuitivos para que
um potencial invocador o descubra
Customer.findById(id);
iterator.hasNext();
quarta-feira, 6 de janeiro de 2010
101. Method Visibility
public, package, protected ou private?
“Revelar o mínimo possível
garante maior flexibilidade”
quarta-feira, 6 de janeiro de 2010
102. Method Object
Esse padrão pode te ajudar a transformar
um código massivo aglomerado em um
método impossível em um código legível,
limpo e claro, que revela gradualmente
suas intenções ao leitor.
quarta-feira, 6 de janeiro de 2010
103. Method Object
Aqueles métodos, cheios de variáveis
temporárias e um montão de parâmetros
são ótimos candidatos se transformarem
em um objeto, tentar apenas fazer um
Extract Method, resultaria em sub-
métodos difíceis de nomear com dezenas
de variáveis.
quarta-feira, 6 de janeiro de 2010
104. Method Object
1. Crie uma classe com o nome do método
2. Crie um atributo para cada parâmetro, variável local e atributos do objeto
original usados no método.
3. Crie um construtor que recebe os parâmetros e atributos.
4. Copie o método original para a nova classe substituindo seus parametrôs
pelas referencias dos atributos da nova classe.
5. Altere a chamada do método na classe original
6. Se atributos eram definidos na classe original, obtenha-os por getters e
defina-os.
7. Agora faça os extract methods necessários para tornar o código mais
legível.
quarta-feira, 6 de janeiro de 2010
105. Overidden Method
Métodos sobre-escritos são
uma forma clara de se expressar
variações.
quarta-feira, 6 de janeiro de 2010
106. Overloaded Method
Métodos sobrecarregados representam
formas alternativas de se invocar o
mesmo método.
Todos as versão sobrecarregadas devem
servir para o mesmo propósito, caso
contrário é melhor procurar um novo
nome.
quarta-feira, 6 de janeiro de 2010
107. Method Return Type
Identificam se o método é uma
Procedure (void) ou uma Function
(Object).
Generalize o tipo de retorno para
esconder detalhes de implementação.
quarta-feira, 6 de janeiro de 2010
108. Comentários
Expresse o máximo de informação
possível através de nomes e da
escreva
estrutura do seu código,
comentários somente para o
que não estiver óbvio.
Evite comentários redundantes.
quarta-feira, 6 de janeiro de 2010
109. Helper Method
São métodos private que compõe um
método público e tornam seu o código
mais legível e coeso.
quarta-feira, 6 de janeiro de 2010
110. Debug Print Method
Implemente o método toString() dos
objetos de forma a identificar seu
valor facilmente, essa prática pode
reduzir significativamente o tempo de
debugging .
quarta-feira, 6 de janeiro de 2010
111. Conversion
Quando você precisa converter
um objeto de um tipo em outro de
um tipo diferente.
quarta-feira, 6 de janeiro de 2010
112. Conversion Method
class Farenheight {
public Celsius convertToCelsius(Farenheight f) {
...
}
}
quarta-feira, 6 de janeiro de 2010
113. Conversion Contructor
class Farenheight {
public Farenheight (Celsius c) {
...
}
}
quarta-feira, 6 de janeiro de 2010
114. Construtor
Deve representar a criação de um
objeto
quarta-feira, 6 de janeiro de 2010
115. Factory Method
Forma alternativa ao Construtor para
representar a criação de um objeto em um
método estático.
Calculadora c = Calculadora.criar();
Muito útil quando se precisa de caching ou
retornar diferentes subclasses dependendo
dos parâmetros.
quarta-feira, 6 de janeiro de 2010
116. Internal Factory
Quando criar ou calcular um objeto for
complexo, crie um método que cria e
retorna o novo objeto.
getX(){
if (x == null)
x = computeX();
return x;
}
quarta-feira, 6 de janeiro de 2010
117. Collection
Accessor Method
Como prover acesso a uma Collection?
public List<Livro> getLivros() {
return livros;
}
Qual o problema dessa
implementação?
quarta-feira, 6 de janeiro de 2010
118. Collection
Accessor Method
public List<Livro> getLivros() {
return livros;
}
Apesar de dar máxima flexibilidade,
você perde o controle sobre um
atributo de seu objeto que pode ser
invalidado sem que você saiba.
quarta-feira, 6 de janeiro de 2010
119. Unmodifiable Wrapper
public List<Livro> getLivros() {
return Collections.unmodifiableList(livros);
}
quarta-feira, 6 de janeiro de 2010
120. Collection Accessor Method
public void addLivro(Livro livro) {}
public int getQuantidadeDeLivros() {}
public Iterator getLivros() {}
Uma boa prática é fornecer métodos que
para operações limitadas e significativas.
Isso melhora a coesão, torna o código mais
legível e testável. E você fica no controle.
quarta-feira, 6 de janeiro de 2010
121. Boolean Setting Method
procure usar
cache.ativar();
cache.inativar();
ao invés de
cache.setStatus(true);
cache.setStatus(false);
quarta-feira, 6 de janeiro de 2010
122. Boolean Setting Method
a menos que
if (booleanVar)
cache.ativar();
else
cache.inativar();
nesse caso
cache.setStatus(booleanVar);
quarta-feira, 6 de janeiro de 2010
123. Getting
Method
quarta-feira, 6 de janeiro de 2010
124. Setting Method
void setX(int x){ ... }
void centered(){ ... }
quarta-feira, 6 de janeiro de 2010
125. http://www.flickr.com/photos/pong/288491653/sizes/o/
Safe Copy
public void getLivros() {
List<Livro> result = new ArrayList<Livros>();
result.addAll(this.livros);
return result;
}
quarta-feira, 6 de janeiro de 2010
126. Coleções
http://www.flickr.com/photos/tambako
quarta-feira, 6 de janeiro de 2010
127. Array
Simples e Pouco Flexíveis
Tamanho Fixo
Sintaxe de Acesso Simples
Acesso Rápido
quarta-feira, 6 de janeiro de 2010
128. Iterable
Interface básica que permite apenas que
se realizem iterações e nada mais.
quarta-feira, 6 de janeiro de 2010
129. Collection
Oferece Adição, Remoção e Verificação de
Presença.
quarta-feira, 6 de janeiro de 2010
130. List
Elementos Ordenados que podem ser
acessados por sua localização.
quarta-feira, 6 de janeiro de 2010
131. Set
Um conjunto de elementos sem
duplicidade.
quarta-feira, 6 de janeiro de 2010
132. SortedSet
Um conjunto ordenado de elementos
sem duplicidade
quarta-feira, 6 de janeiro de 2010
133. Map
Um coleção de chaves ligadas a valores
quarta-feira, 6 de janeiro de 2010
134. Comunicação
As colections Java comunicam o que
são o que elas fazem. Esse é o grande
beneficio de ter padrões.
quarta-feira, 6 de janeiro de 2010
135. Referência
Leia o Livro!
http://www.amazon.com/Implementation-Patterns-Kent-Beck/dp/0321413091
quarta-feira, 6 de janeiro de 2010
136. OBRIGADO!!!!
http://www.flickr.com/photos/tambako
quarta-feira, 6 de janeiro de 2010