Estrutura Procedural não é melhor para sistemas Empresarias

E se você precisa exibir os dados na tela?

ResultSet rs = pegarDadosPessoa(1); if( rx.netx() ) { out.println( rs.getString("nome") ); }

Ou seria melhor?

Pessoa p = PessoaDAO.buscar(1); out.println(p.getNome());

Ainda quer pensar proceduralmente?

Concordo plenamente com vc Daniel. Programando de forma procedural vc programa 1 linha para o que vc quer q o programa faça e 30 linhas para o que quer q ele não faça.É +/- assim!

jprogrammer:

Vi alguns tópicos recentemente aqui no GUJ. E vou continuar um assunto polemico. OO X Procedural.

acho que a maioria são meus hehehe

Mas enfim, procedimentos sempre existirão ou tu viu alguma máquina que não leia procedimentos?

O problema é como são tratados estes procedimentos, se realmente OO, se realemtne PE, ou se realmente OOR(TOO)…
E recentemente ainda tem POA

Disso nascerá o problema e as discussões, qual melhor? qual usar? porque?

Ao meu ver sempre é uma gambiarra para arrumar outra, assim como um certo SO´s : )

Primeiro:
Será que realmente isso aí é OO ?
Segundo:
Qual a diferença entre ter uma collection de javabens e um resultset ?
Apenas os atributos do javabeans são verificados em complie time e de um resultset (ou outra coisa qualquer) seriam verificados em runtime.
e se eu quisesse apenas alguns campos e pior, se quisesse campos de várias entidades diferentes ?
Outra coisa: eu teria uma coisa qe apenas retornasse valores read-only, pois se trata de uma consulta.

Sobre o read-only, leia um ótimo artigo que colocaram o link aqui no Fórum, sobre encapsulamento de dados. Me clarificou muitas idéias. Além do pattern Memento.

E outra, eu falo de experiência própria. Programei muito em ASP usando ResultSet. É MUITO mais trabalho que usar JavaBeans. Muito código repetido, muito lugar pra dar manutenção, muito pior.

Você quer comparar com aquele RecordSet do ASP. Não tem comparação.
Eu programei muito em ASP também. Se for bem feito não fica tão ruim.
Programava baseado (não orientado) a objetos no ASP.
Tinha classes de acesso a dados que encapsulavam o modo de abertura dos benditos Recordsets.

Quando falo de resultset no java , pode ser qualquer tipo de coleção de registros não necessariamente o resultset do JDBC.

Gosto da estrutura dos bancos relacionais. Será que não ficaria interessante uma estrutura parecida, mais em nível de programa.
Com entidades, procedimentos e consultas. Não é basicamente isso que se resume um sistema.
Não confunda isso com sistemas data-driven. Não tem nada a ver com banco de dados, mas sim a organização das responsabilidades.

Entidades - Definição e Repositorio de dados
Procedimentos - Operações e funções
Consultas - Coleta de dados

Será que fui claro…

e só pra constar mais uma das inúmeras técnicas, tem também a GOO

Bom, não sou eu que to falando. Até acho que não tenho muito crédito. Mas as literaturas e os “especialistas” estão ai para dizer e “provar” as arquiteturas usadas, suas vantagens e desvantagens.

Sinceramente acho que esse modelo gera muita repetição de código e difícil manutenção (mexe em 30 mil pontos do programa)…

Quanto à sua última sugestão, acho que isso é muito feito com VO (TO), DAO,Bizz Delegates e blablablás…

jprogrammer:

Gosto da estrutura dos bancos relacionais. Será que não ficaria interessante uma estrutura parecida, mais em nível de programa.
Com entidades, procedimentos e consultas. Não é basicamente isso que se resume um sistema.
Não confunda isso com sistemas data-driven. Não tem nada a ver com banco de dados, mas sim a organização das responsabilidades.

E por que não ter uma porção de objetos que colaboram entre si? Aproximar a modelagem do sistema de como as coisas acontecem realmente, ao invés de espalhar funções e procedimentos pra todo lado. Na hora de dar manutenção ou até mesmo extender o sistema, o que fica mais fácil: Sair ‘caçando’ toda a trilha de procedimentos e funções que determinada regra de negócio executa, ou partir dos objetos e suas responsabilidades?

PE

Dados independentes manipulados por funções independentes em locais independentes…

POO

Dados independentes manipulados por métodos dependentes e responsáveis obtendo independência…

hummm, com qual ficar?

Programação procedural sofre do problema de separar dados de comportamento. Então voce acaba com uma pilha de structs e uma pilha de funções. Com OO dados e comportamento ficam no mesmo lugar, é mais facil de modificar e atualizar.

Realmente um grande trunfo do OO é a herança.
Isso é um ponto muito favorável realmente.

Mas quando falamos em procedimentos as pessoas já pensam em coisas separadas sem conexão entre si.
Mas eu acredito que não precisa ser assim.

Acho que temos que partir do caso de uso. O que ele faz. Qual a sequencia de operações.
Não é preciso repetir. Pode-se aproveitar também.
ex:

consistirFuncionario()
{

}

atualizarCadastroFuncionario()

{

consistirFuncionario();

// codigo

}

cadastrarFuncionario()

{

consistirFuncionario();

// codigo

}

E deve ser centralizado. Existir um unico ponto para o caso de uso, ou seja, apenas uma função para realizar esse procedimento.
Não criar redundancias ou repetições.

Outra coisa:
O que estão usando por aí não é um monte de structs(javabens) sendo passados para uma função (session façade sessionbean…).

louds:

Programação procedural sofre do problema de separar dados de comportamento. Então voce acaba com uma pilha de structs e uma pilha de funções. Com OO dados e comportamento ficam no mesmo lugar, é mais facil de modificar e atualizar.

e get/set seriam responsáveis pelo seu comportamento? cheirando GOO

jprogrammer, eu nao entendi o seu problema (e aparentemente ninguem entendeu, pq cada um foi pra um lado na conversa). Voce nao quer dar uma explicada melhor sobre o que voce esta querendo dizer, exatamente, pra evitar mais uma Discussao Sem Fim?

Me fale mais sobre esse GOO…

Quem falou em getters e setters? Quanto mais deles uma classe tiver, menos OO ela costuma ser.

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 ?

jprogrammer:

Realmente um grande trunfo do OO é a herança.
Isso é um ponto muito favorável realmente.

:shock: seráaaaaaaaaa?

herança é ruim
dependendo da profundidade

Acho que os grandes trufos são: polimorfismo, decomposição, delegação… :roll:

Gambiarra Orientada a Objetos :lol:

Quem falou em getters e setters? Quanto mais deles uma classe tiver, menos OO ela costuma ser.

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…

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 ?

Minha opinião:

98% GOO
01% POO
01% Não sabe definir

jprogrammer:

Mas existe polimorfismo sem herança ?
São essas contradições que me confundem…

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.

1. Quem falou que programar com JavaBens burro é OO, essa é a briga que nos tanto falamos aqui de Domain Driven Design.

2. 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

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.

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 ?

skill_ufmt:

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.

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?

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.

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 ?

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

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 ?

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.

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.

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

Ele também não está nem aí quando você fala que vai ter que mudar 5.045 arquivos de fontes com funções defasadas porque você alterou aquela struct, ele quer a alteração no sistema, e para ontem

Concordo também marcocatunda .
O que importa é a funcionalidade.
Mas as técnicas são importantes para garantir a qualidade do sistema.
Por isso acho relevante discusões como esta e muitas outras que se tem no GUJ.
Essas discussões questionam nosso conceitos.

Mas coloco outra dúvida ?
Um pattern como o Command é uma quebra de OO.

Parece mais uma classe que representa um método (um caso de uso, pode ser) ?

Representar casos de uso em classes genéricas não trazem produtividade ao sistema sem torna-lo totalmente procedural ?
ex:

class BusinessCommand 
{
    public void execute(Map parameters)
    {

     }
}

class RegistrarVenda extends BusinessCommand 
{
    public void execute(Map parameters)
    {
        // faz um monte de coisas
     }

}

class RegistrarVendaParcelada extends RegistrarVenda
{
    public void execute(Map parameters)
    {
        super.execute(parameters);
        // faz um monte de coisas
     }

}

RegistrarVendaParcelada  r = new RegistrarVendaParcelada ();
Map m = new HashMap();
m.put("DATA",new Date());
m.put("VALOR",new Float(12.3));

r.execute(m);

fabgp2001:

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.

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

Isso que eu chamo de cliente chato. Nunca tinha visto isso.
Bom, nesse caso o cliente deve estar pagando pelo código fonte
documentação técnica e outras coisas… Talvez seja a hora
de usar aquela coisa que nunca vi ninguem usar
"Literate Programing".

É por isso que perco meu tempo lendo e escrevendo mensagens
aqui!

Antes de responder isso. Devemos saber extamente
o que é OO? Qual seria a definição para OO.

Para mim OO é uma técnica com três principais premissas:

1. Herança
2. Poliformismo
3. Encapsulamento

O pattern Command possui as três técnicas bem aplicadas.

Será que eu entendi a sua dúvida!

É possível mentir dizendo apenas verdades hehe

Por que uma ação deveria estar numa classe alheia à logicamente responsável pela mesma? Aplicar a Command Pattern gera código desse jeito aqui:

void execute() {
    if( person.getAge() > 18 )
        if( reservation.isAvaiable() )
            if( card.avaiableMoney() >= reservation.getPrice() )
                if( messager.confirm() )
                    transaction.commit();
}

Que, aliás, está espalhado em todo o último sistema que desenvolvemos aqui.
Por que o Command tem que conhecer tantos objetos? Ao invés de pedir os dados para realizar a tarefa, mande quem tem os dados realizá-la. Isso é para mim a premissa básica de OO. O que você citou são técnicas.

Command é completamente procedural: alguns “objetos” tem dados e um “objeto” tem ações.

Mas … bem … nada de errado nisso! Desde que ninguém fale de alterar merda nenhuma hehe

Lipe, que sofre com o código que escreveu.

Command nao eh “quebra da OO”, doenca incuravel e nem uma das quatro bestas do apocalipse. Relaxem

O importante sobre os Commands eh, e o Lipe disse tudo: “Ao invés de pedir os dados para realizar a tarefa, mande quem tem os dados realizá-la”. Simples, non? Isso te impede de usar command pattern de algum jeito? Nope!

Mas é exatamente isso que aprendi na faculdade!!!

Mas quando fui colocar o que vi na faculdade na prática, vi que era inviável! Minha classe Empresa iria ter pelo menos umas 1500 linhas de código!!!

Daí estudei patterns e descobri o DAO! Pronto… O aluno deixou de ser responsável pelas ações criar, deletar e etc!!! Tentei fazer com que a classe de negócio tivesse um método criar que chamada o método criar do DAO!!!
Ainda sim o método ficou meio porco, ou GOO, como diz o Skill!!!

Depois que entrei no GUJ, e de tanto falarem em IoC, containers leve, spring e etc… Pronto!!!

Meus problemas se acabaram!!! Até onde vi, e com dúvidas e opiniões esclarecidas aqui no GUJ, IoC e Spring é uma boa opção para minimizar ou até resolver o problema!!

Mas é ai que entra o problema!!!
Você precisa saber IoC para saber fazer um código realmente orientado a objeto e com boa qualidade???

Abraços!

O esquisito é que a línguagem por si própria não resolve o problema!!! A gente precisa de uma infinidade de conceitos e frameworks para facilitar o desenvolvimento de bons códigos!!!

Ao menos a experiencia que tive com Command nao foi muito agradavel(e o pior, eu tava querendo utilizar novamente!!Mas um cavaleiro do zodiaco nunca cai duas vezes no mesmo golpe…)
Com o Command, acabamos transformando o sistema aqui num conglomerado de objetos especialistas, ou melhor, cada um e responsavel por um proceso, por uma regra de negocio, e so interagem entre si quando necessitam que um objeto execute a funçao do outro.

Ex:
Classe IncluirUsuario, Classe ExcluirUsuario, Classe EfetuarCadastro, Classe DesativarCadastro, etc…

Nao eram sete anjos e uma besta? :roll: :lol:

Nao eram sete anjos e uma besta? :roll: :lol:

De fato, a besta sou eu - eram quatro cavaleiros do apocalipse: Fome, Peste, Guerra e Morte

Thiago Senna:

Tentei fazer com que a classe de negócio tivesse um método criar que chamada o método criar do DAO!!!
Ainda sim o método ficou meio porco, ou GOO, como diz o Skill!!!

Porque meio porco. Isso é delegação.
O que tem de especial no IoC ?

Command é legal… para o que se propõe.

É uma ótima maneira de se implementar undo/redo (até o Meyer usa).

jprogrammer:

Thiago Senna:

Tentei fazer com que a classe de negócio tivesse um método criar que chamada o método criar do DAO!!!
Ainda sim o método ficou meio porco, ou GOO, como diz o Skill!!!

Porque meio porco. Isso é delegação.
O que tem de especial no IoC ?

acho que era um problema com a Facade dele(né Thiago)hehe

Vi em algum lugar nesse post alguém mencionado Java, mas não achei para dar o quote : )

Mas enfim,

Uma das minhas preocupações atualmente é se realmente Java é OO, se é uma GOO, ou se realmente é a maioria que não sabe usar Java corretamente.

No quote lá tinha a frase exata que eu queria questionar sobre Java

Eu chuto na alternativa ‘C’.

Ao menos em todos projetos que participei, o que mais aprendi foi como não programar em Java.

Sou um membro do LIPE´s groups: Eu Sei Como Não Programar em Java

Rafael Nunes:

Eu chuto na alternativa ‘C’.

Ao menos em todos projetos que participei, o que mais aprendi foi como não programar em Java.

Sou um membro do LIPE´s groups: Eu Sei Como Não Programar em Java

Hehehe dessa comunidade eu também faço parte.
E poderia citar a de Como Não Tirar Certificações Em Java : )

Mas aidna com foca no Java, get/set ferem a OO, certo? por que estão no JAVA então?
O Shoes vive falando dos JavaBeans(pelo que me lembre mal), por que estão no Java? : )

Não estão NO Java… os setter e getters são métodos comuns, nada especial e a linguagem te dá suporte a criar métodos (ainda bem) …

set/get são convenções para algumas aplicações específicas onde são necessários (ie: webwork popular o bean, aplicacoes que realmente usam javabeans como IDEs & cia) que acabaram sendo usadas incorretamente.

JavaBeans e getters/setters estao no Java pq existem situacoes onde usa-los eh otimo. O problema eh que neguinho abusa, ou usa nas horas erradas, e ai vira antipattern.

Nao eh “getters e setters sao um lixo SEMPRE”, eh “expor dados dos objetos pra outros causa acoplamento desnecessario”

Falando em getters/setters, já viram esse artigo do Holub?

Annotations rula!

Uma coisa que o C# tem (e até o VB) que dá de dez a zero no java são as propriedades. Porque a Sun não implementou isso no java.
ex:

class Funcionario
{
   private int _codigo;
   private String _nome;

   public int codigo
   {
        get
        {
           return _codigo;
        }

        set
        {
             valida();
           _codigo = value;
         }
   }

  //mesma coisa para nome

}

Funcionario f = new Funcionario();
f.codigo  =1;
f.nome = "maria";

jprogrammer, isso é exatamente o que get/set faz. Se fosse tão necessário a ponto de precisar de um construto na linguagem, ok, mas a ideía é que propriedades acessadas desse jeito não devem ser usadas a toroto e direito

E qual a verdadeira diferença disso pros setters/getters ??

Diogenes:

E qual a verdadeira diferença disso pros setters/getters ??

Otimizações á parte, getters e setters são mais lentos, mas oferecem um modo para você mudar a implementação. Do jeito que get/set são usados, nenhuma, só a lentidão desnecessária.

Numa linguagem OO “nata”, você nunca deveria ter como saber se o que você está acessando numa classe é um método ou simplesmente um atributo, e em algumas linguagens você pode até mesmo sobrescrever um método por um atributo (mas não o contrário, por sobrecarga de operadores). Veja Meyer, recomendado.

Mas isso é bem mais elegante do que getters e setters. Outra coisa interessante são as propriedades indexadas.
ex:

class Funcionario
{
  private  int _salarios[];

   public int salario[int mes]
   {
      get
      {
           return _salarios[mes];
       }
  
    }

}

int salarioAtual =   funcionario.salario[Meses.JANEIRO];

Pra mim tanto faria, exceto pelo fato que não gostaria de mais palavras reservadas e conceitos na linguagem para uma cosia tão…secundária.

Uma coisa é como uma linguagem implementa uma funcionalidade e outra é possuir algo que realmente faça a diferença arquiteturalmente…

Não estou puxando o saco do C#.
O java é bem melhor. Mas tem algumas coisas que são bem interessantes outras desnecessárias.

Por sinal, tuh nao tem um desses aih pra dispôr não Phillip? Pagar quase 400 pilas nele tah brabo…

Cara…vale. O livro tem 1000 páginas e fala de todos os tópicos, até de como ensinar oo. Fora que vem com um ambiente Eiffel.

Opa, achei por 250 na livroarbitrio.
Ueba!

Posso estar errado porque faz tempo que não dou uma olhada no C#, mas que eu lembre não era possível definir visibilidades diferentes para o get e o set da propriedade, o que é simplesmente ridículo. Quer dizer que se eu quero que qualquer acesse a propriedade, ele também tem que ser capaz de atribuir-lhe um valor? Coisas de Microsoft…

Não. pode se ter propriedades read-only.

isso é possível

public bool Adult 
 { 
     get
     {
         if (this.age<18)
             return false;
         else
             return true;
     }
 }

Interessante essa discussão sobre os set/get, é ou não bom, certo ou errao.

Mas acho que saiu do foco da minha pergunta(pra variar).

O Java realmente é OO ou é uma GOO, na opinião de vocês?

jprogrammer:

Não. pode se ter propriedades read-only.

Não, não foi isso que eu quis dizer. Quer ter um getter public e um setter protected. Que eu lembre, isso não dá e é ridículo.

Java é OO. Daí a falar como as pessoas usam…

Java é OO. Daí a falar como as pessoas usam… :-)

Hehehe

Porque insistimos em usar ele como GOO, porqueeeeeeeee? hehe :twisted:

PS: já quase voltando a ser vendedor de picolé, lá pelo menso só precisava saber os preços e os sabores

As pessoas fazem isso porque não absorveram o paradigma, por falta de instrução, por diversas razões. Da mesma forma que os usuários utilizam os softwares da pior forma possível. Se você criar um consulta com diversos parâmetros de filtro que permitam a alguém restringir a seleção a um intervalo realmente pequeno mas houver a opção de simplesmente listar tudo e sair caçando visualmente, pode acreditar que o usuário mediano vai usar mais a opção 2…

mister__m:

Java é OO. Daí a falar como as pessoas usam… :-)

Grande base e cultura OO, mas ainda linguagem híbrida.

Rafael e serviço social:

híbrido

{verbete}

Datação

1836 cf. SC

Acepções

■ adjetivo e substantivo masculino

1    Rubrica: genética.

diz-se de ou animal ger. estéril, formado pelo cruzamento de progenitores de espécies diferentes; bastardo [Os exemplos mais conhecidos são o burro e a mula.]

2    Rubrica: genética.

que ou o que é fruto de qualquer cruzamento em que os progenitores possuem genótipos diferentes (diz-se de indivíduo)

3    (1873)Rubrica: lingüística.

diz-se de ou palavra formada por elementos tomados de línguas diferentes, como bicicleta: bi (latim), cicle (grego), eta (dim.f., do italiano etta)

4    Derivação: sentido figurado.

que ou o que é composto de elementos diferentes, heteróclitos, disparatados

Ex.: <um personagem curioso, um h. de homem de negócios e músico> <um estilo h.>

(Fonte: Houaiss)

pcalcado:

mister__m:

Java é OO. Daí a falar como as pessoas usam… :-)

Grande base e cultura OO, mas ainda linguagem híbrida.

Shoes to muito interessado naquela idéia de programar puramente OO que trocams em outro post outro dia, até para ver mesmo como é OO pura, Java puro : )

Seu projeto ja inicio no RIOJUG? Se não gostarai de participar

pcalcado:

mister__m:

Java é OO. Daí a falar como as pessoas usam… :-)

Grande base e cultura OO, mas ainda linguagem híbrida.

Sim, concordo. Mas o mal uso não vem exatamente disso, com certeza

mister__m:

pcalcado:

mister__m:

Java é OO. Daí a falar como as pessoas usam… :-)

Grande base e cultura OO, mas ainda linguagem híbrida.

Sim, concordo. Mas o mal uso não vem exatamente disso, com certeza :-)

Acho que a maioria concorda que o erro está no usar e não no paradigma em si, então gostaria de saber, o que vocês estão fazendo para tentar mudar essa mentalidade de já começar errado a coisa? ou não estão e não acham interessante mudar isso?

mister__m:

Sim, concordo. Mas o mal uso não vem exatamente disso, com certeza :-)

Sim, claro e tanto você está certo que falta de coisas boçais de OO como herança múltipla e asserções passam despercebidos em java

pcalcado:

mister__m:

Sim, concordo. Mas o mal uso não vem exatamente disso, com certeza :-)

Sim, claro e tanto você está certo que falta de coisas boçais de OO como herança múltipla e asserções passam despercebidos em java :(

Discordo. Já vi muita gente sentir falta de herança múltipla em Java porque não sabe OO e pra um modelo em que composição faria muito mais sentido, tinha gente querendo fazer 7 ou 8 hierarquias de classe pra herdar no final…

Nada como ser consultor e ver um projeto diferente por semana pra ficar espantado com a “criatividade” das pessoas.

mister__m:

Discordo. Já vi muita gente sentir falta de herança múltipla em Java porque não sabe OO e pra um modelo em que composição faria muito mais sentido, tinha gente querendo fazer 7 ou 8 hierarquias de classe pra herdar no final… :-)

Isso acotnece com herança simples e interface também. Um modelo real de objetos sem herança de implementação múltipla é bem tendencioso á gambiarras.

Oba, mais uma discussao sobre heranca multipla que nao vai resultar em nada! :mrgreen:

Voltando ao assunto, gambiarra se faz em qualquer linguagem. Gambiarra se faz no Portugues, se quiser (e o que eh licenca poetica se nao gambiarra?), entao, nao vale a pena ficar botando a culpa na arma.

Existem varios Design Patterns em volta de herança múltipla que são bem legais. Na época que eu trampava com c++ usava eles esporadicamente. Mas via de regra, qualquer uso fora os bem conhecidos era gambiarra forte.

E hoje com os frameworks AOP java também tem herança múltipla.

louds:

E hoje com os frameworks AOP java também tem herança múltipla.

Naquelas. O eterno problema em Java (que existe com interfaces também) de se diferenciar qual método está sendo chamado quando os nomes colidem ainda exige gambiarras mil, como aplicar aspectos em cima das chamadas pra poder capturar o tipo que foi usado, além de outros malabarismos.