Estrutura Procedural não é melhor para sistemas Empresarias

Programação Arquitetura
#41

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 :wink:

#42

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);
#43

[quote=fabgp2001][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[/quote]

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

#44

É 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!

#45

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

#46

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

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!

#47

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!!!

#48

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: :smiley:

#49

Nao eram sete anjos e uma besta? :roll: :lol: :smiley: [/quote]

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

#50

[quote=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!!![/quote]

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

#51

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

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

#52

[quote=jprogrammer][quote=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!!![/quote]

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

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

#53

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 :frowning:

#54

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

#55

[quote=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[/quote]

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? :slight_smile:
O Shoes vive falando dos JavaBeans(pelo que me lembre mal), por que estão no Java? : )

#56

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.

#57

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” :wink:

#58

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

Annotations rula!

#59

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";
#60

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 :wink: