It’s knowledge, baby

Welcome to the jungle!

Passar atributo ou objeto?

Oi pessoal,

Este post é sobre uma dúvida (que me deu um trabalho infeliz) que surgiu entra a equipe de análise do SAEO (eu e o Leonardo).

O sistema está sendo feito utilizando o paradigma de orientação a objeto e surgiu a dúvida de quando passar um atributo ao método ou quando passar um objeto.

Conversando com alguns programadores e analistas experientes, vimos que o Hibernate e, consequentemente, o JPA – Java Persistence API (BTW, see here which difference has between Hibernate and JPA) utiliza a passagem por atributo.

Nossa conclusão foi que quando não for para alterar os dados internos do objeto, passamos o atributo:

$funcionárioTemp = new Funcionario();

$funcionário = $funcionárioTemp->Carregar($id);

Quando formos alterar os dados internos do objeto, como em uma operação de alterar ou cadastrar o objeto, passamos o objeto, pois entendemos que passar apenas os atributos quebaria a idéia do paradigma de OO. Exemplo:

$funcionário = new Funcionario($nome, $telefone, …);

$funcionário->Cadastrar(); // Retorna true ou false para qualquer possível verificação.

O que você acha? Dê sua opinião! A equipe de análise (eu e Leonardo) e a equipe de desenvolvimento (Leonardo e eu) do SAEO agradecemos! =)

Obs.: Só lembrando que no SAEO utilizamos o padrão de projeto (Design Pattern) DAO.

agosto 15, 2009 - Posted by | Computação | , , , ,

10 Comentários »

  1. Acho que isso é uma escolha de design, tudo vai depender do contexto. Mas o que vc disse aí faz sentido mesmo🙂

    Continue assim, padawan.

    Comentário por Ícaro | agosto 20, 2009

  2. To emocionado!!! O primeiro comentário do Ícaro sobre um post meu que ele não mete o pau \o/ hauhauhau

    Comentário por Marco Rosner | agosto 24, 2009

  3. Bicho, eu passaria sem dúvida o objeto… mas depende muito do caso. Se você precisa de apenas alguns poucos atributos do objeto, talvez por questão de performance seja melhor passar os atributos em vez de um objeto todo (pensando em objetos grandes, com muuuuitos atributos).

    Mas no geral, eu sou a favor de passar objeto…

    Comentário por Max | agosto 31, 2009

  4. Opa Marco, blz?

    Bom, pelo que você mostrou do código, isso não parece um DAO, e sim um Active Record (http://pt.wikipedia.org/wiki/Active_record).

    No caso do active record, a segunda opção é a mais aceitável.

    Caso queira implementar um DAO, a situação é um pouco diferente:

    FuncionarioDAO dao = new FuncionarioDAO(); //Pode usar Dependency-injection aqui ou não, se preferir…
    Funcionario funcionario = new Funcionario(nome,telefone,…);
    dao.salvar(funcionario);

    Funcionario funcionario = dao.procurarPorId(id);
    funcionario = dao.procurarPorExemplo(funcionarioExemplo);

    Isso que vc faz é bizarro:
    $funcionárioTemp = new Funcionario();

    $funcionário = $funcionárioTemp->Carregar($id);

    criar um funcionario fantasma, e depois carregar um funcionario via um funcionario fantasma…

    Uma melhor alternativa (ainda usando o Active Record) seria fazer

    $funcionárioTemp = new Funcionario($id);

    $funcionário = $funcionárioTemp->Carregar();

    Algo do tipo…

    Mas ainda prefiro o DAO.

    Espero ter ajudado,
    []’s

    Comentário por Mário Peixoto | setembro 22, 2009

  5. Consertando o link pro ActiveRecord

    http://pt.wikipedia.org/wiki/Active_record

    Tô com a “pequena” impressão que comentei isso sem ver direito a situation aí. Mas não retirarei o comentário, fica assim mesmo

    Comentário por Ícaro Medeiros | setembro 22, 2009

  6. Opa Mario, tranquilo cara =)

    Seguinte, a observação foi só pra dizer que utilizamos o padrão de projeto e não que o código que eu coloquei envolvia o DAO (não a primeiro momento). Optamos por dividir o sistema em camadas (essa é uma das prerrogativas do DAO), então, pra isso, colocamos apenas o código relacionado ao DAO na classe e não na interface (Obs.: O código que eu coloquei vai na interface). Só pra ser mais preciso, utilizamos as camadas (parecido com padrão de projeto MVC) interface, controle (classes) e banco de dados (DAO). O seguimento de um carregar funcionário seria:

    (na interface)
    $funcionarioTemp = new Funcionario();
    $funcionario = $funcionarioTemp->carregarfuncionario($id);

    (na classe)
    public function carregarFuncionario($id){
    $resultado = $this->dao->CarregarFuncionario( $id ); // O objeto DAO é instanciado no construtor da classe, tipo: $this->dao = new FuncionarioDAO();
    return $resultado;
    }

    (no dao)
    public function CarregarFuncionario( $id )
    {

    $consulta = $this->database->Fetch(” SELECT u.*, p.tipo FROM t_usuario u, t_perfil p WHERE u.id = ‘$id’ AND u.id = p.t_usuario_id “);

    if( $consulta != FALSE and mysql_num_rows( $consulta ) > 0 )
    {

    $rows = $this->database->getRow();
    $funcionario = $this->ArrayParaFuncionario( $rows );

    return $funcionario[0];
    }
    else if( mysql_num_rows( $consulta ) == 0 )
    {
    return FALSE;
    }
    }

    entendeu?

    Quanto a forma de fazer, colocando o $id no construtor ou na função, não era bem isso a dúvida em questão e sim se deve passar o objeto ou um atributo na chamada de uma função. Mas com relação ao que você falou, passamos no construtor quando precisamos das informações do objeto (ou seja, passar o objeto pra a função) quando precisamos de apenas um atributo, não vejo muita diferença em passar no construtor ou direto na chamada da função. Pode haver questões teoricas, mas na prática, no desempenho, deve ser a mesma coisa. Não sei. Mas vou conversar com o Leonardo aqui pra ver o que ele acha disso.

    Valeu de qualquer forma! =)

    Comentário por Marco Rosner | setembro 23, 2009

  7. Não tô afim de ficar muito chato e longo não mas tipo

    “controle (classes)”.

    E a parte do modelo e visão não tem classes não? O que tem lá então, gnomos?

    Não sou guru de OO, DAO, design patterns não, mas algo me cheira mal aí nessa explicação. Se possível ler o último post do meu blog.

    Comentário por Ícaro Medeiros | setembro 23, 2009

  8. Olá Marco,

    MVC e Camadas são conceitos diferentes, que podem ser aplicados em conjunto ou não.

    MVC = comunicação entre componentes
    Camdas = agrupamento de componentes

    Uma boa referência para o assunto http://martinfowler.com/books.html#eaa

    Comentário por Diogo Cabral | setembro 23, 2009

  9. Prezado Icaro, leiamos comigo no replay: “utilizamos as camadas (parecido com padrão de projeto MVC) interface, controle (classes) e banco de dados (DAO).”

    Ou seja, ele é feito em camadas (interface – que PARECE com a vision do MVC, as classes do sistema – que PARECE com o model do MVC – e as CLASSES do banco de dados – implementação do patrão de projeto DAO.)

    Fui mais claro dessa vez? O sistema NÃO usa o MVC, usa apenas o padrão de projeto DAO para acesso ao banco de dados.

    Diogo, valeu pela informação, eu nunca tinha visto esse conceito, mas entendia a idéia por trás dele =)

    Comentário por Marco Rosner | setembro 24, 2009

  10. É como eu fiz o trabalho de ES da UFAL, 3 camadas bem separadas de interface, modelo de negócios e acesso ao banco de dados (e aqui eu realmente usava um DAO GENÉRICO), mas n era MVC.

    O que precisa é ter cuidado ao falar de conceitos assim à toa. Leia o post lá que eu passei. Se vc for numa entrevista e perguntarem se vc sabe MVC, diga sim ou não, não existe talvez.

    Comentário por Ícaro | setembro 25, 2009


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: