No exercício em questão, a classe principal poderia ter usado um map pra guardar os dados do aluno. A classe DadosAluno não serve pra absolutamente nada, apenas pra complicar.
Bem lembrado…
Mas só pra ficar claro, apenas estou dizendo que getter/setter viola encapsulamento. Não estou dizendo pra não usar getter/setter no JSF, ou injetar dependência apenas via construtor no Spring. Se esta usando frameworks que exigem getter/setter, não tem porque lutar contra eles. Melhor focar no que sua aplicação JSF ou Spring precisa fazer, afinal, os usuários/clientes da sua aplicação não ligam se ela segue princípios OO.
Encapsulamento é um princípio importante que vale a pena ser seguido, mas em software de larga escala, com maior complexidade, e não para as aplicações CRUD tipicamente criadas com esses frameworks.
O ponto é que, didaticamente, essa classe acaba se justificando para que “os alunos aprendam”. Não importa se é encapsulamento, herança, agregação, existe meio que um bloqueio que torna incapaz todo e qualquer ser que tente ir contra tal corrente de pensamento.
E isso se explica, afinal, qualquer sistema legado (vamos considerar só os legados) vai possuir um sem número de classes “anêmicas”, cuja principal (e única) razão de ser é manter os dados em memória enquanto determinado trecho do código é executado (algo como pegar no DAO com ORM, transportar até a controller, copiar para o helper e enviar para onde será utilizado).
É como se acostumou a fazer e a maioria faz no automático.
A justificativa é sempre “orientação a objetos”.
Mas eles existem justamente por conta de modelagem orientada a banco de dados, afinal, precisa-se representar os dados em memória e “despachar” para algum lugar.
Sim, mas a questao que no caso do Java fica muito verboso para atender isso.
Tambem trabalho orientado a banco, as classes sao diretamente as entidades do banco. A equipe usa property do C#, que quase nunca sao usados os recursos OO, mas é bem mais limpo do que getters/setters da linguagem Java.
Na época que eu trabalhava com OOP foi no saudoso Delphi com Object Pascal, criando componentes para VCL. Para dados do usuário nunca vi grandes vantagens em modelo OO.
No PHP, se eu bem me lembro, existia (ou ainda existe, não sei) um framework ORM que tinha um funcionamento fantástico, se não me engano, se chamava ActiveRecorder e teria sido inspirado em algo vindo do Ruby on Rails.
Basicamente, não havia classes de domínio, apenas a configuração do ORM.
Uma big corp que pagou milhões por uma aplicação CRUD com hibernate não pode simplesmente “deixar de usar” o sistema por pior que ele tenha ficado. Mas fora essas casos, alguém ainda usa Hibernate?
Bom, você ainda vai estar usando os objetos Scanner e System…
A melhor maneira de aprender OO é criando front-ends porque a pessoa pode usar a biblioteca de componentes disponíveis, em pouco tempo ela estará criando seus próprio componentes. Muito melhor que esses exercícios de OO que pedem pra pessoa já sair modelando um problema nada a ver com OO usando OO.
Sério, não vejo sentido nisso.
Eu entendo que a questão do OO e o processo de aprendizado está errado.
Teoricamente, você deveria ser ensinado a pensar em OO e não inserir OO numa linguagem, forçando que o entendimento de qualquer conceito OO esteja associado à esta ou àquela linguagem.
Eu comecei com C++, apenas estruturado (ironia, não?). Passei para PHP (estruturado), depois, java.
Então, quis retornar ao PHP, estudar PHP OO e tive imensa dificuldade, uma vez que tudo o que eu entendia do conceito de OO estava associado com a maneira que o java trata OO, ou melhor, com a maneira como fui ensinado a associar a sintaxe java (e suas peculiares saídas pela tangente) com OO. Resultado: desisti de aprender PHP OO.
Dia desses, vi um vídeo em que alguém dizia (não me recordo quem) que uma das dificuldades em se aprender um novo idioma se deve ao fato de que cada idioma possui uma maneira diferente de pensar. Assim sendo, eu não consigo aprender russo, pensando como brasileiro que fala português. A construção das sentenças, a maneira de interagir muda.
Isso se aplica, também, à OO (e a N outras coisas, incluindo lógica de programação). Se você aprender isso atrelado a uma linguagem, tem grandes chances de estar falhando miseravelmente.
Padrão ActiveRecord, embora misture responsabilidades, para CRUDs simples é super prático em ferramentas que AR faça parte de toda stack, como você citou o caso do Rails. C# também já teve uma implementacao do AR com NHibernate, o Castle, mas não pegou.
Uso hibernate sem XML há, pelo menos, 6 anos. E, entendo, que o hibernate sacrifica algumas coisas em prol de outras. Não é esse o preço dos frameworks? Não é assim com o rails do ruby ou o próprio laravel do php?
O que me refiro ali é não existir a necessidade de criar as estruturas da classe para representar uma tabela (a entidade, seus campos privados e métodos de acesso), tendo, em um nível acima, todos os métodos necessários para o CRUD (como o active record funciona).
Isto, da maneira que se comporta é, inclusive, abordado por Robert Cecil Martin, no livro sobre clean code, quando o mesmo fala sobre estruturas de dado e objetos. Ele é bem sucinto ao comentar sobre active records e foca, infelizmente, no ponto negativo da coisa.
