Law of Demeter
A lei de Demeter é um conjunto de regras para construir sistemas visando baixo acoplamento, também conhecida como Princípio do menor Conhecimento e Fale somente com os amigos. Apesar do nome, Demeter não foi o autor, Demeter é o nome do projeto conduzido pela universidade Northeasterns University em 1987 liderado pelo Dr. Karl Lieberherr. Foi projeto Demeter que as leis foram criadas e por isto o nome.
Em linhas gerais, as regras são:
Em orientação a objetos, definido que uma unidade=método de um objeto, a lei é traduzida da seguinte forma:
Um método M de um objeto O somente poderia acessar métodos de outros objetos que sigam as diretrizes:
-
Seja parâmetro de M
-
Um objeto que M criou
-
Um método do próprio objeto O
-
Objeto diretamente relacionado com o objeto O
-
Uma variável global acessível pelo objeto O
Para não ficar muito abstrato, vamos aos exemplos:
Seja parâmetro de M:
public class A{
public void FazAlgumaCoisa(B parametro){
parametro.FazOutraCoisa();}
}
Um objeto que M criou:
public class A{
public void FazAlgumaCoisa(){
B objetoB = new B();
B.FazOutraCoisa();}
}
Um método do próprio objeto O
public class A{
private void FazOutraCoisa(){
//faz algo}
public void FazAlgumaCoisa(){
FazOutraCoisa();}
}
Objeto diretamente relacionados com o objeto O
public class B{
public void FazOutraCoisa(){
//Faz algo}
}
public class A{
private B _objetoB;
A(){_objetoB = new B();}
public void FazAlgumaCoisa(){
_objetoB.FazOutraCoisa();}
}
Um dos grandes problemas que temos na manutenção de sistemas OO é o alto acoplamento, ou seja, nossos objetos “falam” com muitos objetos, e quando isto acontece, se eu alterar um objeto no sistema, posso ter efeitos colaterais nos chamadores. A lei de Demeter como vimos, ajuda a diminuir este acoplamento. Algo do tipo
public class C{
public void FazMaisOutraCoisa(){
//Faz algo}
}
public class B{
public C FazOutraCoisa(){
return new C();}
}
public class A{
private B _objetoB;
A(){_objetoB = new B();}
public void FazAlgumaCoisa(){
_objetoB.FazOutraCoisa().FazMaisOutraCoisa();}
}
fere a lei de Demeter, pois não estou mais falando com um “amigo” e sim com o método de C que é o objeto de retorno de B, o “estrangeiro”. Agora nossa classe A tem acoplamento com B e C. Se alterar algo em C, tenho efeitos em A. Sacaram ao que leva a lei de Demeter?
Um dos princípios de orientação a objetos que leva a concordância com a lei de Demeter, é o princípio da responsabilidade exclusiva do S.O.L.I.D. Porque digo isto? Simples, quando meu método começa a usar muitos recursos de outro objeto, em vez do próprio objeto ao qual pertence, provavelmente este método está no local errado, resumindo, não faz parte das responsabilidades do objeto que está. Outro princípio interessante de OO que ajuda a atingir a lei é o Tell don’t ask, mas este deixo para vocês lerem nas referências deste post.
Concordam com Lei, o que acham?
Referências: Law of Demeter, S.O.L.I.D, Tell don’t ask, Artigo do Giovanni Bassi sobre Tell don’t Ask
[]’s Fábio Margarito
Logging e Tracing
Freqüentemente, em reuniões de arquitetura, orientamos os desenvolvedores a criarem mecanismos de logging e tracing, com o simples objetivo de ajudá-los a identificar problemas em produção rapidamente. Estes mecanismos fazem parte do processo de instrumentação da aplicação.
Em grandes organizações, como bancos e seguradoras, o acesso a produção é restrito(graças a Deus, nosso dinheiro agradece), não conseguimos, por exemplo, em caso de problemas, abrir nosso componente e colocar uma entrada no eventlog com aquelas mensagens clássicas "Passei por aqui!!!", portanto, instrumentar o código é de fundamental importância, e com certeza vai te poupar muita dor de cabeça. Infelizmente é algo pouco praticado pelos desenvolvedores em geral.
Uma dúvida freqüente, é a diferença entre logging e tracing. A diferença está no teor e quantidade de informações coleadas e armazenadas.
Logging: É o registro contínuo, de qualquer tipo de informação que importante para o usuário final do componente e da aplicação. O logging gera um volume de dados bem inferior a um processo de tracing devido a natureza dos dados. Exemplos de logs:
-
Registro de um erro inesperado
-
Registro do nome do usuário e data quando um dado sensível do sistema foi alterado
-
Registro dos acessos realizados a um sistema, entre outros.
Tracing: Registro de informações extremamente detalhadas e geralmente de cunho técnico, sobre o processo de execução de um componente. É uma informação relevante somente ao desenvolvedor do componente e equipe de suporte.É interessante que o trace seja parametrizável(liga/desliga) e classificável(ERROR,INFO,etc...), possibilitando que ao ligar o log, você determina que tipo de trace é desejado. Exemplos:
-
Passo a passo de execução de uma rotina
-
Dados relativos ao tempo de execução de uma rotina
-
Erro detalhado(mensagem, pilha de execução, fonte, etc..)
Cuidados a serem tomados
Expurgo: Uma vez definido quais logs e traces sua aplicação terá, é necessário definir a política de tempo que a informação ficará em repositório(File System, Banco de dados, etc...). Geralmente logs oriundos de obrigações legais, ficam em torno de 5 anos armazenados, traces, devido a natureza prolixa com propósito de curto prazo, ficam um ou dois em base. Limpar logs é necessário, pois a taxa de crescimento é expressiva e consome muitos recursos.O expurgo pode ser feito de várias formas:
-
-
Tarefa agendada do Windows que executa alguma linhas de comando que faz a atividade de expurgo
-
A própria aplicação fazê-lo de tempos em tempos(não recomendável)
-
Produtos comerciais
-
Ferramenta criadas pela própria empresa
Baixa interferência: O logging/tracing não devem onerar a aplicação submetida a instrumentação. Se houver algum tipo de latência, que seja a menor possível. Menor é subjetivo e deve estar alinhado com tempo de resposta esperado pelo processo de negócio. A melhor forma de mitigar este problema é a inclusão assíncrona destes logs, ou seja, o componente não espera a inclusão de logging/tracing para que continue sua atividade.
Frameworks
Existem diversos frameworks, e utilitários já disponíveis para instrumentar a aplicação, dos quais posso citar:
TraceSource: Classe introduzida no .Net 2.0. O WCF o utiliza para o trace e diagnóstico de problemas
Log4Net: Um dos mais famosos frameworks para esta finalidade e portado do Java.
Logging Application block: Parte integrante do Enterprise Library.
Este é basicamente um post teórico e com objetivo de elucidar dúvidas sobre algo tão pouco posto em prática. Assim que possível, vou postar algo mais prático, mostrando algumas maneiras de instrumentar a aplicação, como por exemplo, por OAP.
Referências:
The Difference Between Logging and Tracing
Application Instrumentation
Criação de aplicação com boas práticas de arquitetura
Para quem quiser acompanhar, o Ayende Rahien(MVP) irá construir uma aplicação do zero, utilizando boas práticas de arquitetura de software. Diferente da maioria dos exemplos, desta vez não será locadora, biblioteca, ou até mesmo restaurante, será algo mais inusitado, o gerenciamento de uma prisão. Acho que vale a pena acompanhar.
Link da aplicação: http://ayende.com/Blog/archive/2009/07/27/macto-or-how-to-build-a-prison.aspx
Para quem não conhece o Ayende, ele é um dos contribuidores do NHibernate.
Provavelmente, vocês verão uma aplicação que não será distribuída(fisicamente), mas será distribuída em camadas lógicas, entretanto, as técnicas aplicadas ao domínio do problema são válidas e acredito que estará repleta de patterns utilizados na prática, e caso queiram expandir para uma aplicação distribuída fisicamente, bastaria criar uma camada de serviços nos servidores de aplicação(há outras questões que precisam ser discutidas) , utilizando, por exemplo, o WCF para comunicações com a camada de apresentação. Criar tudo em apenas uma máquina não é errado, é apenas um outro tipo de arquitetura.
Obviamente, diferente de uma aplicação distribuída, estas máquinas ao invés de especializadas para determinado cenário de utilização, serão mais potentes, e quando é necessário escalar a aplicação, é necessário colocar mais uma máquina no cluster, contendo um espelho da aplicação(técnica que o Windows Azure utiliza). Outro ponto legal da aplicação, pelos insights que vi, é que ela utilizará um Mapeador Objeto Relacional(ORM) que será o NHibernate(concorrente do Entity Framework da Microsoft, só que bem mais maduro, pelo menos até a versão corrente do EF).
No texto acima deixei diversos links com os conceitos e ferramentas.
Para quem não está acostumado com este cenário, é uma excelente oportunidade de aprendizado.
Vamos aguardar os próximos capítulos.
[]'s
Fabio Margarito
12º Reunião do Grupo .NetArchitects
No sábado(17/07), houve o 12º encontro do grupo .Net Architects. Desta vez o tema foi WCF(Windows Communication Foundation) o qual foi apresentado pelo Rafael Godinho especialista em desenvolvimento do grupo de evangelização de tecnologias da Microsoft. O Rafael abordou vários assuntos interessantes com propriedade, passando pelo básico e alternando entre conceitos e exemplos práticos, ou seja, agradou a quem não conhecia quase nada, e trouxe novos conhecimentos aos que já trabalham com esta tecnologia.
Alguns tópicos:
- O que é WCF?
- O que não é WCF?
- Definição do termo serviços
- Serviços REST com WCF
- Hospedagem de serviços WCF
- Cenários de utilização
Logo em seguida fomos para a discussão saindo de WCF, passando por ESB(Enterprise Service Bus), EAI(Enterprise Application Integration) e até por OSLO. Pena que não conseguimos gravar a discussão devido a problemas técnicos, e por isso recomendo a reunião presencial.Outro ponto positivo da discussão foi ter a oportunidade de trocar idéias com profissionais que dificilmente teríamos contato de outra forma, como o Waldemir Cambiucci, arquiteto de solução da Microsoft e MVPs como o Giovanni Bassi.
Alguns Links úteis:
E a próxima reunião será sobre OSLO com o Waldemir Cambiucci.
[]'s
Fábio Margarito
Não entendi o artigo, o autor escreve mal?
Escarafunchando a net em busca de bons materiais de leitura (acabou virando um vício), encontrei um artigo do Michael Feathers no site ObjectMentor, onde ele cita 10 artigos que qualquer desenvolvedor deveria ler. Acabei chegando neste artigo, a partir de outro que o Steve Rowe, líder do time de testes da Microsoft, escreveu com um título bem interessante “Five Books To Read If You Want My Job” , em português, “Cinco Livros para ler se você quiser meu emprego”.
O motivo pelo qual Michael elencou estes artigos, é um problema recorrente, e acredito que todo articulista já sofreu em algum momento. Qual o nível de abstração que o artigo deve seguir? Muitas vezes perdemos o foco do artigo tentando explicar cada conceito base envolvido, levando a um artigo longo demais e pouco detalhista para os iniciantes, e enfadonho para os mais experientes. O que fazer? No meu ponto de vista acho importante entender o público alvo, se for um público mais experiente, aconselho deixar diversas referências de apoio para que os mais novatos consigam entender. Se o artigo for para um público mais novato, o melhor mesmo é atacar um assunto em específico e detalhar ao máximo possível.
Para os que agora ingressam neste mundo tão volátil, não tem solução mágica, tem que estudar, estudar, trabalhar e trabalhar, somente um ou somente outro não adianta, eles são complementares. Não é fácil eu sei, há todo um caminho cheio de pedras a seguir, exige muita dedicação, amor pelo que se faz, e só o tempo trará as respostas, é um processo evolutivo.
Lembro de uma revista chamada Developers, nesta época eu estava iniciando na carreira como desenvolvedor e me recordo como era difícil entender o conteúdo e para piorar, na época a internet era incipiente e não havia muita coisa disponível. Ao invés de ficar desanimado, eu fui atrás dos conhecimentos necessários para eu poder assimilar os artigos. Depois de alguns anos, peguei novamente a revista e os assuntos ficaram muito mais claros, uma excelente recompensa. Até hoje estudo constantemente e vejo que quanto mais estudo, mais informações aparecem, isto não para nunca, por isso reforço, você precisa gostar muito do que faz.
Ainda bem, que muitos grupos como o .Net Architects foram criados. O principal objetivo destes grupos e dar o caminho das pedras e propiciar debates substanciais entre os membros mais experientes, e tudo com um único objetivo, agregar conhecimento.
[]’s
E-book ASP.NET MVC
Scott Guthrie disponibilizou no dia 10 de março, um e-book tutorial de ASP.NET MVC. O e-book é um tutorial de 185 páginas onde uma aplicação completa em ASP.NET MVC é criada.Trata-se do primeiro capítulo escrito pelo Scott do Livro “Professional ASP.NET MVC 1.0” que já está disponível na Amazon em pré-venda. O acordo que o Scott fez com a Wrox, editora do livro, permite que o livro possa ser distribuído livremente. Para maiores detalhes, acesse o post de lançamento do livro.
[]'s
O retorno de um otimista
Hoje vou colocar um post um pouco fora do contexto do blog, mas não resisti. Acabei de assistir o clássico Corinthians x Palmeiras, algo muito fora do meu costume. Além de ser corinthiano, gosto de futebol mas não tenho o hábito de assistir jogos. Assisti o clássico para ver o Ronaldo mostrar o seu futebol. Apesar dos deslises pessoais( o que não é da nossa conta),o acho um profissional guerreiro e com objetivo. O Ronaldo foi eleito três vezes o melhor jogador do mundo, o maior artilheiro de todas as copas, depois de Pelé, acredito que seja o jogador mais conhecido do mundo, venceu contusões que o deixaram fora do futebol por 3 anos dentro dos 16 de carreira, e por mérito, se tornou milhonário. Agora podemos nos perguntar, por que ele com todo o sucesso que um profissonal poderia atingir no seu campo de atuação, precisa voltar a lutar e mostrar seu potencial? Na minha opinião, garra, força de vontade e principalmente amor pelo que faz. Para mim ele é um exemplo que podemos trazer para o nosso laboro.Se muitos dos profissionais que trabalhassem com sistemas tivessem amor e esmero pela profissão em detrimento aos rendimentos financeiros que profissão trás, com certeza não teríamos sistemas “capengas”, com manutenção difícil e sem visão de futuro. Nossa área cada vez está mais inflada de profissionais que na maioria não possuem qualquer embasamento em fundamentos, e, para piorar, o mercado responde com altos salários, seja lá qual for o nível. Espero que todos estes profissionais se espelhem no Ronaldo e se dediquem pelo menos 10% do que ele se dedica e com certeza nossa área crescerá e dará muito orgulho a todos, porque sinceramente, me desaponta muito quando ouço no metrô ou no ônibus, alguém escolhendo nossa área porque paga-se bem.Aonde está a qualidade e aptidão profissional? E a dedicação a profissão que se gosta? Alguém só é feliz e cresce no que gosta de fazer.
[]’s
Preparando uma máquina para arquitetura e desenvolvimento
Hoje navegando pelo site do Waldemir Cambiucci,arquiteto da Microsoft, encontrei um post que vale a pena divulgar. Ele lista todos os softwares que utiliza no dia-a-dia e respectivos links de um máquina utilizada para desenvolvimento e arquitetura de aplicações Microsoft.
Links para um processo de instalação : Prism 2.0, Windows Azure Kit, Silverlight 2.0, SDS SDK e outros pacotes...
[]'s
Design Patterns - Padrões de Projeto
Depois de algum tempo sem post devido a problemas de saúde, estou na ativa novamente. Gostaria de falar um pouco sobre referências para aprendizado de Padrões de Projeto, os famosos Design Patterns. No design de software diversos problemas são comuns. Como é de conhecimento, o GOF(Gang of Four), criou diversos padrões para endereçar este problemas, fornecendo soluções elegantes,reutilizáveis e embasadas em fortes princípios de Orientação a Objetos. Os padrões estão divididos em grupos: criação, estruturais e comportamentais. Mesmo que você não conheça os patterns, com certeza já os utilizou diversas vezes. Vejamos o pattern observer, que no framework .Net é utilizado na construção de eventos. Como os patterns são muitos, decorá-los pode-se tornar uma tarefa árdua e muitas vezes inviável. Você naturalmente acabará absorvendo os patterns mais utilizados pela sua equipe. O interessante é conhecer a função de cada um e possuir boas referências para consulta. Aqui cabe algumas indicações:
Head First Design Patterns: O livro trás de uma forma bem didática o conceito de cada padrão através de pequenas estórias e ilustrações. A abordagem torna o aprendizado de padrões uma atividade divertida. Na minha opinião, deve ser o primeiro livro para introduzir o assunto. Existe uma versão em português para o livro, chamada “Use a Cabeça - Padrões de Projeto”
Design Patterns: Elements of Reusable Object-Oriented Software: Este é o livro dos criadores dos padrões, o GOF. É o Livro de referência obrigatório nas estantes de desenvolvedores e arquitetos. Por se tratar de uma leitura um pouco mais complicada, recomendo a leitura de um livro mais simples, como o Head First mencionado anteriormente.Também existe uma versão em português denomiada “Padrões de Projeto - Soluções Reutilizáveis de Software Orientada a Objetos”
DoFactory: Este site é bem interessante e prático. Os exemplos são simples e mostram bem a estrutura dos patterns. Destaco o site pelos exemplos em C#. Até mais.
Entendendo o Windows Azure
Sexta-feira(05/11), tive a oportunidade de participar como ouvinte da palestra sobre Cloud Computing com o Windows Azure. A palestra ocorreu na semana de tecnologia da Faculdade Impacta e foi ministrada pelo Dennes Torres com início as 20:30.
O que mais nos motivou a assistir a palestra em uma sexta-feira a noite , foi o fato de haver uma demo de criação de um serviço dentro do Windows Azure. O assunto Cloud Computing e Windows Azure estava muito nebuloso e precisávamos do famoso “estalo” para entender os conceitos. O Dennes Torres participou do PDC e nos trouxe uma visão clara sobre o tema e quais os próximos passos para dar início as primeiras brincadeiras e vislumbrar novas oportunidades. Nas linhas a seguir faço um resumo sobre o que foi mostrado e discutido no evento.
Vou começar por uma definição grosseira sobre o que é o Windows Azure:
“A Microsoft virou uma grande empresa de hosting”
Isso mesmo, um grande hosting, mas um hosting diferenciado, já explico. Inicialmente vou falar sucintamente sobre como funciona uma empresa de hosting. Quando precisamos colocar um site no ar, temos algumas tarefas, precisamos registrar nosso domínio, www.nome.com.br em algum órgão de registro. Em seguida, este domínio precisa apontar para uma máquina na grande nuvem, a internet, na qual os arquivos do seu site e banco de dados estarão presentes. Esta máquina pode estar dentro da sua empresa, ou, você pode contratar um serviço de hosting. Normalmente contratamos um espaço físico que muitas vezes compartilha os recursos da máquina com outros sites. Caso seja necessário mais espaço físico, memória, processador, etc..., pode-se contratar uma máquina dedicada, ou seja, alugar uma máquina exclusiva para a sua aplicação. Há também uma terceira modalidade, contratar um serviço de co-location, ou seja, comprar uma máquina que ficará alocada na empresa de hosting. Qualquer uma das formas, visa diminuir custos e preocupações, pois a responsabilidade de backups, redundância de links e disponibilidade do servidor, fica a cargo da empresa de hosting. Independente da forma de contratação, será necessário conhecimentos especializados para colocar a aplicação no ar, principalmente quando a máquina for dedicada. Tarefas como configurar o servidor web e banco de dados será toda sua. Se for necessário escalar a aplicação, você poderá seguir duas abordagens:
<!--[if !supportLists]-->
- Scale-up: Aumento de recursos de hardware da máquina, como aumento de memória, troca de processador, expansão do espaço em disco.
<!--[endif]-->
<!--[if !supportLists]-->
- Scale-out: Colocar diversas máquinas com características semelhantes contendo cópias da aplicação.
<!--[endif]-->
Alguns problemas nos serviços de hosting nos moldes atuais:
<!--[if !supportLists]-->
-
Scale-up: Toda máquina tem um limite, a estratégia de Scale-up funcionará até certo ponto e em algum momento, teremos que colocar mais uma máquina trabalhando em paralelo para dividir a carga (Scale-out).
-
Arquitetura: Scale-out é excelente, entretanto, devemos nos preocupar com outros detalhes. Para ficar mais fácil o entendimento, vamos nos basear em uma aplicação web. Como teremos diversos servidores com a cópia do nosso site será difícil saber em qual máquina o usuário estará utilizando. Podemos ter casos em que o usuário começa em um servidor e termina o uso em outro. Obviamente quando se troca um servidor por outro, não queremos que a autenticação, sessão ou cache sejam perdidos. Para isso temos que implantar estratégias de centralização de sessão, cache e autenticação.
<!--[if !supportLists]-->
-
Picos de utilização variáveis: Vamos imaginar uma grande loja de e-commerce, em datas comemorativas há picos de utilização e será necessário alugar/comprar mais máquinas para se adequar a utilização. Quando o pico de uso acabar, teremos máquinas subutilizadas o que representa custos desnecessários para a organização.
<!--[if !supportLists]--><!--[endif]-->
Todos os problemas acima, apesar das dificuldades e possíveis desvantagens podem ser endereçados, mas arquitetos, DBAs e especialistas em infra-estrutura serão necessários, e o mais importante, investimentos para sustentar toda esta estrutura.
Imagine abstrair toda esta dificuldade, o desenvolvedor cria uma aplicação web, monta um banco de dados e os publica no hosting. O site está indo bem até o momento, questões de performance e disponibilidade estão dentro dos níveis de serviço acordados. Chegou o natal, há uma previsão de aumento de 1 milhão de usuários, verifica-se que será necessário aumentar o parque de máquinas, e agora? Simples, abre o arquivo de configuração e através de uma tag aumente o número de máquinas para o valor desejado, o hosting automaticamente criará cópias da aplicação, banco de dados e se preocupará automaticamente com o gerenciamento de tudo isto (cache/sessão/Autenticação/Banco de dados), isto é o Windows Azure, um sistema de hosting que vai além de oferecer infra estrutura. Ele oferecerá aplicações de alto nível, sistemas de monitoração da saúde da sua aplicação on-line, praticamente uma revolução na forma de trabalho.
O Windows Azure poderá hospedar um site, componentes de negócio, um banco de dados e oferecer diversos serviços.
Após a apresentação diversas dúvidas surgiram:
<!--[if !supportLists]-->
-
Windows Azure será vendido? Somente a Microsoft oferecerá este serviço?: Não, o Windows Azure não será vendido e sim, somente a Microsoft oferecerá este serviço. Ela está investindo massivamente em datacenters ao redor do globo e detalhes da construção e softwares utilizados não são divulgados. Futuramente recursos que tornam possíveis a concepção do Windows Azure, estarão disponíveis nas próximas versões dos sistemas operacionais da Microsoft, assim empresas de hosting privadas poderão prover serviços semelhantes.
<!--[endif]-->
<!--[if !supportLists]-->
<!--[endif]-->
<!--[if !supportLists]-->
-
Posso portar minha aplicação existente para a plataforma Azure?: Sim, entretanto alguns ajustes serão necessários, como a lógica de acesso a dados, ou seja, acesso ao banco de dados na nuvem, o SQL Services.
<!--[endif]-->
<!--[if !supportLists]-->
-
Qual será a forma de licenciamento e preços?: Pelo site do Windows Azure, o preço será baseado no consumo. Você poderá alterar a utilização a qualquer momento, comprando ou retirando recursos quando necessário. Durante o período de CTP não há encargos na utilização, apenas certos limites estão serão impostos.
<!--[endif]-->
<!--[if !supportLists]-->
- Os datacenters já foram construídos?: Segundo o blog do Otávio, arquiteto da Microsoft, já existem 13 e até o final deste ano serão 20.
<!--[endif]-->
<!--[if !supportLists]-->
-
Se desenvolvedor criar uma aplicação ruim, provavelmente para aumentar o desempenho ele irá aumentar a quantidade de máquinas. O Azure não poderá inibir as boas práticas de programação e arquitetura?: Não, para aumentar a quantidade de máquinas, haverá aumento de custos. Alguém quer pagar pelos erros? Eu não.
<!--[endif]-->
Para trabalhar com o Windows Azure, você precisará baixar alguns SDKs que encontram-se disponíveis neste link.
Concluindo, o Windows Azure é uma grande quebra de paradigma e com certeza trará muitas oportunidades, críticas e desafios aos arquitetos de software. Para os próximos posts trarei mais exemplos e curiosidades sobre o Azure.
Até a próxima