BUT, one problem that comes not just with CakePHP but with several frameworks, is the usage of the Model. it’s not really a problem, but I think that is the way that people learned MVC with the framework, and the way that we see the Controller.

Frameworks, such as CakePHP, Rails and so on, impose that Model is database access (not really, but they come with this access).

Is that wrong? NOT really wrong…

As the fact that normally your application will need to save data into one database, or filesystem, etc… So provide one database access inside our model probably will help us.

What is the problem?

The problem comes when you see your model as JUST one database access layer, see the model as the thing that will store our data. So we start write the system logic inside the Controller, and this Controller starts to grow, because it already has several roles in our application, it handle the request, it handle the input, it call the model, it call the view… and it also get an additional role that is have the system logic. So our controller get FAT, hard to maintain, hard to change, hard to test, hard to change. It start to has the action methods, some other private/protected methods to implement logic, and it get ugly, strange, BIG.

What about our model?

The model keep thin, with no methods, no logic, just with the relationships of our database, with the validation… does it seems strange for you?

So what hell we are not using our model?

YES, we should use our model to make the logic of the system, is that the M of our application, is what Model must be, and is what the Model is expecting.

How we can start use our model as the logic part of our applications?

1. STOPING to see the Model as your database access;
2. Writing methods inside our models;
3. Creating models without usage of database;
4. Making the models talks each other;
5. Importing libraries, objects inside or model;
6. Creating one API inside or models, to make easy the calls for the controllers;
7. Make your controllers as  much thin as possible.

What will be your gains?

1. You will probably have more freedom to make your logic;
2. Your code will be more simple to maintain;
3. It’s simple to write test for Models;
4. You will have a better OO structure of your logic;
5. You will start think different about Behaviors, Components in CakePHP;
6. Your controller will be thin, and make just what he should do, nothing else;
7. You will stop rewrite code, the model can be called in any controller that you want;
8. With a good structure of logic, it will be so much easy to upgrade your code to new versions of  the framework, or why not, migrate to another framework, as the fact that your logic system will not depends more of the features that CakePHP has.

To summarize, CakePHP is great, it has great tools to make our development fast, but what we can not do is misunderstand the MVC, and starts to be addict with bad practices.  Frameworks like Zend make it more simple to understand, because it not provides directly in the model one database access, BUT anyway in CakePHP we can make the thing correct too, and get everything good of the framework.

So the idea behind the post is not forget the Controller, but pay much more attention in your Model.

Uma definição para o Factory seria, definir uma interface única para criação de objetos, deixando a cargo da classe Factory decidir qual instância de subclasse deve ser feita.

Trocando em miudos, é como uma central telefonica, você liga para apenas 1 número que você conhece, pergunta para a telefonista o que deseja, e ele te retorna o número correspondido ao seu pedido.

É bastante comum encontrarmos esse padrão em frameworks, ferramentas e bibliotecas.

Bom vamos ao um exemplo prático pois por enquanto está tudo lindo, sabemos que podemos encapsular subclasses em uma classe, fornecendo assim uma instância única, logo se num futuro é necessário fazer alterações, precisamos mudar em apenas um local.

Jõao um famoso empresário da cidade, decide criar uma lancheria, então logo vai para o seu sobrinho dono de uma empresa de programação na cidade e passa os requisitos, nada mais que 1 cardápio com os preços dos lanches tendo 3 tipos de lanches, X-Gordura, X-Maionese, X-Ovo, cada 1 com 1 preço diferente.

José que também é sobrinho do Jõao, diz logo para os programdores tarefa simples, criamos 1 classe que armazena o lanche e receba como parâmetro o preço…

Todos concluem ser uma ótima solução até que depois da entrega, Jõao resolve alterar o preço de 1 dos lanches, para concorrer com outra lancheria que abriu nas proximidades. Pede ao seu sobrinho para alterar o preço do lanche.

E o sobrinho disse que demoraria 6 meses, para fazer isso… José envocado, mas como se para fazer o programa todo demorou 2 meses…

Seu sobrinho responde é que vou ter que alterar os 200 códigos onde está o preço desse lanche!

Conclusão! menos é mais, e é isso que ocorre, vamos fazer essa simples implementação da lancheria com o Padrão Factory.

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
42
43

< ?php
abstract class Lanche {
    abstract public function pegar_preco();
}
 
class XgorduraLanche extends Lanche {
    public function pegar_preco() {
        return 2.90;
    }
}
 
class XmaioneseLanche extends Lanche {
    public function pegar_preco() {
        return 3.90;
    }
}
 
class XovoLanche extends Lanche {
    public function pegar_preco() {
        return 6.90;
    }
}
 
class LancheFactory {
    public static function lanche($type) {
        switch ($type) {
            case 'Xgordura':
                return new XgorduraLanche();
            case 'Xmaionese':
                return new XmaioneseLanche();
            default:
                return new XovoLanche();
        }
    }
}
 
$lanche = LancheFactory::lanche( 'Xgordura' );
echo $lanche->pegar_preco() . '<br />';
$lanche = LancheFactory::lanche( 'Xmaionese' );
echo $lanche->pegar_preco() . '<br />';
$lanche = LancheFactory::lanche( 'Xovo' ) ;
echo $lanche->pegar_preco() . '<br />';
?>

Como podemos ver foi muito simples a implementação, criamos uma classe abstrata onde dizemos quais são os métodos que temos que implementar nos tipos de lanches, criamos os diversos tipos de lanches extendendo ele da classe abstrata, logo após fizemos a classe factory, com 1 método statico que passamos como parâmetro o tipo do lanche que queremos, dentro do método temos 1 controle com um block swich, e por fim retorna o preço de cada tipo de lanche.

O que pode ser feito é não usar o controle com switch e chamar dinâmicamente a classe, além de adicionar um tratamento de erro para evitar quando informado o tipo errado:

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

< ?php
abstract class Lanche {
    abstract public function pegar_preco();
}
 
class XgorduraLanche extends Lanche {
    public function pegar_preco() {
        return 2.90;
    }
}
 
class XmaioneseLanche extends Lanche {
    public function pegar_preco() {
        return 3.90;
    }
}
 
class XovoLanche extends Lanche {
    public function pegar_preco() {
        return 6.90;
    }
}
 
class LancheFactory {
    public static function lanche($type) {
	$type .= 'Lanche';
	if (class_exists($type)) {
		return new $type();
	} else {
		throw new Exception('Nao tem essa classe!!');	
	}
    }
}
 
try {
	$lanche = LancheFactory::lanche( 'Xpicanha' );
	echo $lanche->pegar_preco() . '<br />';
} catch (Exception $e) {
	echo 'Informamos que não temos esse pedido no nosso cardápio! <br />';
}
try {
	$lanche = LancheFactory::lanche( 'Xgordura' );
	echo $lanche->pegar_preco() . '<br />';
} catch (Exception $e) {
	echo 'Informamos que não temos esse pedido no nosso cardápio! <br />';
}
try {
	$lanche = LancheFactory::lanche( 'Xovo' );
	echo $lanche->pegar_preco() . '<br />';
} catch (Exception $e) {
	echo 'Informamos que não temos esse pedido no nosso cardápio! <br />';
}
try {
	$lanche = LancheFactory::lanche( 'Xmaionese' );
	echo $lanche->pegar_preco() . '<br />';
} catch (Exception $e) {
	echo 'Informamos que não temos esse pedido no nosso cardápio! <br />';
}
?>

Esse foi um exemplo simples, mas em prática podemos se deparar em boa hora de usar o Factory, como tratamento de diversos tipos, como por exemplo imagens, arquivos de música, até mesmo banco de dados entre outros.

Qualquer dúvida comentem!

Mas afinal o que são padrões de projeto?

Padrões de Projetos ou Design Patterns, são características arquiteturais de software, que ao longo do tempo se tornaram soluções de problemas. Ou seja, você tem um problema, muitas vezes outras pessoas já passaram por ele, logo, alguém já resolveu ele. Com isso, com problemas freqüentes de arquitetura na programação que os padrões de projetos surgiram.

Eles são, soluções muito boas, que várias pessoas ajudaram a pensar na melhor solução, para problemas existentes.

Bom mas chega desse papo, deixa um pouco mais da história, para um próximo post…

Vamos por a mão na massa, opa, massa não, pois dessa vez não é CakePHP. Bom chega de piadinhas sem graça, vamos ao primeiro padrão de projeto a ser apresentado.

É ele o Singleton.

Ao que se refere o Singleton, o seu nome é bem sugestivo, Singleton é aquele padrão que garante apenas 1 instância de 1 classe, ou seja ele garante que após instanciar uma vez a classe, você sempre irá estar usando o mesmo objeto.

Hmmm, legal mas quando usar???

Em todos os lugares, onde se precisa garantir uma instancia de uma classe, ou seja, por exemplo 1 log de dados, onde apenas um objeto da aplicação é responsável pelo controle dos log’s. Outro exemplo, é uma conexão de banco de dados, que no caso seja necessário garantir sempre a mesma conexão. Entre outros exemplos.

Bom vamos ao exemplo da implementação, em PHP:

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
42
43
44

<?php
class Singleton {
 
	public static $instance; //atributo responsável por retornar a instancia da classe.
	public static $cont; //atributo que serve apenas para contar quantas vezes a classe foi chamada.
 
	/**
	* Método construtor responsável por criar a página, é declarado como privado para garantiar,
	* que apenas a classe Singleton chame ele!
	*/
	private function __construct() {
		echo "<h1>Sou sempre o mesmo, com a mesma instancia!</h1>
"; //Texto para mostrar quando ocorre a instancia e comprovar que só ocorre uma vez!
	}
 
	/*
	* Método singleton, responsável por ser o construtor da classe, por ser abstrato e público,
	* é possível chamar ele sem termos o objeto da classe Singleton;
	*/
	public static function singleton() {
		//Verifica se o atributo $instance já foi setado, caso não faz a instancia dele
		if (!isset(self::$instance)) {
			//Criamos o objeto e alocamos ele para o atributo self::$instance
			self::$instance = new Singleton();
		}
 
		//Código para mostrar quantas instancias requiridas da classe tivemos, e que é sempre o mesmo objeto
		self::$cont++;
		echo "e fui chamado ", self::$cont ," vezes.";
 
		//Retorna a instancia da classe!
		return self::$instance;
	} 
 
}
 
//5 chamadas do objeto singleton
Singleton::singleton();
Singleton::singleton();
Singleton::singleton();
Singleton::singleton();
Singleton::singleton();
 
?>

Acho que os comentários estão explicando bem o funcionamento, mas vamos tentar explicar um pouco mais, se temos que garantir apenas 1 objeto, não podemos ter o método construtuor liberado para novas instancias, logo criamos um novo método singleton, este passa a ser o responsável por criar um novo objeto, caso seja a preimeira instancia ou retornar o objeto que já foi instanciado.

Bom por hoje é isso, vou continuar a explicar em PHP alguns Designer Patterns.