12. Paradigmas da programação; Programação orientada por objectos; Pacotes – Fundamentos de Programação

Paradigmas da programação
Programação orientada por objectos
Modularização em pacotes

 Enumerações
 Instrução de selecção switch
 Gama limitada dos tipos inteiros
2013/2014 Fundamentos de Programação 2

 Programação esparguete
 Programação estruturada
 Programação procedimental
 Programação baseada em objectos
 Programação orientada por objectos
Progresso

 Forma
 Instâncias de tipos escalares ou arrays
 Instruções organizadas em estruturas de controlo
 Sem modularização
 Melhorias
 Melhora estruturação do fluxo de controlo dos programas
 Possibilita raciocínio formal acerca de programas
 Aumenta legibilidade dos programas face ao passado
(programação «esparguete»)
Organização do código em módulos, i.e.,
«cápsulas» com objectivos bem definidos
contendo uma implementação oculta e
expondo ao exterior uma interface. A
modularização favorece a abstracção.

 Forma
 Instâncias de tipos escalares ou arrays
 Instruções e estruturas de controlo organizadas em rotinas
 Modularização em rotinas
 Funções – Devolvem resultado de um cálculo
 Procedimentos – Agem sobre o mundo, modificando-o
 Melhorias
 Possibilita encapsulamento
 Facilita reutilização
 Melhora localização de erros e facilita manutenção
 Possibilita maximização da coesão e minimização das ligações

 Forma
 Instâncias de tipos escalares, de arrays ou deTAD
 Rotinas relacionadas organizadas emTAD
 Modularização
 TAD – Conjunto de dados e operações
 Operações – Rotinas que operam sobre instâncias deTAD
 Melhorias
 Melhora encapsulamento (dados e operações relacionadas)
 Possibilita ocultação da informação
 Muda perspectiva sobre os problemas
Ou programação centrada
nos dados.
Tipos
abstractos de
dados

 Forma
 Instâncias de classes (objectos), de tipos escalares, de arrays ou deTAD
 Rotinas relacionadas organizadas emTAD
 Rotinas relacionadas organizadas em classes
 Modularização
 Classes – Modelos para objectos com um dado comportamento
 TAD – Conjuntos de dados e operações
 Operações – Rotinas que operam sobre instâncias deTAD ou sobre objectos
 Métodos – Implementação das operações
 Melhorias
 Introduz noções de extensão e especialização
 Muda drasticamente perspectiva sobre os problemas

 Assenta sobre
 Programação estruturada – Controlo de fluxo
 Programação procedimental – Rotinas
 Programação centrada nos dados –TAD e operações
 Vantagens
 Melhor modularização
 Melhor encapsulamento
 Maior possibilidade de reutilização
 Possibilidade de extensão e especialização
 Maior expressividade
 Maior flexibilidade
 Maior robustez

 Interface
 Operações – Implementadas por um ou mais métodos
 Propriedades – Podem ou não ser implementadas
usando atributos
 Implementação
 Métodos – Implementação de operações
 Métodos auxiliares – Usados pelos outros métodos
 Atributos – Dados que são parte da implementação

 Tudo (ou quase) são objectos
 Objectos têm
 responsabilidades,
 comportamentos e
 propriedades
 Organização de programas reflecte realidade…
 …mas os objectos são personificados
Na linguagem usada pelos programadores é muito comum e útil a
prosopopeia. Por exemplo, «depois pede-se a rapidez ao carro»
corresponde a car.speed() ou car.getSpeed().

 Análise do problema
 Que objectos existem?
 Que responsabilidades têm?
 Como colaboram?
 Como classificar os objectos?
 Desenho da solução
 Que classes definir?
 Que objectos construir?
 Que responsabilidades lhes atribuir?
 De que forma os fazer colaborar?

 Classes
 São tipos
 São modelo para objectos com características comuns
 Declaram-se ou definem-se
 Definem conjunto de possíveis objectos
 São nomes comuns: humano, carro, …
 Objectos
 São instâncias de classes
 Constroem-se
 São nomes próprios: Manuel Silva, o carro do Manuel, …

 Classes
 Favorecem abstracção
 Permitem encapsulamento
 Possibilitam reutilização
 Objectos
 Representam entidades
▪ reais (e.g., carro) ou
▪ virtuais (e.g., compra)
 Têm identidade
 Têm estado observável através da interface
Consumidor só conhece
interface.
Implementação oculta.
Por especialização ou por
instanciação.

 Tipos de referência
 Classes de identidade ou referência
▪ Identidade é relevante
▪ Igualdade usualmente não é relevante
 Classes de igualdade ou valor
▪ Identidade não é relevante
▪ Igualdade é relevante
 Tipos de valor
 Identidade não é relevante
 Igualdade é relevante
E.g., classes Java.
Tipos primitivos em
Java.
E.g., String,
Rational, Point
E.g., Person, Gang,
Car

 Definem características
(propriedades e
operações) comuns a
todas as instâncias
Car
- licenseNumber : String
- model : String
- yearBuilt : int
- lastInspectionDate : LocalDate
+ getLicenseNumber() : String
+ getModel() : String
+ getLastInspectionDate() : LocalDate
+ getYearAge() : int
+ getNextInspectionDate() : LocalDate
+ isInspected() : boolean
+ setInspectedToday()
Propriedades
Operação
implementaçãointerface

 Instâncias de classe de
referência com
identidade e com
propriedades bem
definidas
johnsCar : Car
licenseNumber = 00-AA-00
model =VW-GTI-TDI-SLK
yearBuilt = 2005
lastInspectionDate = 2014-11-20

 Operações
 Parte da interface da classe
 São invocadas
 Métodos
 Parte da implementação da classe
 São executados quando se invoca a sua operação
 Uma única operação pode ser implementada por
vários métodos
Como? Usando polimorfismo de
subtipos, que se verá mais tarde.

 Inicializam instâncias/objectos em construção
 Colocam instâncias/objectos em estado
inicial válido, i.e., cumprindo a condição
invariante de instância

 Modificadoras – Alteram estado do objecto
(procedimentos)
 Não modificadoras – Não alteram estado do
objecto
 Inspectoras – Devolvem propriedade do objecto e não
têm efeitos laterais (funções)
 «Alter-modificadoras» –Alteram estado do programa
ou do seu ambiente (procedimentos) sem alterar
estado do objecto

 Cada operação deve ter um objectivo (ou uma
função) único e bem definido
 Operações inspectoras – Nome reflecte o que
devolvem
 Outras operações – Nome reflecte acção realizada
 Uma operação não deve ser simultaneamente
inspectora e modificadora (função e
procedimento)

 Classes são «pseudo-objectos» fábrica das suas instâncias
 «Pseudo-objectos» fábricas têm características de classe
 Declaração de atributos e métodos de classe: com static
 Boas práticas
 Evitar características de classe, em geral
 Usar para definir constantes
 Exemplo
 Math.PI
Por oposição às
características de
instância.

final Car johnsCar = new Car("00-AA-00", …);
final Car janesCar = johnsCar;
final Car fredsCar = new Car("01-35-AP", …);
johnsCar, janesCar : Car
licenseNumber = 00-AA-00
…
fredsCar : Car
licenseNumber = 01-35-AP
…

final Car johnsCar = new Car("00-AA-00", …);
final Car janesCar = johnsCar;
final Car fredsCar = new Car("01-35-AP", …);
johnsCar : «ref» Car
: Car
licenseNumber = 00-aa-00
…
: Car
licenseNumber = 01-35-AP
…
janesCar : «ref» Car
fredsCar : «ref» Car
Referências: Objectos:

johnsCar : Car
licenseNumber = 00-aa-00
model =VW-GTI-TDI-SLK
yearBuilt = 2005
lastInspectionDate = 2013-11-20
Car
- licenseNumber : String
…
+ getLicenseNumber() : String
…
Nome da
classe
AtributosOperações
Acesso Nome do objecto
Atributos Valores dos atributos

Classe variável;
variável = null;
Classe outraVariável = null;
Classe aindaOutraVariável =
new Classe(…);
Inicialização da referência com o valor
especial null, que indica que referência não
referencia qualquer objecto.
Declaração da referência variável, não
inicializada, capaz de referenciar objectos da
classe Classe.
Construção de um novo
objecto e de uma referência
que o referencia.
Construção de uma
referência com valor inicial
nulo.
Construçãodareferência
Atenção! Os tipos primitivos do Java (int, float, char, etc.) são tipos de
valor. Não há referências para eles.As variáveis declaradas são uma
instância do tipo primitivo. Por exemplo:
int anInteger;
anInteger = 10;
int anotherInteger = 20;
Construção do novo objecto
Construçãodareferência

 Usa-se operador . (ponto)
 Objecto (característica de instância)
referênciaParaObjecto.característica
 Classe (característica de classe)
Classe.característica
Se a referência for nula
(null), é lançada a excepção
NullPointerException.
Ou membros.

 Tudo o que pode ser privado deve ser privado!
 Regras gerais
 Todos os atributos devem ser privados
 Os construtores são usualmente públicos
 As operações devem ser públicas
 Os métodos auxiliares devem ser privados
As constantes, pelo contrário,
podem e muitas vezes devem ser
públicas.

 Interface
 Operações não privadas
 Constantes não privadas
 Implementação
 Métodos privados
 Atributos privados
 Corpos dos métodos
 Contrato
 Pré e pós-condições das operações e métodos
 Manual de utilização
 Comentários de documentação da classe
 Comentários de documentação de cada característica pública
não privado ≠ público
etc.

 Características ou membros podem ser
 private – acesso apenas por outros membros da
mesma classe
 package-private (sem qualificador) – adicionalmente,
acesso por membros de classes do mesmo pacote
 protected – adicionalmente, acesso por membros de
classes derivadas (a ver nas próximas aulas)
 public – acesso universal
Acessibilidadecrescente
Há promiscuidade entre objectos da
mesma classe! Cuidado!
Que é isto? Próximo diapositivo…

Pacote Pacote
Classe
Rotina
Rotina
Rotina
Classe
Rotina Rotina
Rotina
Classe
Rotina
Rotina
Rotina
Rotina
Classe
Rotina
Rotina
Classe
Rotina
Rotina
Rotina
Rotina

 Conjuntos de classes com relação lógica forte entre si
 Exemplos
 java.util
 org.junit
 Convenções de nomes
 Só minúsculas
 Sem separação entre palavras
 Abreviaturas e siglas aceitáveis
 Prefixo é nome DNS invertido (e.g., pt.europeia)
 Elementos após prefixo podem ser unidades
organizacionais (e.g., pt.europeia.fp)

 Interface
 Classes públicas
 Membros não privados de classes públicas
 Implementação
 Para além da implementação das classes…
 … todas as classes privadas de pacote (package-
private)

 java
 lang
 util
 org
 junit
 omg
 pt
 europeia
▪ fp
▪ eda
 Hierarquia aberta
 Não têm declaração isolada
 Cada ficheiro .java declara o pacote a que
pertence
package pt.europeia.fp
public class Game {
…
}
Game.java
package pt.europeia.fp
public class Player {
…
}
Player.java

 Relevante quanto a nomes
 Organização lógica (como directórios)
 Menor colisão de nomes
 Irrelevante quanto a categorias acesso
 Pacote e subpacote são independentes
 Membros do subpacote não o são do pacote
 Membros do pacote não o são do subpacote

The type top.AtTop is not visibleThe type top.bottom.AtBottom is not visible

 Uma só classe pública por ficheiro
 Classe pública em ficheiro com mesmo nome
 Número arbitrário de classes privadas de
pacote (package-private) por ficheiro, mas…
 Boa prática: Uma só classe por ficheiro!

 Usualmente, à hierarquia de pacotes
corresponde uma hierarquia de directórios
com os ficheiros correspondentes
Depende da
implementação do Java.
No Eclipse
(directórios/pastas)
No Eclipse
(pacotes)

 Classes são modelos
 Objectos são instâncias classes de referência
 Em Java variáveis não são instâncias de classes,
mas sim referências para instâncias de classes
 Tudo o que pode ser privado deve ser privado
 Classes devem organizar-se em pacotes

 Paradigmas da programação
 Programação orientada por objectos
 Modularização em pacotes

12. Paradigmas da programação; Programação orientada por objectos; Pacotes – Fundamentos de Programação

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a 12. Paradigmas da programação; Programação orientada por objectos; Pacotes – Fundamentos de Programação

Mais de Manuel Menezes de Sequeira

Último

12. Paradigmas da programação; Programação orientada por objectos; Pacotes – Fundamentos de Programação

Notas do Editor