2016-02-04 2 views
0

Рассмотрим следующий классОбработка Dependency объекта

class User 
{ 
    protected $password; 

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

    public function getPassword() 
    { 
     return $this->password; 
    } 
} 

Я хочу подать Bcrypt на пароль, используя Zend\Crypt\Password\Bcrypt в пользовательском объекте, так как это создает зависимость я хочу знать, как правильно справиться с этим, я могу думать о несколько подходов к этой работе, позвольте мне уточнить

Подход 1: Здесь мы создаем экземпляр класса внутри метода и применяем необходимые изменения.

class User 
{ 
    protected $password; 

    public function setPassword($password) 
    { 
     $bcrypt = new Bcrypt(); 
     $this->password = $bcrypt->create($password); 
     return $this; 
    } 

    public function getPassword() 
    { 
     return $this->password; 
    } 

    public function verifyPassword($password) 
    { 
     $bcrypt = new Bcrypt(); 
     return $bcrypt->verify($password, $this->getPassword()); 
    } 
} 

К моему пониманию этого не рекомендуется подход, так как я вижу две проблемы здесь

  1. Bcrypt() экземпляра дважды
  2. Это делает объект пользователя тесно связанные с Bcrypt

Я могу решить проблему-1 путем создания экземпляра Bcrypt() один раз в конструкторе класса и использовать его, когда это требуется, однако это не решает проблему-2

подход 2: Переместить объект Bcrypt из класса пользователя и ввести его во время установки пароля

class User 
{ 
    protected $password; 

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

    public function getPassword() 
    { 
     return $this->password; 
    } 
} 

// Init Bcrypt 
$bcrypt = new Bcrypt; 

// Instantiate user object and create a password 
$user = new User; 
$user->setPassword($bcrypt->create($password)); 

// Verify user password 
if ($bcrypt->verify($password, $user->getPassword())) { 
    // Password is verified 
} 

Каков наилучший способ по этому поводу?

Спасибо.

+0

Вы правы, я думаю, что лучший подход должен иметь класс PasswordService –

+0

Если вы планируете добавить другие методы, которые будут обрабатывать пароль, этот подход имеет смысл. В противном случае, какая разница между использованием класса Bcrypt и класса PasswordService (в случае вашего второго вопроса)? –

+0

Вы не будете отделяться от рамки в любом случае, если вы не используете какой-то интерфейс 'HashingMechanism', который (на данный момент) реализован классом BcryptProxy. – shudder

ответ

1

А может быть, вы можете просто создать класс Password и переместить туда эту логику? Вы можете сделать что-то вроде этого:

class Password 
{ 
    private $password; 
    public __construct($password) 
    { 
     $this->password = $password; 
    } 

    public crypt(Zend_Crypt_Password_PasswordInterface $crypt) 
    { 
     $this->password = $crypt->create($password); 
    } 
} 

или использовать Decorator. Оба решения предоставляют вам возможность расширения кода. Вместо Zend_Crypt_Password_PasswordInterface вы также можете использовать свой собственный Wrapper. Это было бы ИМХО даже лучшим решением.

И тогда вы можете установить пароль для конкретного пользователя, и это не волнует, был ли он шифрованный, перемешанным или что-то:

class User 
{ 
    private $password; 

    public function changePassword(Password $password) 
    { 
     $this->password = $password; 
    } 
} 
+0

Спасибо, ты указал на правильное направление. Я завершил внедрение интерфейса для пароля, поэтому любой расширяемый класс должен использовать этот интерфейс, таким образом, может быть реализован любой алгоритм создания пароля или соответствия. –

0

Я предполагаю, что первый подход лучше, потому что его скрыть использованием bcrypt в классе пользователя.

Я не думаю, что другой программист должен иметь в виду, что он должен использовать, например, $bcrypt->verify при работе с классом User.

+0

Я думаю, что правило для лучшего дизайна всегда предполагает, что произойдут изменения. хотя я согласен с тем, что лучше скрывать внутреннюю функцию, я также думаю, что в то же время существует несколько шаблонов дизайна, которые позволяют нам справляться с такими вещами. –

Смежные вопросы