O problema

Em um projeto pessoal recente precisei fazer a integração entre três sistemas distintos, na verdade os sistemas são distintos, mas não deveriam ser. Trata-se de um site e o que ocorre é que esse mesmo site possui três módulos (sistemas) que estão em plataformas, linguagens e lugares diferentes. Conclui-se que é um projeto que foi crescendo desordenadamente e que em nenhum momento ninguém pensou em uma maneira de organizar melhor os módulos e realizar as integrações. Como esses módulos foram feitos em linguagens e plataformas diferentes, o requisito número um do cliente era que esses módulos se comunicassem e que essa comunicação fosse transparente pra ele e para quem fosse administrar o sistema.

Cenário atual

O site é um pequeno site de e-commerce e dos três módulos existentes, um diz respeito ao frontend/backend do site e é feito com .NET/SQL Server, o outro módulo é o backend de vendas e é feito com PHP/MySQL e o último módulo é o de newsletter (mailing) que também está em PHP/MySQL. O módulo de vendas foi o último a ser desenvolvido e deveria ser mantido, o problema é que o administrador do sistema precisa “inputar” todas as vendas na mão, isso mesmo, na mão! Atualmente, quando um cliente tem interesse em algum produto do site, ele envia um email ao administrador informando qual(is) o(s) produto(s) ele tem interesse e os seus dados pessoais, e por sua vez o administrador entra no módulo de vendas, cadastra esse novo cliente, cria um pedido de venda, gera um login/senha para esse cliente e envia por email para que ele possa se autenticar no módulo de venda, concluir a compra e efetuar o pagamento.

Além de ser algo totalmente mecânico e nada prático, não há nenhuma relação entre os módulos do site e o administrador precisa reproduzir os dados do produto, que já existe em um módulo, em outro. Eram esses problemas que deveriam ser remediados.

Requisitos do cliente

Um dos requisitos do cliente, era de que o site (frontend e backend) deveria ser construído novamente, pois o atual além de ter sido construído em uma plataforma que ele não tinha mais interesse em manter, também estava incompleto e apresentando problemas, portanto o primeiro requisito era refazer todo o site com PHP/MySQL.

O segundo requisito era que o processo compra de produtos deveria ser todo feito através do site, pelo cliente, e não da forma arcaica como é atualmente e que foi descrita acima.

O terceiro requisito era que o módulo de vendas deveria ser mantido, pois ele atendia o que o cliente precisava, sendo assim o sistema que eu iria desenvolver deveria alimentar diretamente esse módulo de vendas.

Estrutura do módulo de vendas

Felizmente o módulo de vendas estava construído de uma maneira que facilitou o meu trabalho, quem o desenvolveu se preocupou em criar classes de modelo, uma camada de persistência e uma camada de negócio, portanto pude pensar em uma arquitetura simples em funcional muito em função disso.

Arquitetura pensada

Tentei pensar em algo que não criasse uma dependência entre os sistemas e que me fizesse mexer o minímo possível, ou nada, no módulo de vendas que seria mantido. Outros fatores que levei em consideração era que eu queria algo fácil de implementar, de dar manutenção e que de certa forma fosse rápido de desenvolver.

Conclui o desenvolvimento do (frontend/backend) e parti para pensar em uma arquitetura que me permitisse fazer tudo o que citei acima e que além disso me permitisse utilizar a boa estrutura que eu encontrei no módulo de vendas.

Para construir o site utilizei o Code Igniter, que é um framework que tenho prática, e também é leve e rápido de desenvolver, mas o que vale ressaltar é que arquitetura é algo que é independente de framework, portanto se eu tivesse utilizado qualquer outro framework, ou até mesmo se eu não tivesse utilizado nenhum framework, não faria a mínima diferença. Nesse caso os frameworks escolhidos só entram como facilitadores na implantação da arquitetura.

Mas voltando ao foco inicial, que é explicar a arquitetura, o que eu pensei foi em criar um Web Service com as operações específicas para tudo o que eu precisaria fazer no módulo de vendas, ou seja, eu precisaria identificar todas as ações que eu precisaria realizar para fazer essa integração e alimentar esse módulo. Na verdade, além de alimentar eu também precisaria recuperar algumas informações do módulo de vendas. Como os módulos (site, vendas, newsletter) ficariam provavelmente em servidores diferentes, em bancos diferentes e em estruturas diferentes essa era a forma mais limpa de realizar a integração sem causar dependência entre esses módulos e com isso dar manutenção seria bem mais fácil.

Como já estava definido que eu iria utilizar Web Service, eu optei por utilizar o formato RESTful, pois eles se encaixava perfeitamente na minha necessidade: me trazia simplicidade, praticidade, facilidade, além do que no meu caso a aplicabilidade de ROA, que é o conceito que Web Services RESTful utilizam, era muito mais evidente do que a abordagem de serviços.

O próximo passo era identificar os recursos necessários e criar as URI que eu utilizaria nos requests do meu Web Service REST, então ficou dessa forma:

• user/new
• user/retrieve/email
• user/retrieve/cpf
• order/new
• order/save/products
• order/retrieve/last
• shipping/calculate

Para desenvolver esse Web Service RESTful resolvi utilizar o Zend Framework, pois ele possui alguns componentes que me ajudariam a desenvolver esse Web Service mais rápido, como o suporte a Web Services RESTful, por exemplo, o ZF também tem uma API para trabalhar com JSON muito boa, então esse foi outro componente do ZF que eu resolvi utilizar.

Como no módulo de vendas já existiam classes de modelo que representavam as entidades do meu domínio, o que eu fiz foi criar uma estrutura JSON semelhante as essas entidades e que representaria os requests/responses do meu Web Service RESTful. Paralelo a isso criei algumas classes de apoio que serviriam como os Marshallers e Unmarshallers do Spring. Marshallers e unmarshallers são como data mappers, e no meu caso servem para eu mapear um objeto JSON para um objeto PHP (classes modelo) e também realizar o inverso.

Dessa forma com objetos JSON convertidos para objetos PHP que representavam as minhas classes modelo eu poderia usar a camada de persistência existente na aplicação para persistir todo objeto, então no caso de salvar um novo usuário, ficou assim:

function saveUser($user) {	
	$userObject = Unmarshaller::user(Zend_Json::decode($user));	
	$conn 	    = DB::getConnectionHandler();
 
	$result 	= $conn->user->save($userObject);	
 
	if ( $result )
		return array('status' => TRUE, 'response' => 'Usuário cadastrado com sucesso.');	
	else
		return array('status' => FALSE, 'response' => $conn->ErrorMsg());	 
 
}

Bem simples, né? No exemplo acima, criei algumas classes estáticas (utilitárias), a primeira me retorna um objeto de conexão com o banco de dados e a segunda classe representa o unmarshaller para transformar um Objeto JSON em uma classe de modelo que representa um usuário, após isso foi só persistir o usuário e retornar as mensagens correspondentes para quem está acessando recurso.

Visão geral

No fluxo de salvar um novo usuário, teríamos:

1) Site (módulo site) deseja salvar um novo usuário;
2) Site monta um objeto JSON com os dados que representam o novo usuário;
3) Site acessa o Web Service RESTful do módulo de venda através do recurso user/new;
4) No módulo de venda, o método mapeado para o recurso user/new, faz unmarshaller do objeto JSON mapeando os valores desse objeto JSON para uma classe de modelo;
5) O usuário é persistido através do objeto que foi mapeado no passo anterior;
6) O Web Service RESTful retorna a mensagem correspondente para o site.

Quando se fala em arquitetura é comum pensarmos em algo complexo, cheio de tecnologias, frameworks e etc, mas o foco de arquitetura não deve ser esse, o foco de arquitetura deve ser pensar em uma estrutura que prime pela organização, relacionamento e reuso dos componentes de softwares envolvidos em um sistema, onde o intuito deve ser facilitar e não complicar.

Hoje em dia vejo muitas aplicações que cometem esse mesmo equívoco que eu cometia há alguns anos atrás, fazem o uso do recurso (que nesse caso passaria a não ser um recurso) sem saber a razão, isso me remete até ao meu primeiro post.

Essa questão sobre o uso de getters e setters tem muito a ver como as coisas são feitas hoje em dia em relação ao desenvolvimento de software, principalmente em desenvolvimento para web, eu diria. Perdeu-se o seu principal foco, razões e objetivos e com isso surgem casos como o uso desenfreado dos getters e setters.

Getters e setters devem ser originalmente usados para encapsular seus atributos, evitando assim que eles sejam acessados diretamente. Dessa forma podemos aplicar determinada regra de negócio antes de atribuir valor a um atributo. Não é necessário, por exemplo, usar getters e setters em alguns objetos que serão imutáveis, ou então, apenas em objetos que servem para receber valor, nesses casos os getters e setters tornariam-se desnecessários.

Hoje em dia só faço o uso dessa dupla, quando realmente sinto essa necessidade, quando sei que meu atributo poderá vir a ter uma regra de negócio específica ou por algum motivo muito peculiar (ver mais abaixo), caso contrário, não uso. Em muitos casos passar os valores para o objeto utilizando o método construtor já resolveria o problema de forma simplória.

Deve-se considerar também, a possibilidade do seu software ser uma API aberta, usada e modificada por outros desenvolvedores, onde talvez você não tenha necessidade de um getter/setter, mas provavelmente para fornecer uma maior flexibilidade do código – considerando a possibilidade dele ser extendido – talvez seja interessante disponibilizar os tais pares. Da mesma forma que para debugar um código, talvez seja interessante fazer o uso de getters e setters para saber o valor que está sendo atribuído a uma variável, ao invés de espalhar milhões de breakpoint pelo código.

Links Interessantes
Fowler e Getters
Getter Erradictor
Why getter and setter methods are evil
Como não aprender Java e orientação a objetos

A idéia foi criar um problema simples e a partir disso coletar as implementações nas mais diversas linguagens, das mais loucas as mais famosas.

Eu dei a minha colaboração na implementação para PHP 5.

Reparem na “facilidade” que seria resolver o problema usando SED, que na verdade não é considerada uma linguagem de programação.

É a famosa discussão da melhor linguagem. Para mim não existe a melhor linguagem, cada uma tem sua finalidade e consequentemente seus pontos fortes e fracos. Nada impede que um sistema tenha várias linguagens e plataformas, não é mesmo? Aliás, felizardo são aqueles que tem essa visão e know-how de mixar tecnologias. Vide Google, que dentre outras usa Python, Java e C++.

Acompanhando a discussão e até participando, refleti sobre alguns pontos e percebi um detalhe que até então estava passando desapercebido por mim: frameworks só deveriam ser usados por quem consegue e tem responsailidade ao usá-los.

A frase acima parece meio ambígua e talvez até agressiva, concordo, mas posso explicar melhor.

Tenho visto constantemente em fóruns de discussão, listas e etc, pessoas com dúvida sobre o framework X, só que grande parte dessas dúvidas não são em função de uma limitação do framework X e sim uma limitação do desenvolvedor. Vejo que por exemplo, com essa explosão dos frameworks WEB/MVC, que muitos desenvolvedores fazem o uso do framework X de forma famigerada ferindo todos os conceitos de MVC, conseguem simplesmente esquecer que o framework foi construído dentro desse padrão e que o ideal é que ele permaneça dessa forma. Quando digo isso, não digo isso porque o framework X deve ser imutável, na verdade a grande maioria dos frameworks oferece flexibilidade o suficiente para ser extendido e até alterado (que na maiora das vezes não é a melhor decisão), mas de forma que seja respeitado a sua arquitetura e ‘boas práticas’ de design de uma aplicação.

Quase todos esses frameworks foram construídos usando OO, mas mesmo assim a maioria dos desenvolvedores que usam esses frameworks não conhecem os principais (básicos) conceitos de OO e com isso acabam tomando decisões que no futuro irá prejudicar o projeto como um todo e consequentemente irão ter o seu filme queimado. Em muitos casos a aplicação correta dos conceitos de OO resolveriam de forma elegante e reutilizável aquele problema que outros optam por resolver de forma bisonha.

Onde eu quero chegar com tudo isso?

O que eu quero dizer é que todos deveríamos nos preocupar em entender como as coisas funcionam antes mesmo de usá-las, aprendi isso há bastante tempo atrás com um amigo meu na época em que agia da mesma forma que estou citando aqui, portanto compreendo perfeitamente algumas pessoas ainda agirem dessa forma, principalmente as mais inexperientes, por isso resolvi ter a iniciativa de escrever esse post e talvez gerar uma reflexão. Não sou o dono da verdade, não construo os melhores softwares do mundo, mas procuro sempre saber e entender o que eu estou usando e o que estou fazendo, pois com isso evito problemas para mim e para o meu projeto. E o principal é que evoluo.

Dicas

Antes de usar algo, procure se perguntar:

- O que eu preciso?

- Como “x” funciona?

- Usar “x” resolve o meu problema?

- “x” vai me ajudar ou atrapalhar?

- Quais são as outras alternativas a “x”?

Acredito que com respostas para as questões acima é possível ter uma resposta que satisfaça a necessidade real do problema e que principalmente nos deixe com a sensação de que o melhor possível foi feito, pelo menos pensado foi. E se mesmo assim algo der errado, como conhecemos o problema e a solução que fracassou, fica mais fácil (ou menos difícil?) de identificar e resolver.