Quais os diagramas utilizados na UML que melhor representam as seguintes características da Orientação a Objetos: Herança, Polimorfismo e Encapsulamento?
Acho que heranaça deve ser o Diagrama de classes, agora polimorfismo e encapsulamento nao sei…
O diagrama de classes representa bem todos os conceitos que você mencionou. As interfaces representam o polimorfismo e o encapsulamento, por exemplo, pode ser representado por uma classe que contenha modificadores de acesso e métodos getters and setters, utilizados por membros externos para acessar informações da classe de maneira indireta, ou seja, encapsulada.
Você tem certeza que usar Get e Set é sinônimo de encapsulamento?[/quote]
Entao o certo seria eu dizer que:
“O diagrama de classes representa bem todos os conceitos (Herança, polimorfismo e encapsulamento).
As interfaces representam o polimorfismo.
E o encapsulamento, por exemplo, pode ser representado por uma classe que contenha modificadores de acesso, utilizados por membros externos para acessar informações da classe de maneira indireta, ou seja, encapsulada.”
Você tem certeza que usar Get e Set é sinônimo de encapsulamento?[/quote]
Acho impressionante nesse fórum como tem gente que gosta de colocar palavras na boca dos outros …
O cara apenas citou Setters e Getters como [size=18]1 (um )[/size] exemplo de encapsulamento, e não que encapsulamento é definir um
método get e um método set para cada variável de instância. Eu posso perfeitamente ter uma classe Quadrado com um membro private ‘lado’ e métodos getArea(){ return lado * lado } e getPerimeter{ return 4 * lado }. Ou então uma classe Cliente com um membro private nome e métodos getNome(){ return nome } e setNome( String n ){ nome = n }. Tanto um quanto o outro são casos de encapsulamento.
Ninguém colocou palavra na boca dos outros. Uma pergunta foi feita e caso o autor da afirmação tivesse dito outra coisa, ele mesmo teria respondido explicando que ele não quis dizer o que eu interpretei. Se ele não disse nada, é provável que eu tenha interpretado corretamente o que ele quis dizer.
[quote=rmendes08]
O cara apenas citou Setters e Getters como [size=18]1 (um )[/size] exemplo de encapsulamento, e não que encapsulamento é definir um
método get e um método set para cada variável de instância. Eu posso perfeitamente ter uma classe Quadrado com um membro private ‘lado’ e métodos getArea(){ return lado * lado } e getPerimeter{ return 4 * lado }. Ou então uma classe Cliente com um membro private nome e métodos getNome(){ return nome } e setNome( String n ){ nome = n }. Tanto um quanto o outro são casos de encapsulamento. [/quote]
Me desculpe mas a sua classe Cliente do segundo exemplo não é exemplo de encapsulamento. Como eu disse anteriormente, criar um atributo privato e disponibilizar um get e set pra ele, é um péssimo exemplo, dificultando mais ainda o entendimento das pessoas sobre o assunto.
Ninguém colocou palavra na boca dos outros. Uma pergunta foi feita e caso o autor da afirmação tivesse dito outra coisa, ele mesmo teria respondido explicando que ele não quis dizer o que eu interpretei. Se ele não disse nada, é provável que eu tenha interpretado corretamente o que ele quis dizer.
[quote=rmendes08]
O cara apenas citou Setters e Getters como [size=18]1 (um )[/size] exemplo de encapsulamento, e não que encapsulamento é definir um
método get e um método set para cada variável de instância. Eu posso perfeitamente ter uma classe Quadrado com um membro private ‘lado’ e métodos getArea(){ return lado * lado } e getPerimeter{ return 4 * lado }. Ou então uma classe Cliente com um membro private nome e métodos getNome(){ return nome } e setNome( String n ){ nome = n }. Tanto um quanto o outro são casos de encapsulamento. [/quote]
Me desculpe mas a sua classe Cliente do segundo exemplo não é exemplo de encapsulamento. Como eu disse anteriormente, criar um atributo privato e disponibilizar um get e set pra ele, é um péssimo exemplo, dificultando mais ainda o entendimento das pessoas sobre o assunto.[/quote]
É sim! Com o get e o set eu posso alterar a maneira como o atributo nome é armazenado sem modificar as assinaturas dos métodos. Eu poderia alterar o tipo do atributo nome de String para uma nova classe, por exemplo, MyCharArray e fornecer novas implementações dos métodos, como getNome(){ nome.toString() } e setNome( String n ){ nome = new MyCharArray( nome ) }.
[quote=rmendes08]
É sim! Com o get e o set eu posso alterar a maneira como o atributo nome é armazenado sem modificar as assinaturas dos métodos. Eu poderia alterar o tipo do atributo nome de String para uma nova classe, por exemplo, MyCharArray e fornecer novas implementações dos métodos, como getNome(){ nome.toString() } e setNome( String n ){ nome = new MyCharArray( nome ) }. [/quote]
Volto a dizer, isso é um péssimo exemplo. O problema não está no getXXX, mas sim em achar que ter get/set é sinônimo de ter encapsulado seu objeto.
Existe uma diferença importante nesse sentido. Dá uma lida no artigo do Fowler que te passei que você vai entender o que quero dizer, pois não há motivos pra repetir tudo que ele menciona.
Nosso amigo Shoes aqui do forum também já falou muito sobre Objetos Fantoches. Dá uma lida que também é uma ótima referência pra não ficar com objetos cheios de get/set.
[EDITADO]
Antes de clicar no enviar surgiu o post do Phillip.
É isso mesmo que eu quero dizer Phillip. Obrigado
[EDITADO]
Eu entendo perfeitamente o que você quer dizer. Não estou defendendo que encapsulamento é incluir set/get para todo e qualquer atributo na classe, mas que quando necessários e bem usados são exemplos de encapsulamento, citando o próprio artigo:
[quote] There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters.
[/quote]