MVC e Padrão Strategy

Você poderia simplificar um pouco. Não existe necessidade de ter uma classe AbstractAlgorithm e depois estendê-la para todo strategy. Ficaria assim:

<?php
	interface IAlgorithm
	{
 public function hash( $string );
	}

	class Bcrypt implements IAlgorithm
	{
 protected static $cost = 8;
 protected static $salt = 'teste';

 public function __construct( $cost = null )
 {
 self::$cost = $cost;
 }

 public function hash( $string )
 {
 echo crypt($string, '$2a$' . self::$cost . '$' . self::$salt . '$');
 }
	}

	class Md5Hash implements IAlgorithm
	{
 public function hash( $string )
 {
 echo md5( $string );
 }
	}

	class Algorithm
	{
 private $algorithm;

 public function __construct( IAlgorithm $algorithm )
 {
 $this->algorithm = $algorithm;
 }

 public function hash()
 {
 $this->algorithm->hash();
 }
	}

O segundo ponto é aqui:

protected static $cost = 8;
protected static $salt = 'teste';

Por que você os tornou estáticos? E como eu modificaria esse salt sem editar a classe? Você tem dois problemas: estado global desnecessário e uma violação do OCP, já que é impossível mudar o salt sem editar a classe.

A solução é bem simples:

class Bcrypt implements IAlgorithm
{

 protected $cost;
 protected $salt;

 public function __construct( $cost, $salt )
 {
 $this->cost = $cost;
 $this->salt = $salt;
 }

 public function hash( $string )
 {
 echo crypt($string, '$2a$' . $this->cost . '$' . $this->salt . '$');
 }
	}

1) O exemplo aplicado acima, mesmo que apenas "ilustrativo" está correto para aplicação do padrão Strategy?

O padrão em si sim.

2) Mesmo usando uma interface, eu poderia criar novos métodos "auxiliares" dentro das classes que implementam os algoritimos? Por exemplo, criar um método "check()" dentro da class "Bcrypt"?

Claro que poderia. Porém, se for algo interno torne protected/private.

A única coisa que você tem que prestar atenção é quanto ao LSP, veja o caso abaixo:

function doSomething(IAlgorithm $algorithm) {
 $algorithm->check();
}

Como o método check não faz parte da interface, não se deve usar a interface como o tipo requerido, então tome cuidado com isso.

3) No meu modelo de MVC que estou estudando e fazendo alguns testes, eu inclui as classes dentro do controller, e as instanciei dentro do meu Model, ao gravar um usuário no banco, por exemplo. É errado fazer desta forma?

Hã? Se eu consegui compreender, você está instanciando o controller dentro da model?

Olá Enrico,

Muito obrigado por me responder. Vou responder em partes:

Por que você os tornou estáticos?

Os tornei estáticos por que seriam usados apenas dentro da classe. Isso é uma má prática?

Hã? Se eu consegui compreender, você está instanciando o controller dentro da model?

Então, em meu pseudo-mvc tenho mais ou menos isso :

Index.php

<?php
require "controller/UserController.php";

$controller = new UserController();
$controller->save();

UserController.php

<?php
require "model/entity/User.php";
require "model/UserModel.php";

class UserController
{

 public function __construct()
 {
 private $model;
 private $user;

 $this->model = new UserModel();
 $this->user = new User();
 }

 public function save()
 {
 $post = filter_input_array( INPUT_POST , array(
 'name' => FILTER_SANITIZE_STRING,
 'senha' => FILTER_SANITIZE_STRING
 ) );

 $this->user->setName( $post['name'] );
 $this->user->setPass( $post['senha'] );

 return $this->model->create( $this->user );
 }
}

User.php

<?php
 class User
 {

 protected $id;
 protected $name;
 protected $pass;

 public function getId()
 {
 return $this->id;
 }

 public function getName()
 {
 return $this->name;
 }

 public function getPass()
 {
 return $this->pass;
 }

 public function setId( $id )
 {
 $this->id = $id;
 }

 public function setName( $name )
 {
 $this->name = $name;
 }

 public function setPassword( $pass )
 {
 $this->pass = $pass;
 }

UserModel.php

<?php
class UserModel
{

 private $db;

 public function __construct()
 {
 $this->db = Registry::getInstance()->get( 'pdo' );
 }

 public function create( User $user )
 {
 require_once "util/Bcrypt.php";

 $stmt = $this->db->prepare('
 INSERT INTO `users`
 (name, pass, created_at)
 VALUES
 (:name, :pass, NOW());
 ');

 $bcrypt = new BCrypt( "8", "SALT AQUI" );
 $stmt->bindParam( ':name', $user->getName(), PDO::PARAM_STR );
 $stmt->bindParam( ':pass', $bcrypt->hash( $user->getPass() ), PDO::PARAM_STR );

 if ( $stmt->execute() ) {
 $user->setId( (int)$this->db->lastInsertId() );

 $stmt->closeCursor();

 return $user->getId();
 }

 return false;
 }
}

Perceba que eu fiz o include da classe BCrypt dentro do método create() que está no meu Model... É correto fazer desta forma ou eu deveria fazer esse include em outra camada do MVC?

Valeu,

abss

Os tornei estáticos por que seriam usados apenas dentro da classe. Isso é uma má prática?

Neste caso o correto seria declara-los como private. Como static eles vão estar acessíveis a qualquer um que der um include na classe. Na verdade a grande sacada do static é você poder acessar métodos ou atributos de uma classe sem precisar instanciar a mesma. O ponto negativo é que isso equivale a usar globais que envenenam o código quando não bem usadas.

Perca que eu fiz o include da classe BCrypt dentro do método create() que está no meu Model... É correto fazer desta forma ou eu deveria fazer esse include em outra camada do MVC?

Evite instanciar um objeto dentro de outro. Isso gera acoplamento entre classes o que, assim como globais, é outra coisa a ser evitada. Procure usar dependency injection, neste conceito em vez de instaciar o objeto dentro da classe você vai passa-lo pelo construtor ou metodo.

Embora nos controllers você poça instanciar objetos no método, no model - como no caso do include do BCrypt na classe UserModel -o melhor seria o dependency injection, assim como você esta recebendo um objeto User no método receba também um objeto BCrypt,

O ideal seria abstrair essa tarefa de criptografar a ponto de poder receber qualquer algorítimo de hash, você pode criar uma interface hash que implementa o método hash, Assim você poderia receber objetos de qualquer classe implementa esta interface. O que importaria para esta classe é receber um objeto com metodo hash( ), ela pode permanecer "burra" em relação ao algorítimo em si. Assim ela fica flexível e pode-se usar diferentes algoritmos nela.

Neste caso o correto seria declara-los como private. Como static eles vão estar acessíveis a qualquer um que der um include na classe. Na verdade a grande sacada do static é você poder acessar métodos ou atributos de uma classe sem precisar instanciar a mesma. O ponto negativo é que isso equivale a usar globais que envenenam o código quando não bem usadas.

Acho que saquei...

>
Evite instanciar um objeto dentro de outro. Isso gera acoplamento entre classes o que, assim como globais, é outra coisa a ser evitada. Procure usar dependency injection, neste conceito em vez de instaciar o objeto dentro da classe você vai passa-lo pelo construtor ou metodo.

Embora nos controllers você poça instanciar objetos no método, no model - como no caso do include do BCrypt na classe UserModel -o melhor seria o dependency injection, assim como você esta recebendo um objeto User no método receba também um objeto BCrypt,

O ideal seria abstrair essa tarefa de criptografar a ponto de poder receber qualquer algorítimo de hash, você pode criar uma interface hash que implementa o método hash, Assim você poderia receber objetos de qualquer classe implementa esta interface. O que importaria para esta classe é receber um objeto com metodo hash( ), ela pode permanecer "burra" em relação ao algorítimo em si. Assim ela fica flexível e pode-se usar diferentes algoritmos nela.

Entendi... esse é exatamente o motivo pelo qual estou criando essa interface "Algorithm"... Acho que com sua resposta deu até para abrir mais minha mente em relação a Dependency Injection... hehhee

Puxa, obrigado Enrico e Raoni, além de sanarem minhas dúvidas, foram esclarecedores em outros pontos...

Abraços!