Falta um modificador em Java?

GUJ Ranger Membro desde: 21/07/2005 08:51:27 Mensagens: 807 Offline

ozix wrote:Sempre pensei nesse ponto relacionando-o com a arquitetura multi-camadas. Embora você separe sua aplicação nas camadas A - B - C. Não há uma solução natural java que impeça que A acesse C.

Também sempre me fiz a mesma pergunta do Vini.

Exato!

Quando a modularização, isso já pode ser resolviso com OSGI mesmo mas e como ficam os jars que usamos como dependencias?

Eu adiciono Hibernate + Spring + Framework qualquer, vou no netbeans digito a letra C e depois Ctrl+space, pronto... tenho aí umas centenas de classes que posso usar indevidamente.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Modificadores de acesso me parecem mais uma solução técnica para um problema social de falta de conhecimento¹.

Edit:

1 - Falta de conhecimento de como usar as classes de um sistema/framework do jeito certo/esperado pelo autor.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ViniGodoy wrote:Acho os modificadores do Java extremamente permissivos.
Por que o protected abre tanto para as classes do mesmo pacote?

De privado mesmo você praticamente só tem o private.

Porque o java é desenhado para hierarquia de pacotes e a herança pode ser cross-package. O pacote é um membro importante do java porque é usado para várias coisas na jvm. Segurança, entre elas. O Package é um conjunto de Class.

Não faltam modificadores no java, o que falta é o conceito de pacote filho. normalmente criamos o pacote X e depois o pacote X.Y onde Y serve para alguma coisa particular de X, por exemplo, X é interfaces e Y é implementações. Este vicio é levou a considerar que o java é imcompleto, quando na realidade é esta prática que está errada. Apenas classes da API que podem ser usadas fora do pacote devem ser publicas. O resto deve ser tudo package. É por isso que o package é o default, porque é assim que deveria ser feito.

Protected é para herança entre pacotes. Ele é mais permissivo que o package e menos que o public. Só que as pessoas não o sabem usar. O problema é esse e não a especificação do java. Por exemplo, métodos auxiliares declarados em classes abstratas devem ser protected e não public, como é costume ver por ai.

As anotações do projeto jigsaw não são para aumentar ou substituir os modificadores de visibilidade, são feitas para criar um novo conceito de bundle (que eles chama modulo) que é um conjunto de pacotes. (Bundle -> pacote -> class ). Na realidade está havendo uma evolução e não um remendo. O conceito é definir permissões de visibilidade entre modulos e pacotes e não entre classes como fazem os modificadores de visibilidade.
Com modulos é possivel fazer mais coisas interessantes em segurança e gerenciamento de dependencia como o OSGI já mostrou.

sergiotaborda wrote:Porque o java é desenhado para hierarquia de pacotes e a herança pode ser cross-package. O pacote é um membro importante do java porque é usado para várias coisas na jvm. Segurança, entre elas. O Package é um conjunto de Class.

Não faltam modificadores no java, o que falta é o conceito de pacote filho. normalmente criamos o pacote X e depois o pacote X.Y onde Y serve para alguma coisa particular de X, por exemplo, X é interfaces e Y é implementações. Este vicio é levou a considerar que o java é imcompleto, quando na realidade é esta prática que está errada. Apenas classes da API que podem ser usadas fora do pacote devem ser publicas. O resto deve ser tudo package. É por isso que o package é o default, porque é assim que deveria ser feito.

Claro, siga essa recomendação e você acabará com pacotes enormes, cheios de classes, o que vai contra qualquer prática sensata de modelagem. Não é à toa que a própria API do Java foi a primeira a desrespeitar a regra, e usar o conceito de subpacotes erroneamente.

E, como vc mesmo falou, falta o conceito de pacote filho. Essa falta é uma falha da especificação, não dos programadores. Subpacotes eram usados muito antes do java sequer existir.

sergiotaborda wrote:Protected é para herança entre pacotes. Ele é mais permissivo que o package e menos que o public. Só que as pessoas não o sabem usar. O problema é esse e não a especificação do java. Por exemplo, métodos auxiliares declarados em classes abstratas devem ser protected e não public, como é costume ver por ai.

Não concordo com você. O problema surgiu porque a especificação do java é ruim nesse aspecto. Programar seguindo a forma que foi feito é simplesmente inviável. Você acabaria com pacotes gigantescos e desorganizados. A recomendação de criar subpacotes está em artigos da Sun, embora haja a ressalva de que isso seja para organização do programador, e que para a linguagem são pacotes diferentes. A própria convenção de nomes de pacotes da a noção de hierarquia, que para linguagem não existe.

O único modificador que você tem que torna as coisas mais privadas é o private. Classes num mesmo pacote enxergam umas as outras com todas as suas propriedades públicas, exceto as private. É difícil modelar blocos de componentes em java por causa disso, é difícil garantir extensibilidade para fora do pacote sem ser permissivo demais para dentro do pacote.

Agora, não acho que a Sun tenha optado por uma abordagem de todo ruim. Talvez tenham optado por manter os modificadores simples, mesmo a custa de alguns problemas menores. E isso eles realmente são.

GUJ Ranger Membro desde: 21/07/2005 08:51:27 Mensagens: 807 Offline

Opa!

Claro que podemos esconder tudo o que nao deve ser acessível ao mundo externo através do modificador default ou abrindo um pouco mais com protected. O problema é como o viny falou, se eu tenho um sistema que tem 1k classes como fica?

A própria estrutura de Sun (quer dizer.. Oracle) usa esse modelo de sub-pacotes, o que eu acho que aconteceu é que ou numca se deu grande importancia a isso ou fazem vista grossa.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ViniGodoy wrote:

sergiotaborda wrote:Porque o java é desenhado para hierarquia de pacotes e a herança pode ser cross-package. O pacote é um membro importante do java porque é usado para várias coisas na jvm. Segurança, entre elas. O Package é um conjunto de Class.

Não faltam modificadores no java, o que falta é o conceito de pacote filho. normalmente criamos o pacote X e depois o pacote X.Y onde Y serve para alguma coisa particular de X, por exemplo, X é interfaces e Y é implementações. Este vicio é levou a considerar que o java é imcompleto, quando na realidade é esta prática que está errada. Apenas classes da API que podem ser usadas fora do pacote devem ser publicas. O resto deve ser tudo package. É por isso que o package é o default, porque é assim que deveria ser feito.

Claro, siga essa recomendação e você acabará com pacotes enormes, cheios de classes, o que vai contra qualquer prática sensata de modelagem.

Não vejo onde está o problema disso. Nem vejo que isso seja um problema de modelagem. Organização de pacotes está longe de ser um problema de modelagem a menos que vc siga o padrão proposto pelo Java ( eu disse java, não sun).

Ao construir uma API grande como a do java é necessário tem em consideração que existem classes escondidas que vc não vê. A API publica é publica exatamente porque é que vc precisa usar, mas exste a API privada que tem apenas detalhes de implementação. Esta deve ser "secreta".

Eu nunca vi muita utilidade na visibilidade padrão, até que comecei a criar API grandes como o MiddleHeaven. Existem coisas que vc precisa fazer mas que vc não quer publicar (até porque vc quer minimiar a superficie da API). Então o nivel default é realmente util na prática.

Em pacotes de negocio obviamente terá pouca utilidade já que os pacotes de dominio são os mais publicos que ha (afinal eles representam conceitos que existem na realidade e não detalhes de implementação).

Ter muitas classes num pacote não significa desordem. É esse conceito errado que leva as pessoas a criarem muitos subpacotes idiotas. Eu odeio especialmente o pacote impl. Um verdadeiro cancer. Não ha razão logica para segregar as implementações para outro pacote.

A regra base é muito simples ( tudo é private, apenas é aumentada a visibilidade quando necessário) mas - quase - ninguém a usa. e depois culpam o java ...

Eu sempre achei um problema ter pacotes gigantes. Acho tão problemático quanto ter pacotes vazios demais.

Notícias, artigos e o maior fórum brasileiro sobre Java