Quem falou em getters e setters? Quanto mais deles uma classe tiver, menos OO ela costuma ser.
[/quote]
a tah ai sim eu conto um ponto a favor 
e como controlar os dados e mantelos independentes dos demais? IOC? AOP? Properties? mágica?
isso aqui é o GUJ, nada aqui tem fim hehehe
Mas existe polimorfismo sem herança ?
São essas contradições que me confundem…
[quote=jprogrammer]O ponto que eu quero chegar é:
Será que estamos programando em OO ?
Ou é um procedural com recursos OO ?
Será que realmente o OO é útil na vida real ?
[/quote]
Minha opinião:
98% GOO
01% POO
01% Não sabe definir
[quote=jprogrammer]Mas existe polimorfismo sem herança ?
São essas contradições que me confundem…
[/quote]
Acredito que não possa no final acaba sendo uma sobrecarga…
Tipo 01:
A sobrecarga é um tipo de polimorfismo. É considerado Polimorfismo estático.
Tipo 02:
Para que ocorra polimorfismo se faz necessária a existência de herança de uma classe (abstrata de preferência) ou a implementação de uma interface.
PS: editado…
Só é importante lembrar que isso não tem nada a ver com orientação a objeto, quer dizer, linguagens procedurais também possuem esse tipo de polimorfismo. Então, acho que não é relevante no contexto da pergunta original.
Mais um catequizado. :mrgreen:
jprogrammer, que tal tu da uma lida no post que catequizou o Rafael e mais alguns tipo.
http://www.guj.com.br/posts/list/21687.java
http://www.guj.com.br/posts/list/20668.java (O Link que o Daniel falou sobre encapsulamento, o tutorial esta ai dentro).
Alguns aspectos que nao podem passar desapercibido.
-
Quem falou que programar com JavaBens burro é OO, essa é a briga que nos tanto falamos aqui de Domain Driven Design.
-
Basear o sistema em caso de uso, e quem disse que existem caso de uso??
Ps.: A historia do catequizar é brincadeira, nao me leve a mal Rafael. 
]['s
[quote=mister__m]
Só é importante lembrar que isso não tem nada a ver com orientação a objeto, quer dizer, linguagens procedurais também possuem esse tipo de polimorfismo. Então, acho que não é relevante no contexto da pergunta original.[/quote]
Doutor M,
não entendi o que você quer dizer com “isso não tem nada a ver com OO”, o que não tem nada a ver? sobrecarga? polimorfismo estático?
Entendi esses posts relativamente e até participei. Achei bem interessante a idéia.
Mas aí você tocou em um ponto interessante.
O sistemas devem ser baseado em ações do usuário ou na arquitetura que o compõe (os elementos se se colaboram) ?
Essa é minha dúvida.
Acredito que quando você disse que não existe caso de USO, foi por essa questão.
Quando falo ações do usuário não me refiro a tela de sistema, mas os procedimentos que são realizados em um processo.
ex:
O sistema deve registrar uma venda.
Quais são os procedimentos necessários para registrar uma venda.
- entrada de dados
- validação
- baixa estoque, etc…
- salva dados
Isso não seria um caso de uso ?
[quote=skill_ufmt][quote=mister__m]
Só é importante lembrar que isso não tem nada a ver com orientação a objeto, quer dizer, linguagens procedurais também possuem esse tipo de polimorfismo. Então, acho que não é relevante no contexto da pergunta original.[/quote]
Doutor M,
não entendi o que você quer dizer com “isso não tem nada a ver com OO”, o que não tem nada a ver? sobrecarga? polimorfismo estático?
[/quote]
Na minha resposta original, eu citei as suas palavras pra deixar claro exatamente a que eu me referia, o polimorfismo estático, ou paramétrico. Inclusive, esse nome é muito ruim porque confunde conceitos que são fundamentalmente diferentes.
[quote=jprogrammer]Quais são os procedimentos necessários para registrar uma venda.
- entrada de dados
- validação
- baixa estoque, etc…
- salva dados
Isso não seria um caso de uso ?
[/quote]
Sim, mas e quem nao usa caso de uso?? Quem usa XP por exemplo tu vai querer fazer por UE? Tem gente que nao faz nada, nem UC nem UE…entao vai da cabeca de quem desenvolve.
Se eu fosse fazer como tu ta falando, uma classe faria todo o trabalho e ai pra onde for a separacao de camadas. Vamos voltar ao desenvolvimento de anos atras que nao deu muito certo?
Eu acho que esse assunto nao agrega nada, e so gera discuacao. 
]['s
Jamais!!!Agora você me deve R$20,00 por cada ofensa!!1(É que tá na moda cobrar aqui no GUJ…hehe). Brincadeira, relaxa que não levo nada como pessoal.
Quanto a catequização, era mais ou menos a idéia que eu fazia de uma lógica de negócios, só tava tentando entender este conceito de Domain Driven.
Eu ia entrar nessa discussão de JavaBeans burros, mas xápralá…
Existem duas questões filosóficas:
- Sistemas de Objetos são melhores que sistemas procedurais?
- Vale a pena usar objetos, não é muito complexo?
Vou expôr meu ponto de vista.
- Sistemas de Objetos são melhores que sistemas procedurais?
Depende.
Se você pegar a literatura de Projeto Estruturado vai ver pessoas (que aliás, são as mesmas que hoje falam em Projeto Orientado à Objetos) explicando como modularizar código. Nessa abordagem, modularizar significava criar subrotinas, cosia que foi possível com o avanço das linguagens, compiladores e computadores.
Se você pensar como uma pessoa daquela época, vai perguntar: por que usar essas funções seria melhor do que simplesmente escrever o bendito código? O argumento mais forte é a modularidade que o uso de funções traz, mudando um simples ponto você consegue alterar o comportamento de um sistema inteiro. Reutilizando funções você economiza muito tempo para fazer as coisas.
Alguém aí programa de maneira não-estruturada hoje em dia?
Atrás sempre de modularidade, as estruturas de dados a serem manipuladas foram também encapsuladas junto com as funções que as manipulam.
Imagine um módulo C. Você tem estruturas de dados (structs) e funções. Um .c e um punhado de .h. Agora imagina que você pudesse tratar tudo isso, funções e dados, como uma entidade única. Isso é um objeto.
Ao definir a interface para o objeto, eu posso evitar que meus “clientes” mexam diretamente nos dados, fazendo com que mudar a implementação interna do meu objeto seja extremamente simples. Você já tentou mudar uma struct num grande sistema em produção? Nem que fosse só o tipo de dado? Tente e você vai ver o inferno que é.
Então, com objetos temos modularidade à um nível baixo. Conseguimos uma abstração muito melhor das coisas e podemos deixar que “como implementar isso” seja um detalhe.
- Vale a pena usar objetos, não é muito complexo?
Depende.
Para programas muito simples, objetos são um overhead. Para programas complexos ou para coisas que evoluem, não usar objetos pode ser um problema muito grande no futuro.
A resposta é sempre depende. Depende do que você quer fazer (e nem entrei em méritos gerenciais ou financeiros!).
Enfim, um bom texto sobre o tema: Object Orientation: Making the Transition.
Shoes (ou outro…) na opinião de vocês isso seria OO.
class Funcionario
{
public void cadastrar(int codigo, string nome)
{
}
public void alterarCadastro(int codigo, string nome)
{
}
public float calcularBonus(int codigo, int mesReferencia)
{
}
}
essa classe tem métodos que não estão associados com nenhum registro, ou seja, parece mais uma classe utilitária que realiza funç~es relacionadas com funcionários.
ou ficaria melhor
class Funcionario
{
private int codigo;
private string nome;
private int mesReferencia // não é um atributo de um funcionario
// setters e getters
public void cadastrar()
{
}
public void alterarCadastro()
{
}
public float calcularBonus()
{
}
}
A segunda opção!
Acho que você está confundindo algumas coisas, jprogrammer.
O objeto em si não vai gerenciar a funcionalidade, ele vai participar da funcionalidade.
Não é o meu Funcionário que vai fazer tudo. Eu pdoeria, por exemplo, ter um gerenciador:
class GerenciadorFuncionarios{
public void cadastrar(Funcionario f)
public void alterarCadastro(Funcionario f)
public float calcularBonus(Funcionario f)
}E qual o papel do bendito funcionário neste exemplo? Poderia ser:
class Funcionario{
public void aderirDepartmento(Departamento d)
public int idade()
public List filhos()
}E por aí vai
Realmente tá bem interesante esse exemplo.
Melhor que aqueles setters and getters.
para definir valor como você faz.
funcionario.idade( 19 ) ;
ou funcionario.definirIdade( 19 );
(dei uma editada no seu psot para não ficarem smiles )
Nomenclatura é dependente. Eu não gostod e usar get/set, mas como isso é uma cosia padrão em java eu uso. O problmea é que o cliente acha (por experiência própria) que esse get é um “this.blabla=nanana;”, o que nãod everia ser (sempre) verdade.
O importante num objeto é o seguinte: minha API/interface/sei lá como vc quer chamar do objeto é:
public void definirIdade(int idade)Não importa se você faz:
public void definirIdade(int idade){
checarIdadeValida(idade);
Date nascimento = calcularDataNascimento(idade);
this.dataNascimento = nascimento;
}ou
public void definirIdade(int idade){
this.idade = idade;
}Note que no segundo temos um típico setter. Não é porque setters são super-utilizados geralmente que eles são inúteis
[quote=jprogrammer]O ponto que eu quero chegar é:
Será que estamos programando em OO ?
Ou é um procedural com recursos OO ?
Será que realmente o OO é útil na vida real ?
[/quote]
No meu ponto de vista, OO serve apenas para auxiliar
a manutenção do código. Se suas classes forem encapsuladas
corretamente, vc poderá fazer varios tipos de mudanças
sem se preocupar com outras classes. Utopia!!
Acho que não devemos nos preocupar se estamos usando
OO ou procedural. O cliente não está nem aí para o que
vc usa, ele quer ver a coisa funcionar.
Nós que devemos entender as técnicas de Engenharia
de Software (OO é uma delas) para que possamos
atender o cliente mais rápido e sem bugs! Ou seja,
a manutenção do código ao longo do projeto que é
o grande problema.
[quote=marcocatunda]Acho que não devemos nos preocupar se estamos usando
OO ou procedural. O cliente não está nem aí para o que
vc usa, ele quer ver a coisa funcionar.
Nós que devemos entender as técnicas de Engenharia
de Software (OO é uma delas) para que possamos
atender o cliente mais rápido e sem bugs! Ou seja,
a manutenção do código ao longo do projeto que é
o grande problema.[/quote]
Nem sempre. Ja parcipei de projeto que a primeira coisa que o cliente fez foi abrir o codigo e ver como tinha sido implementado.
Agora estou em outro projeto que o cliente ou outro empresa é quem vai dar manutencao. Entao sempre é bom ter cuidado nessa hora tambem.
]['s