Quebra de encapsulamento

Programação Java
#21

[quote=microfilo]Não podemos ser dogmaticos demais.
Conclusão: use Interfaces quando for algum serviço (persistência, por exemplo) e Classes Concretas quando for lógica de negócio. Afinal o mais importante e o que menos deveria mudar é a lógica de negócio.[/quote]

Meio irreal isso.

Lógica de negócio é algo que mais muda num sistema grande (inclusive devo apresentar algo sobre isso em breve). O cliente muda fluxos, faz promoções loucas, compra outras empresas, disponibilizam outros serviços, altera forma de pagamento, pede para tal coisa ser feita de jeito diferente…

Em três anos cuidando basicamente de ‘produtos’ eu nunca vi nada mudar tanto. Projetos mudam, mudam, dae você entrega e geralmente alguém fica com a manutenção. Produtos fazem projetos constantemente para alterar tudo.

Flexibilidade para regras de negócio é muito importante.

#22

E falando um pouco de aplicações orientadas a serviços ? Por exemplo, teríamos interfaces que seriam como uma linha fina entre as especificações dinâmicas e a implementação específica, assim facilmente o sistema seria manipulado pelas assinaturas e comportamentos na interface, representando neste caso os serviços que deverão ser providos a um determinado domínio de negócio da aplicação.

Sim, regras de negócios na sua ideal existência deveria ser plugável e configurável, estamos entrando hoje numa fase em que a tendência modular prevalece na luta pela sobrevivência agressiva no mercado, e para isso, uma forma estratégica seria em pouco tempo você mudar a forma como seu sistema vai agir, sem mudar o comportamento principal,a ‘engine’ do sistema deve permancer quase imutável, isso hoje é muito bem factível utilizando interfaces na modelagem de classes, porém para isso é necessário que a pessoa tenha um certo pensamento abstrato do negócio, e que infelizmente é difícil encontrar.

#23

[quote=pcalcado]O que ele diz (e não quer dizer que esteja absolutamente certo mas Joshua Bloch é uma referência cheia de crdibilidade) é que você deve utilizar interfaces quando disponíveis (e eu acrescento: quando fizerem sentido!). O exemplo dado é bem claro: em vez de usar ArrayList, use List mas para String use String mesmo.

[/quote]

Muita gente, e a api do java desde o 1.4, costuma referir String por CharSequence, sempre preferindo a interface, aceitando assim StringBuffer/Builder, e se precisar de String basta um toString.

Eu leio mais como o takeshi: use interface sempre que possivel, mesmo que nesse momento nao faca sentido. Mas se ela tem interface, e da para usa-la, mesmo sem parecer util no momento, use.

Um dos refactorings do eclipse é “substituir pelo uso de interface whenever possible” ou algo assim.

Mas tambem sou contra criar uma interface para qualquer classe.

#24

[quote=Paulo Silveira]Muita gente, e a api do java desde o 1.4, costuma referir String por CharSequence, sempre preferindo a interface, aceitando assim StringBuffer/Builder, e se precisar de String basta um toString.
[/quote]

Eu nunca vi um código que não fosse um framework (como Rife) ou algo do tipo utilizar CharSequence mas não duvido que exista.

[quote=Paulo Silveira]
Eu leio mais como o takeshi: use interface sempre que possivel, mesmo que nesse momento nao faca sentido. Mas se ela tem interface, e da para usa-la, mesmo sem parecer util no momento, use
…
Mas tambem sou contra criar uma interface para qualquer classe.[/quote]

:wink:

#25

Esse assunto pode ir longe hein !

Mas vou por minha opinião…

Pra mim, o uso de Interface serve para que se possa ter um certo pardrão entre os objetos de sua aplicação… no qual facilita futuras alterações…

Em uma interface vc especifica os métodos que seus “filhos” deverão implementar…

Uma coisa legal nisso, eh que vc pode implementar os métodos de formas diferentes para cada objeto e tb pode adicionar novos atributos…
(nada de novidade neh?)

Agora… a maneira de como se utilizar esse monte de classes fica TOTALMENTE a sua escolha…

Não eh um manual ou um artigo que irá te falar qual a melhor opção ou qual a melhor forma de se modelar um sistema…

Acho estranho ficarmos nos bazeando nos que certas pessoas falam… quel disse que eles estão certos ? quem disse que essa eh a melhor maneira ??? quem pode provar que eh melhor utilizar uma herança, uma composição ou uma agregação ??

O cara que criou a linguagem ?? Os analistas mais falados do mundo ??

Bah! Se nos formos ver os padrões de modelagem especificados em vários lugares… são tantos padrões que fica dificil escolher um…

Camdas então… ! Nossa… vc pode fazer uma modelagem em tantas camadas que acabam deixando o desenvolvedor doido… ^^

Os conceitos de O.O n são regras… são sugestões que vc pode utilizar… cabe a vc utiliza-las, e cabe a vc fazer com que funcionem…

Quebra de encapsulamento ?? Se isso ocorre, não eh porque a idéia esta errada, mas sim porque n foi bem aplicada… Se uma Interface oferece quebra ou não… isso eh vc q define… vc que deve controlar…

Como controlar isso ??? Vc escolhe, n será um padrão ipipoca que vai te mostrar isso… n existe uma maneira correta de se utilizar encapsulamento… existem várias… qual a melhor ?? qual funciona de verdade ??
Qual segue as regras ?? Regras ?? Quem disse que existem regras ??

Kraca… n qnto mais digitar !

Fui !

#26

Não entendi seu ponto. O que você quer dizer com isso?

Por isso que:

Mas mesmo assim, desprezar referências como Joshua Bloch é, na muito melhor das hipóteses, reiventar a roda e, na maioria das vezes, aplicar péssimas práticas.

Lendo os diversos pontos de vista e diversos trabalhos de autores clássicos ou não você ganha conhecimento apra tomar suas decisões. São anos e anos de experiência que você não vai viver o suficiente para conseguir por si só compilados em livros e artigos. Nem Bertrand meyer que é talvez o maior ícone atual de OOP (e o mais arrogante) diz que o que ele aplica são regras (pelo menos não abertamente).

#27

Galera e qual a forma de se escrever corretamente um Interface?

Exemplo:

  • Tenho a classe Carro
  • e as interfaces IMecanico e IUsuario

como nomeio elas?

#28

Bom dia Srs.

Estou com uma dúvida. É o seguinte, tenho um classe Pessoa e nela tenho alguns objetos pertinentes a pessoa encapsulados. Bom tem “outros” que eventualmente iram acontecer, tais como o objeto Estrangeiro e Reservista.

Estava pensando em criar uma forma de realizar um encapsulamento sobre demanda, utilizando métodos dentro da Pessoal, que ao serem chamados instanciariam o objeto Reservista por exemplo. Mas para eu criar isso teria que passar alguma coisa para o objeto Reservista, pois não tenho como saber se tal objeto, Reservista, pertence ao objeto Pessoa…

Estou viajando, ou tem outra forma mais prática pra fazer isso !!!

Valeu …

#29