Junior Oliveira

Jr Oliveira

Strategy Pattern

30 de outubro de 2012   |       |     csharp di ioc design pattern   |     pt

Olá pessoal, vou falar um pouco sobre Strategy Pattern, é um Design Pattern que ficou famoso depois de ser catalogado pelo GoF (Gang Of Four) formado por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides no livro “Design Patterns: Elements of Reusable Object-Oriented Software”.

Segue abaixo a definição de acordo com o livro:

“Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.”

Vamos ao exemplo para ficar mais claro a definição.

Imagina que você precisa desenvolver uma funcionalidade que irá validar um usuário. Este é um cenário bem simples e típico podemos fazer esta implementação de várias formas diferentes, abaixo segue um código que em um primeiro momento acho que seria o mais comum.

A primeira classe é uma controller do asp.net mvc que terá uma action que irá receber o usuário e a senha por POST e chamar a classe que irá validar estas informações.

LoginController.cs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class LoginController : Controller {

    public ActionResult Index() {
        return View();
    }

    [HttpPost]
    public ActionResult Index(LoginViewModel viewModel) {
        if (!ModelState.IsValid) return View(viewModel);

        var username = viewModel.Username;
        var password = viewModel.Password;

        var application = new UserApplication();
        var valid = application.Validate(username, password);

        //Caso o usuario nao seja valido, retorna para a view.
        if (!valid) return View(viewModel);

        //Autentica o usuario no sistema.
    }
}

A classe abaixo será responsável por controlar o fluxo de validação do usuário.

UserApplication.cs
1
2
3
4
5
6
7
8
9
10
public class UserApplication {

    public bool Validate(string username, string password) {
        var userDAO = new UserDAO();
        var user = userDAO.GetBy(username);
        if (user == null) return false;

        return user.Check(password);
    }
}

Nossa classe que será responsável por manipular os dados do usuário.

UserDAO.cs
1
2
3
4
5
6
public class UserDAO {

    public User GetBy(string username) {
        throw new System.NotImplementedException();
    }
}

Como mencionado acima, este é um código bem simples, porém, este código é impossível testar unitariamente e caso haja a necessidade de alterar a fonte dos dados também será difícil.

Para resolver este problema, podemos aplicar o Strategy Pattern, de forma que iremos passar para a classe UserApplication a “estratégia” (classe) de acesso a dados que iremos utilizar, assim fica fácil testar a classe UserApplication unitariamente e de mudar a fonte de dados quando necessário.

UserApplication.cs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class UserApplication {

    private readonly IUserDAO _userDAO;

    public UserApplication(IUserDAO userDAO) {
        _userDAO = userDAO;
    }

    public bool Validate(string username, string password) {
        var user = _userDAO.GetBy(username);
        if (user == null) return false;

        return user.Check(password);
    }
}

Notem que agora eu passo a dependência do repositório no construtor da minha classe UserApplication, sendo assim eu consigo passar qualquer classe que implemente a classe IUserDAO.

Abaixo notem que a nossa classe UserDAO sofreu uma modificação, agora ela implementa a interface IUserDAO sendo assim eu posso passar ela no construtor da nossa classe UserApplication.

UserDAO.cs
1
2
3
4
5
6
7
8
9
10
11
public interface IUserDAO {

    User GetBy(string username);
}

public class UserDAO : IUserDAO {

    public User GetBy(string username) {
        throw new System.NotImplementedException();
    }
}

Vocês podem perceber que agora estou passando para a classe UserApplication a conexão que ela deverá utilizar. Esta classe de conexão é uma “estratégia” que estou utilizando para acessar as informações do usuário, caso haja necessidade de acessar as informações de outra fonte de dados é necessário apenas implementar outra “estratégia” (classe) que implemente a interface IUserDAO e passar para a nossa classe UserApplication como mencionado acima.

LoginController.cs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class LoginController : Controller {

    public ActionResult Index() {
        return View();
    }

    [HttpPost]
    public ActionResult Index(LoginViewModel viewModel) {
        if (!ModelState.IsValid) return View(viewModel);

        var username = viewModel.Username;
        var password = viewModel.Password;

        IUserDAO dao = new UserDAO();
        var application = new UserApplication(dao);
        var valid = application.Validate(username, password);

        //Caso o usuario nao seja valido, retorna para a view.
        if (!valid) return View(viewModel);

        //Autentica o usuario no sistema.
        throw new NotImplementedException();
    }
}

Abaixo outra “estratégia” (classe) de acesso a dados que irá conter os métodos que simulará as operações na base de dados, nos ajudando assim a testar a classe UserApplication.

FakeUserDAO.cs
1
2
3
4
5
6
7
8
public class FakeUserDAO : IUserDAO {

    public User User { get; set; }

    public User GetBy(string username) {
        return User;
    }
}

O teste abaixo é para garantir que as operações da classe UserApplication estão de acordo com as regras do negócio.

UserApplicationTest.cs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
[TestFixture]
public class UserApplicationTest {

    private const string Username = "username";
    private const string Password = "password";

    private FakeUserDAO _fakeUserDAO;

    [SetUp]
    public void SetUp() {
        _fakeUserDAO = new FakeUserDAO();
    }

    [Test]
    public void Validate_QuandoUsuarioNaoExiste_RetornaFalse() {
        var userApplication = new UserApplication(_fakeUserDAO);
        var userIsValid = userApplication.Validate(Username, Password);

        userIsValid.Should().Be.False();
    }

    [Test]
    public void Validate_QuandoASenhaEhInvalida_RetornaFalse() {
        _fakeUserDAO.User = new User { Password = "pass" };

        var userApplication = new UserApplication(_fakeUserDAO);
        var userIsValid = userApplication.Validate(Username, Password);

        userIsValid.Should().Be.False();
    }

    [Test]
    public void Validate_QuandoASenhaEhValida_RetornaTrue() {
        _fakeUserDAO.User = new User { Password = Password };

        var userApplication = new UserApplication(_fakeUserDAO);
        var userIsValid = userApplication.Validate(Username, Password);

        userIsValid.Should().Be.True();
    }
}

Analisando a definição do pattern, descrita no inicio do post:

O contexto é a classe UserApplication.

As estratégias criadas foram as classes que implementam a interface IUserDAO no caso a classe UserDAO e FakeUserDAO.

E os clientes que utilizam a classe UserApplication são os testes da classe UserApplication e a action da LoginController.

Neste post usei os seguintes pacotes: Sharp Tests Ex e NUnit.

Existem outras aplicações mais comuns para o Strategy Pattern como: criptografias, logs entre outros cenários, escolhi este cenário também para demonstrar a aplicação de testes unitários em códigos “legados”.

Espero que tenham gostado do exemplo e até a próxima.