Lorival Smolski Chapuis

Archive for the ‘Padrões de projeto’ Category

Design Pattern: Facade

Definição segundo GoF: Oferecer uma interface única para um conjunto de interfaces de um subsistema. Façade define uma interface de nível mais elevado que torna o subsistema mais fácil de usar.

Exemplo baseado no mundo real: A sala de estar…. ah! sala de estar, quanta beleza existe em uma boa e tecnológica sala de estar… quantos de nós já teve a maravilhosa idéia de montar seu home theater em sua sala de estar, tornando-a um fantástico embolado de fios e aparelhos eletro-eletrônicos? Pois bem, nosso objetivo aqui é criar uma sala simples e bacana tecnológicamente. Vamos precisar de:

• Uma TV 32 polegadas LCD (poderia ser LED eu sei, mas vamos pelo  mais barato);
• Um DVD Player conectado a nossa TV;
• Um Aparalho de som 7.1 para usar como rádio/CD/MP3  para conectar com nosso DVD Player;
• Um PlayStation3 conectado a TV;
• Uma luz ambiente regulável.

Poderia ser mais coisas, mas vamos começar pelo simples. Agora você sentou no sofá e pegou na mão os controles:

• da TV;
• do DVD Playser;
• do aparalhode som;
• da luz ambiente.

Já imaginou o trabalho que vai ter para usar tudo isso integrado? E se tivessemos apenas um controle que reuni-se as principais funcionalidades destes 4 e ainda conecta-se nosso Play 3 junto? Não seria uma maravilha? Pois bem, este é o objetivo do Façade ou fachada: servir como uma interface única para um conjunto de interfaces.

Aplicações:

• Sempre que for desejável criar uma interface para um conjunto de objetos com o objetivo de facilitar o uso da aplicação;
• Reduzir a complexidade do relacionamento entre uma classe relativa ao cliente e as demais classes utilitárias [Junior, 2004];
• Redução de dependência entre o cliente e as classes existentes nos subsistemas, ocasionando a redução da coesão do sistema.

Vantagens:

• Permite que objetos individuais cuidem de uma única tarefa, deixando que a fachada se encarregue de divulgar as suas operações;
• Reduz dependências de compilação, possivelmente complexas ou circulares;
• Não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem [Junior, 2004];

Desvantagens:

• Necessário saber a classe concreta do criador de instâncias;

Observações:

• Fachadas são normalmente implementadas com singleton;
• Uma fachada apenas com métodos estáticos são chamadas de Utility.

Diagrama de classe:

Diagrama simplificado

Implementação em C#:

public class Client
{
    public void Cooking() //-- Quando o cliente for cozinhar algo para comer...
    {
        //-- Código especialista
        HomeTheaterFacade homeTheater = new HomeTheaterFacade();
        homeTheater.WatchMovie();
        //-- Código especialista
    }

    //-- Outros métodos úteis aqui
}

A codificação inteira deste post, juntamente com exemplos será feita em outro post.

Abrs a todos e até a próxima.

“Quando vemos um gigante, temos primeiro de examinar a posição do sol e observar para termos certeza de que não é a sombra de um pigmeu.” Friedrich Novalis

Em maio de 2005, Robert Martin, mais conhecido como Uncle Bob, publicou um artigo sobre 11 princípios de Design para Orientação de Objetos. No artigo ele diz que não basta programar orientado a objetos, é necessário ter princípios de design para manter a qualidade. Os 5 primeiros princípios ficaram “mais famosos”, sendo estes os que formam o S.O.L.I.D.

Na verdade S.O.L.I.D. é uma sigla de siglas. Vejam abaixo as siglas que o compõe e um resumo de seu princípio:

• SRP: The Single Responsibility Principle
  • Nome: Responsabilidade única;
  • Princípio: “Uma classe deverá ter um, e apenas um motivo para mudar”;
  • Detalhes: Uma classe deve ter apenas uma única responsabilidade, ou seja, aquela classe que tem  vários métodos com inumeras funcionalidades não atende este princípio;
  • Resultado: Existirão muito mais classes, no sistema, com poucas linhas de código

• OCP: The Open-Close Principle
  • Nome: Aberto-fechado;
  • Princípio: “Você deve ser capaz de estender o comportamento de uma classe, mas sem modificá-la”;
  • Detalhes: Quando precisar adicionar uma nova funcionalidade a uma classe, já em produção, não se altera a classe e sim estende-a adicionando a nova funcionalidade, não alterando, assim, a original. Só é permitido alterar uma classe em produção se for para corrigir bugs.
  • Resultado: Funcionalidades construídas e em produção, não sofrem riscos de pararem de funcionar quando uma nova for adicionada;

• LSP: The Liskov Substitution Principle
  • Nome: Substituição de Liskov;
  • Princípio: “Classes derivadas devem ser substituíveis por suas classes Base”;
  • Detalhes: Este é o mais debatido, devido a dificuldade de compreendê-lo. Uma casse derivada deve poder substituir plenamente a sua classe base sem alterar as funcionalidades;
  • Resultado: Um design onde não é permitida uma sub-classe com precondições mais fortes que a sua super-classe;

• ISP: The Interface Segregation Principle
  • Nome: Segregação de interface;
  • Princípio: “Faça interfaces de fina granularidade, que sejam específicas para quem vai utilizá-las”;
  • Detalhes: Uma interface não deve ter inúmeras funcionalidades. Deve ser o mais enxuta possível, seguindo o princípio SRP mas voltado a interfaces;
  • Resultado: Mais interfaces dentro do sistema, porém mais estruturadas e com maior possibilidade de reutilização;

• DIP: The Dependency Inversion Principle
  • Nome: Inversão de dependência;
  • Princípio: “Dependa de abstrações e não de classes concretas”;
  • Detalhes: Se depender apenas das interfaces, podemos substituir as classes concretas por outras totalmente diferentes, respeitando as interfaces é claro, sem alterar a estrutura do software. Isto pode ser feito até em tempo de execução;
  • Resultado: Um software com baixo acoplamento.

Leiam o artigo do Tio Bob para se aprofundar mais. Aproveitem para ouvir o podcast do .net arquitects sobre o assunto.

Abrs e fiquem com Steve Jobs….

“A maioria das pessoas cometem o erro de pensar que design é a aparência. As pessoas pensam que é esse verniz – que aos designers é entregue esta caixa e dito: “Deixe bonito!” Isso não é o que achamos que seja design. Não é só o que aparece e sente. Design é como funciona.”
Steve Jobs – CEO da Apple