17 de mai de 2011

Introdução a Programação Orientada a Objetos

Vamos à parte 2 da aula 2:


Exercício: A partir do desenho, extrair classes com atributos e métodos. Não tenho o desenho – creio que ficaram nos slides passados pelo instrutor...

Texto sobre o desenho (aproximado):
Abertura de conta: o Cliente traz os documentos para o gerente. O gerente confere os documentos e cadastra o cliente. Depois, o gerente oferece 2 produtos ao cliente: limite e cartão de crédito. O gerente consulta os órgãos de proteção ao crédito e se a resposta for negativa não libera o produto para o cliente. O Gerente pede para o cliente fazer o depósito inicial. A caixa recebe o depósito e ativa a conta corrente.

Dividindo em frases:
  1. gerente cadastra cliente
  2. cliente escolhe serviço
  3. gerente consulta situação do cliente junto aos órgãos de crédito
  4. cliente faz um depósito inicial no caixa
  5. caixa ativa a conta do cliente

entidades/classes: cliente, serviço, órgãos de crédito
  • gerente não vira classe, pois ele “apenas” realiza a tarefa de cadastrar o cliente e conferir seus documentos
  • deposita na conta ou no caixa? Qual é o objeto que deve ser modelado?
    A caixa é o meio físico para acessar a conta. Logo a conta é que é o item manipulado. Além disso, a conta pode ser manipulada a partir de diversos pontos, tais como pelo terminal de auto atendimento, pelo internet banking ou mesmo pelo caixa do banco. Por isso foi criado um objeto “conta” com os métodos despositar e ativar; cada operação realizada na conta, independente do meio, chamará sempre os métodos já existentes na conta;
  • Deve-se tomar cuidado ao modelar baseado em experiências prévias. Exemplo: no mundo real um banco oferece vários outros servíços como poupança, investimentos, previdência privada, títulos de capitalização. Mas no exercício foram mencionados apenas dois: limite e cartão de crédito. Logo apenas estes dois devem ser inseridos;
  • os órgãos de proteção ao crédito (Serasa, SPC, CCF, etc) não estão no escopo deste sistema, e cada um pode ter os seus métodos próprios de consulta. Por isso foi feito apenas um esboço da classe e de sua herança.


Estruturas e relacionamentos

  • relacionamentos entre as classes: visam representar o comportamento no mundo real
    • exemplo: relacionamento entre professor e alunos: aula
  • diagrama de classes – representação estática


  • Leciona Para: nome do relacionamento
  • Lecionador, Aprendiz: papéis. Cada relação entre os métodos gera um papel. Por exemplo: o método “lecionar” da classe professor deixa o professor com papel de lecionador e o aluno com papel de aprendiz.
    O método professor.aplicarProva() deixa o Professor com papel de “avaliador” e o aluno com o papel de “avaliado”.
  • 1 e 1...x: Cardinalidade. Indica o mínimo e o máximo de objetos que entram no relacionamento. Neste caso, 1 professor dá aula para 1 a x alunos; 1 a x alunos só podem estar em aula com 1 professor.

    Tipos de associação

  1. Composição
    As partes compõem um todo, e se o todo sumir elas somem.

Exemplo: não existe galho sem árvore
Outro exemplo: pastas e subpastas. Não tem como criar uma subpasta sem criar a pasta antes. (pasta = árvore, subpastas = galhos)

  1. Agregação
    as partes compõem um todo, mas podem existir sozinhas

Exemplos: as árvores e pássaros não precisam que exista uma floresta para eles existirem. Mas podem fazer parte de uma.

  1. Herança / Generalização
    Conjunto mais geral para um mais específico.
Voltando ao caso do banco, podemos ter a classe “Conta” (mais geral) que é a generalização das classes ContaCorrente e ContaPoupança. Ou temos as classes ContaCorrente e ContaPoupança, das quais pegamos os atributos e métodos semelhantes e jogamos numa classe “geral”, a classe Conta:


  • Dependência direta: ocorre quando a existência de uma classe depende da existência de outra.
    No exemplo: só pode existir um item no pedido... se existir o pedido.



    Obs: neste tópico do GUJ tem uma explicação bacana também.



Nenhum comentário: