-
Implementar a validação de CNPJ e usar as funções removeSimbolo e calculaDigito (que devem ser movidas de PessoaFisica para Pessoa)
-
Mostrar que com herança, não podemos ter um professor que é aluno (ou vice versa).
-
Mostrar a duplicação de dados de PF entre um aluno que já é professor e que, ao alterar os dados de PF em um, estes ficam desatualizados no outro.
-
Reimplementar as classes de pessoas agora sem utilizar herança em toda a hierarquia, para mostrar como cadastrar uma pessoa como aluno e funcionário:
-
PessoaFisica e PessoaJuridica herdam de Pessoa
-
Aluno vai agregar PessoaFisica (Aluno é o todo e PF é a parte), onde ao excluir Aluno, não necessariamente exclui PF.
-
Professor vai agregar PessoaFisica
-
-
Mostrar composição (todo-parte) com o exemplo da Venda e ItemVenda, onde ao excluir a venda, exclui os itens.
Criação de projeto com classes de diferentes partes de um sistema de vendas, para mostrar como a falta de uso de pacotes torna a visualização das classes complexas.
-
Definição de pacotes
-
Padrão de nomes de pacotes
-
Refatorar projeto para mover classes para pacotes
-
Utilizando suas classes de outro pacote
-
Usar o modulo11 para calcular o dígito verificador da matrícula.
-
Mostrar que agora como Aluno e Professor não herdam de PessoaFisica, eles não podem acessar o métodulo modulo11 que é privado. Se quisermos que somente as classes dentro do pacote atual acessem tal método, podemos colocá-lo como package. Package tem maior restrição que protected. Se realmente não quisermos que nenhuma classe fora do pacote acessem o método, ele deve ser package. Se o método realmente tiver que ter seu acesso restrito às classes do pacote (caso seja algo interno que não deve ser exposto, como a placa de circuitos de um controle remoto), ao colocá-lo como protected, consegue-se contornar a restrição de acesso criando-se uma sub classe (isto pode ser impedido se a classe for final). Assim, para realmente restringir o acesso somente às classes do pacote, usa-se visibilidade package.