quarta-feira, 27 de junho de 2012

Ordenando array de objetos pelo atributo no php

Olá meus amigos e amigas tudo bem? Hoje vou ser breve.

Se vc precisou ordernar um array de objetos pelo atributo aqui esta a solução.
Não importa se o atributo é privado ok? Vamos utilizar o usort do php que recebe como parametro o array e um callback que é nossa função capaz de ordenar esse cara.

  1. <?php
  2. /* Funcao que ira ordenar */
  3. function verificador($obj1, $obj2) {
  4.     if ($obj1->getOrdem() < $obj2->getOrdem()) {
  5.         return -1;
  6.     } elseif ($obj1->getOrdem() > $obj2->getOrdem()) {
  7.         return +1;
  8.     }
  9.     return 0;
  10. }
  11. /* Classe de exemplo */
  12. class Pessoa{
  13.    
  14.     private $idade;
  15.     private $ordem;
  16.    
  17.     public function getIdade() {
  18.         return $this->idade;
  19.     }
  20.     public function setIdade($idade) {
  21.         $this->idade = $idade;
  22.     }
  23.     public function getOrdem() {
  24.         return $this->ordem;
  25.     }
  26.     public function setOrdem($ordem) {
  27.         $this->ordem = $ordem;
  28.     }
  29. }
  30. /* O array que vamos colocar os objetos*/
  31. $array_objetos = array();
  32. /* 6 objetos pessoa com atributos aleatorios */
  33. for($i = 0; $i < 6; $i++):
  34.     $objeto = new Pessoa();
  35.     $objeto->setIdade(rand(20, 60));
  36.     $objeto->setOrdem(rand(0,30));
  37.    
  38.     $array_objetos[] = $objeto;
  39. endfor;
  40. /* Mostrando o array de objetos criado */
  41. echo "<h1>Array de objetos desordenados</h1><br>";
  42. var_dump($array_objetos);
  43. echo "<br><hr><br>";
  44. /* Usando o usort */
  45. usort($array_objetos, 'verificador');
  46. /* Mostrando o array de objetos criado */
  47. echo "<h1>Array de objetos ORDENADOS pelo atributo ordem</h1><br>";
  48. var_dump($array_objetos);
  49. echo "<br><hr><br>";
  50. ?>

Bem, espero ter ajudado... hehehe

terça-feira, 5 de junho de 2012

Observer - Design Patterns

Design Patterns Observer

Neste artigo abordaremos a modelagem e prática de um padrão de projeto (Design Patterns) bastante importante do GoF (Gang of Four) que é o Padrão Observer.

A essência desse padrão está na possibilidade de uma classe poder fazer uma 'notificação' a um conjunto de classes associadas de que o Estado (Conjunto de Atributos) dela foi alterado por algum motivo. A definição do padrão observer descrita pelos criadores é a seguinte:
"Definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente." [GoF]
Você deve estar pensando "Eu posso fazer essa notificação manualmente ou até mesmo utilizando eventos como actionPerformed para fazer a notificação através de chamas a métodos de cada instância (ufaa)". Porém dessa maneira você estará criado um sistema com alto acoplamento e de difícil manutenabilidade.
Utilizando o padrão Observer conseguimos reduzir o uso do relacionamento bidirecional por meio de interfaces e classes abstratas, separando a abstração para ter um alto nível de coesão e baixo acoplamento.
Para ficar mais intuitivo vamos fazer o uso de exemplos. Imagine um operário de obras que esta trabalhando em uma construção junto com seus 'companheiros'.. O fato de uma sirene tocar implica em uma mudança (mudança de estado), que pode ser um sinal para a hora do almoço, pode ser o final do expediente e etc.
Temos então o seguinte ambiente, o objeto observável (Sirene) e os observadores (Operários). Quando o objeto observável alterar o seu estado, enviará um sinal sonoro (mensagem) alertando os objetos observadores.
Padrões de Projeto - Observer








Vamos definir as abstrações, chamaremos de Operário a interface do operário e Sirene a interface da sirene como mostrado abaixo:
Padrões de Projeto - Observer Interface
Perceba que as duas abstrações se relacionam entre si, relacionamento entre interfaces, ou seja, estamos deixando nossa aplicação mais independente separando-as das classes concretas
Na interface Sirene nós especificamos parte do que ela poderá fazer, no caso adicionar ou retirar um observador, da mesma maneira seguiremos com o Operário, sendo que, no mais alto nível de abstração, o mínimo que um observador irá sofrer é o fato de ser notificado (atualizar). Se o operário vai ou não responder ao chamado não cabe a interface.
Com as interfaces em mãos podemos montar nosso diagrama, criaremos duas classes que vão implementar essas interfaces, sendo elas SireneConcreta e OperarioConcreto, conforme vemos abaixo:
Diagrama de Classe Observer
Na classe SireneConcreta criaremos todos os outros métodos necessários para o bom funcionamento da sirene e o método notificarObservadores que ira "varrer" o ArrayList que contem uma lista de observadores.
A classe concreta não foge a regra, irá implementar além do método atualizar todos os métodos dos operários.
Tendo toda a estrutura diagramatizada você poderá utilizar o próprio programa de modelagem (se estiver disponível) para gerar o código da nossa estrutura. Eu estou utilizando para esse fim o Enterprise Architect, porém qualquer um com suporte a UML 2.0 (de preferência) poderá ser usado, seja Netbeans, ArgoUML, ou plugins para eclipse..
Implementando nossas interfaces, teremos,
Interface Sirene:
 
public interface Sirene {
 
 public void adicionarObservador( Operario o );
 public void removerObservador( Operario o );
 
}
 
Interface Operario:
 
public interface Operario {
 
 public void atualizar(Sirene s);
 
}
 
Com as nossas abstrações prontas, podemos dar inicio a construção das classes concretas, teremos,
Classe SireneConcreta:
 
import java.util.ArrayList;
import java.util.Iterator;
 
public class SireneConcreta implements Sirene {
 
 private Boolean alertaSonoro = false;
 private ArrayList observadores = new ArrayList();
 
 public void alterarAlerta(){
  if(alertaSonoro)
   alertaSonoro = false;
  else
   alertaSonoro = true;
  notificarObservadores();
 }
 
 public Boolean getAlerta(){
  return alertaSonoro;
 }
 
 public void adicionarObservador(Operario o) {
  observadores.add(o);
 }
 
 public void removerObservador(Operario o) {
  observadores.remove(o);
 }
 
 private void notificarObservadores(){
  Iterator i = observadores.iterator();
  while(i.hasNext()){
   Operario o = (Operario) i.next();
   o.update(this);
  }
 }
}
 
Perceba que chamamos o método notificarObservadores exatamente quando o objeto SireneConcreta altera seu estado. Na implementação do método notificarObservadores nos fazemos uma varredura simples e informando a cada instância dele mesmo que o objeto que estava sendo observado mudou seu estado. Repare que estamos trabalhando sempre com as Interfaces ao invés das classes concretas.
Classe OperarioConcreto:
 
public class OperarioConcreto implements Operario {
 
 private SireneConcreta objetoObservado;
 
 public OperarioConcreto(SireneConcreta o){
  this.objetoObservado = o;
  objetoObservado.adicionarObservador(this);
 }
 
 public void atualizar(Sirene s) {
  if(s == objetoObservado){
   System.out.println("[INFO] A Sirene mudou seu
estado para: " + objetoObservado.getAlerta());
  }
 }
}
 
Com o construtor dessa maneira podemos ao passo de criar o observador e já setar como parâmetro o objeto observado, logo abaixo podemos chamar o método adicionarObservador que passa por referência a sua própria instância!. Interessante, não?
Quando o método atualizar é chamado nós precisamos checar se a sirene que alterou o estado é a mesma que estamos observando.
Com toda estrutura implementada é hora de testar, para tal vamos criar a classe GerenciadorSirene:
 
public class GerenciadorSirene {
 
 public static void main(String[] args) {
 
  SireneConcreta sirene = new SireneConcreta();
  // Sirete ja começa com valor default false
 
  OperarioConcreto obs1 = new OperarioConcreto(sirene);
  OperarioConcreto obs2 = new OperarioConcreto(sirene);
  // Já passando a sirene como parametro
 
  sirene.alterarAlerta();
  // Nesse momento é chamado o método atualizar
  // das instâncias obs1 e obs2, saída:
  // [INFO] A Sirene mudou seu estado para: true
  // [INFO] A Sirene mudou seu estado para: true
 
  sirene.alterarAlerta();
  //[INFO] A Sirene mudou seu estado para: false
  //[INFO] A Sirene mudou seu estado para: false
 
  // Obs: 2 saídas porque temos 2 observadores
 }
}
 
É possível dar nomes aos observadores criando um atributo String dentro de OperatorConcreto e passando seu nome para o construtor como segundo parâmetro, para ficar mais fácil diferenciá-los.

Artigo original de: http://blog.rafaelcapucho.com/

sábado, 2 de junho de 2012

#TDC2012 São Paulo vamos?

Amigos e amigas tudo bem? Espero que sim!
Hoje não venho aqui para inserir nenhum artigo mas sim falar sobre o TDC2012 pois é pessoal o TDC hoje é um dos maiores eventos do Brasil na reunião de comunidades de desenvolvimento. Na minha opinião é o maior e melhor evento quando refere-se a integração das comunidades E a disseminação do conteúdo.

E onde será? Quando? Para pessoas do estado de SP o TDC será do dia 04 ao dia 08 de Julho e serão 5 dias de evento com 35 trilhas e 240 palestras. Espero vocês lá hein?

 The Developers Conference 2012, um evento organizado pela Globalcode 
Universidade Anhembu Morumbi - Campus Vila Olimpia

PS: Não estou recebendo NADA para divulgar o evento, o MEU intuito é realmente unir as comunidades de desenvolvimento de software.

sexta-feira, 1 de junho de 2012

Diagrama de pacotes uml exemplo

Amigos e amigas tudo bem? Hoje eu vou retirar um pouco a parte técnica dos meus artigos e voltar a falar sobre UML... Mas, pq? Veja bem, mesmo vc montando tudo tecnicamente perfeito é preciso que isso esteja bem definido e nada como a UML para resolver isso. Não entendeu? Eu particularmente não gosto daquele estilo de pessoa que não quer explicar, que tenta explicar algo apenas para te complicar mais e vc achar que o cara é o fodão(o que na maioria das vezes não é verdade). Bem deixa eu parar de viajar e voltar ao assunto sobre "O POR QUÊ A UML DEIXA BEM DEFINIDO UM SISTEMA"... 

Vamos imaginar que você é um empresario de uma grande empresa(bom hein? Se vc for essa pessoa tem como me emprestar uns trocados?) E então precisa mostrar o andamento financeiro da empresa como uma visão geral, AMPLA de tudo que esta acontecendo o que vc iria fazer? Entregrar relatórios com milhões de páginas cheias de números ou basicamente montar gráficos para que as pessoas se localizem facilmente e posteriormente se aprofundem no caso da empresa? Pois bem, o diagrama de pacotes é basicamente essa visão geral das camadas do nosso sistema. Ele já existia nas versões anteriores da UML, mas foi considerado totalmente independente a partir da UML 2. Tem por objetivo representar de forma clara os sub-sistemas englobados por um sistema de forma a determinar as partes que o compõem. 
Pode ser utilizado de maneira independente ou associado com outros diagramas. Veja um exemplo desse carinha:


Nesse caso definitivamente buscamos "visualizar" o sistema de cima e seria mais o menos essa a visão. O diagrama de pacotes(assim como toda a UML) não segue uma regra a RISCA de o que devemos inserir como "pacotes", eu particularmente prefiro inserir camadas que deixa bem claro para um desenvolvedor novo em um projeto X como se trabalha aqui. 

Veja outro exemplo, vamos supor que trabalhamos em um projeto que utiliza Yii Framework (Framework PHP) e Propel(ORM) e gostariamos de inserir uma camada central que fosse capaz de fazer a ligação dos dois frameworks com baixo acoplamento, fazendo isso poderiamos mudar facilmente o propel por exemplo para injetar um Doctrine e para entender essas camadas por cima iriamos montar o diagrama de pacotes que seria mais o menos assim:

Esse já poderia ser um módulo ou sub-sistema mas esse assunto não vem ao caso, olhando ele por cima veja o que temos, uma camada do propel que chamamos de Infraestrutura, outra de Negocio que é uma classe nossa que irá fazer as chamadas ao Yii e as camadas do mesmo com o controller, os forms, o config,views e languages.
Veja que em instantes já entendemos a arquitetura geral de distribuição desse cara e quando criarmos métodos na camada de negócio vamos montar um código muito mais coeso sem dúvidas.

Conclusão
- O diagrama de compomentes esta amplamente associado a tecnologia que utilizamos 
- Apresenta uma visão estática de como o sistema será implementado e quais os seus módulos de software.
- Destaca a função de cada módulo monstrando a utilidade do mesmo em um certo sistema