Java é um linguagem OO porém amplamente usada de forma procedural?

Mas porque livrar-se dos get’s e set’s ? Não há problema algum em usá-los, desde que eles reflitam o contrato de operação da classe. O problema é usá-los de forma que ele exponha a implementação do objeto. Por exemplo, é perfeitamente plausível um métod getText() e um método setText() para um componente de caixa de texto, pois isso faz parte do contrato do componente. Por outro lado, seria uma completa bagunça se houvesse um setSize() no ArrayList por exemplo, de forma que você alterasse uma variável que guarda o tamnho da lista mas sem remover apropriadamente seus componentes, gerando uma inconsistência no objeto.

Ok! me expressei mal com relação a se livrar! Mas voltando ao foco da pergunta. Não sei sua experiência, mas você não acha que os frameworks e até mesmo especificações jee anteriores 1.4 e 5 fizeram com que tivessemos classes com get e set desnecessários?

Bem, acho que precisaríamos analisar cada caso. Particularmente, eu não conheço muito sobre frameworks de forma que eu possa falar de uma maneira geral, então tenho que ser mais específico. Ultimamente tive mais contato com o Hibernate/JPA. Sinceramente, não vejo problema algum em modelar classes que representem entidades, ou então os chamados Entity Beans. Por exemplo, eu não vejo sentido em existir um método cadastrar() em uma classe de entidade chamada PessoaFisica, como já vi em modelagem UML de gerente por aí. Se o resultado da modelagem é uma entidade, apenas com gets/sets acho que não há motivo para correr para as montanhas. Agora, se o sistema começa a virar um emaranhado apenas de classes com get/set e métodos estáticos operando sobre eles, aí é algo para se estranhar.

Ok. Mas em OO o objeto não deve possuir estados e comportamentos? Em um modelo ORM como eu definiria esse comportamentos?

A meu ver, basta você adicionar métodos que representem esse comportamento na sua classe. Por exemplo, talvez tenha sentido você criar uma classe Empresa, que possa ser mapeada para uma tabela no banco de dados e essa classe Empresa tenha um método Funcionario contratar(PessoaFisica f). Nunca vi uma regra que diga que você não possa fazer isso.

Acredito que as principais causas do BOLOVO são estas que vc citou mesmo: Falta de conhecimento em OO, frameworks e o patterns sugeridos pela SUN. Porem tem que observar os recursos tecnológicos disponíveis na época, problemas decorrentes da evolução dos artefatos tecnológicos e do conhecimento são coisas naturais (vide EJBs).

vagner.oliveira2:

Será que é possível fazer um sistema 100%OO onde meu objeto possa ter comportamentos e estados mas que ao mesmo tempo consiga utilizar-se framework como hibernate, jpa?. Será que
é possível se livrar dos benditos get e sets?
Desculpem-me caso não tenha me expressado bem em alguns pontos.

OO é uma idéia que se não me engano surgiu nos anos 60 e até hoje surgem linguagens tentando implementar esta idéia da melhor maneira. Hibernate, JPA e etc… surgiram como uma “saida” para construirmos softwares OO utilizando banco de dados relacionais, tomando isto como base podemos dizer que um sistema para ser 100% OO deveria considerar o banco de dados tambem OO, caso fosse utilizado algum.

flws

Concordo com o fantomas. Nos velhos tempos do EJB 1 e 2, muitos dos frameworks que obedecem às melhores práticas ainda não existiam.
No entanto ainda acho que o problema maior é a falta de conhecimento. Principalmente no Brasil, há 15 anos atrás a Orientação a Objetos não era utilizada comercialmente como é hoje, e a maioria dos desenvolvedores ainda tinham um paradigma muito procedural, vindo das linguagens tipo Clipper, Cobol, etc. Esta falta de conhecimento e experiência fez com que pegássemos algumas recomendações da época (o pattern TO da Sun, por exemplo) e o utilizássemos indiscriminadamente em qualquer projeto, mesmo em sistemas não distribuídos! Este foi um dos fatores para a “geração automática de getters e setters nas classes”, e alguns outros hábitos como este ainda perduram. Acho que eles até podiam retirar este recurso dos IDEs

Acho que tudo faz parte de uma evolução natural , tanto tecnológica quanto de conhecimento. Agora estamos falando de TDD, de Aspectos, de DDD e outras práticas que já existem há muitos anos.

Acredito que as principais causas do BOLOVO são estas que vc citou mesmo: Falta de conhecimento em OO, frameworks e o patterns sugeridos pela SUN. Porem tem que observar os recursos tecnológicos disponíveis na época, problemas decorrentes da evolução dos artefatos tecnológicos e do conhecimento são coisas naturais (vide EJBs).

Perdoem a intromissão, mas Hibernate/JPA não levam à falta de utilização de OO. Explico: se alguém quiser introduzir um determinado comportamento, com gets/sets, é só colocar o método (ou atributo) e marcar com @Transient. Se quiser colocar métodos de outros tipos, é mais fácil ainda, nem precisa de @Transient (já que métodos fora do padrão não são mapeados).

Vale lembrar que quem dita o que é mapeado é a anotação de Id (@Id ou @EmbeddedId), ou seja, se ela estiver em um atributo, os atributos são mapeados (e devem ser marcados com @Transient); se estiver em um getter (setter não vale), só colocar o @Transient nos getters.

[]'s

Eu acho que sim… Java é uma linguagem OO usada amplamente de forma procedural… Grande parte dos projetos que vi por aí tem uma camada de entidades burras e uma camada de EJB’s com a lógica do negócio…

Os fatores que contribuíram pra isso são diversos, tais como as specs de ejb anterior a 3.0, os Blueprints da sun, o padrão java beans e até mesmo alguns livros que pregam esse design.

O que eu acho curioso é que em grande parte dos projetos que ví assim, a equipe realmente acreditava que estava utilizando OO. Orientação à objetos é muito mais amplo que utilizar herança para evitar a duplicação de atributos, porém parece que grande parte dos desenvolvedores não tem essa noção.

Eu tento evitar ao máximo gets e sets nos meus projetos, mas há situações que não tem como. O Hibernate/JPA não depende do padrão javabeans, se você anotar o atributo ID ao invés do getter. Agora se você utiliza JSF pra preencher seus objetos de domínio nos formulários, será obrigado a criar os gets e sets. É uma pena ele não utilizar reflection pra isso.

O que costumo fazer é criar os gets e sets nestes casos, porém eu não os utilizo para operações de negócio… prefiro criar métodos que tenham sentido pro negócio para mudar os estados de meu objeto.

[]s