Espero estar podendo voltar a postar regularmente, agora sem a complicação editor de conteúdo do Blogger...
Este é o primeiro post que faço usando o Windows Live Writer e ele me parece muito bom. Leve, simples e eficaz. Resolve as dores de cabeça das transições "quebradas" entre HTML e texto que o editor do Blogger apresenta e dá mais opções - como inserir tags e mapas - além de estar integrado a serviços de sites populares.
Enfim, de volta a ativa...
class Base
{
public:
virtual ~Base()
{
cout<< "\nDestrutor da classe base." << endl;
};
virtual void Metodo()
{
cout << "\nMétodo da classe base." << endl;
};
};
class Derivada : public Base
{
public:
virtual ~Derivada()
{
cout<< "\nDestrutor da classe derivada." << endl;
};
virtual void Metodo()
{
cout << "\nMétodo da classe derivada." << endl;
};
};
// ...
int main()
{
Base *obj = new Derivada;
obj->Metodo();
delete obj;
}
class BasePura
{
public:
virtual ~BasePura() = 0; // destrutor virtual abstrato
virtual void Metodo() = 0;
};
BasePura::~BasePura()
{
// implementacao normalmente vazia
}
Para conseguir isso, cada camada é projetada de forma que nenhuma saiba muito sobre o funcionamento interno da outra. A maioria só conhece o protocolo pelo qual vai se comunicar com a camada associada.
Não conhecendo detalhes sobre a implementação das camadas associadas, uma camada comunica-se sem necessitar entender o funcionamento das demais. Por isso o nível de abstração do modelo aumenta e você pode facilmente variar a implementação de cada parte (aplicando reutilização do modelo através da combinação de herança e polimorfismo).
MVC
O Model-View-Controller é um padrão criado inicialmente para ser utilizado no sistema de interface gráfica do SmalltalkTM (Goldberg e Robson, 1983), possuindo as seguintes metas:
Antes do MVC, os projetos de interface com o usuário tendiam a agrupar o comportamento da interface e a lógica do problema no mesmo contexto, digamos numa mesma classe. O MVC separa cada parte numa classe diferente, a fim de aumentar a flexibilidade e a reutilização.
O MVC propõe a separação do modelo de interação com a interface com o usuário em três partes: uma Visão (View), um Modelo (Model) e uma Controladora (Controller). A Visão representa a interface com o usuário, a representação interativa do software. O Modelo representa o domínio da aplicação, a lógica sob a qual a Visão opera, transforma e obtém informações. A Controladora é um mediador entre o Modelo e a Visão, que tem como objetivo controlar a interação entre ambos, esconder os detalhes e diminuir a dependência entre as mesmas.
O funcionamento do modelo se dá da seguinte maneira:
1. O usuário executa alguma ação de entrada na interface, ou melhor, na Visão.
2. A Visão notifica a Controladora para mudar o Modelo de acordo com a ação executada.
3. A Controladora notifica o Modelo sobre a ação.
4. O Modelo recebe a notificação da Controladora, possivelmente alterando seu estado, e notifica indiretamente a todos que necessitam saber que seu estado se alterou.
Assim sendo, os objetos que são notificados de atualizações no Modelo implementam um método comum (Atualizar), e por terem o mesmo comportamento, implementam (herdar de) uma mesma interface.
Quais podem ser os objetos notificados ? Eles podem ser as Controladoras ou mesmo as Visões. (Em breve, possivelmente em outro post, estarei discutindo problemas e melhorias relacionadas, além de outros modelos).
Nota sobre uso de Padrões:
O comportamento acima descrito sobre a notificação de objetos foi catalogado como um Padrão de Projeto (Design Pattern) sobre o nome Observador (Observer). A idéia é que as classes que são notificadas sobre as atualizações são as “observadoras” e as que enviam a notificação são as “observadas”.
Caso você também tenha notado, o papel da classe Controladora do modelo MVC pode ser descrita também como um Padrão, catalogado sob o nome de Mediador (Mediator). No padrão Mediador, um objeto encapsula como um conjunto de objetos interage. Ele promove o acoplamento fraco para evitar que os objetos se refiram explicitamente uns aos outros, permitindo que eles variem independentemente.
Sendo assim, vamos analisar um exemplo simples, para retratar o modelo MVC:
Um usuário deseja conceder desconto em uma venda que ele está realizando. Quando o novo desconto é informado, o total da venda é recalculado e atualizado na tela, refletindo a mudança.
Para isso, teremos uma janela de venda (GUI_Venda) e um classe de venda (Venda).
Venda é uma classe (filha de) Observada e GUI_Venda é (filha de) uma classe Observadora.
Ao se conceder um desconto à venda, ela recalcula seu total. É desejado entretanto que ao recalcular seu total, a interface com o usuário exiba o novo total recalculado.
Tomando-se as devidas abstrações, o modelo seria parecido com este:
Essa é a idéia por trás do padrão Observador, e é a base do MVC.
A atualização via notificação indireta é uma poderosa ferramenta para nos auxiliar no desenvolvimento de diferentes interfaces para o mesmo modelo. Isso porque a informação permanece sempre sincronizada com o modelo. Ao alterarmos o modelo, essa alteração se reflete em todas as interfaces.
Em um próximo post estarei discutindo mais sobre o modelo MVC, alguns padrões relacionados e alguns outros modelos, como o Model-View-Presenter (MVP).
Até breve.
