1
느슨하게 결합 된 OOP 디자인과 관련된 질문이 있습니다. 우리가 이메일느슨하게 결합 된 디자인에서 인프라 클래스 사용
final class Email
{
private $_email;
public function __construct($email)
{
self::isValid($email);
$this->_email = $email;
}
public function getEmail()
{
return $this->_email;
}
public static function isValid($email)
{
// some validation logic goes here
return true;
}
} 실제로 isValid 메소드를 구현 할 때까지
모든 것이 간단하고 알기 쉽게 같은 간단한 값 객체를 고려한다.
1)과 같이 몹시 추한 것이 될 수 있습니다 내 자신의 유효성 검사 논리 구현 : 여기이 옵션을 가지고 사용하는 일부 빌드 - 프레임 워크를
public static function isValid($email)
{
$v = preg_match(
'/^[-a-z0-9!#$%&\'*+\/\=?^_`{|}~]+(?:\.[-a-z0-9!#$%&\'*+\/\=?^_`{|}~]+)*@(?:[a-z0-9]([-a-z0-9]{0,61}[a-z0-9])?\.)*(?:aero|arpa|asia|biz|cat|com|coop|edu|gov|info|int|jobs|mil|mobi|museum|name|net|org|pro|tel|travel|pro|[a-z][a-z])$/',
$email
);
return $v > 0;
}
2)
public static function isValid($email)
{
$validator = new Zend_Validate_Email(); // tight-coupling detected!
return $validator->isValid($email);
}
휠을 다시 발명하고 싶지 않으므로 코드를 반복하고 싶지 않으므로 첫 번째 방법을 따르고 싶지 않습니다. 따라서 두 번째 방법을 고수하고 있습니다.
두 번째 방법을 따르는 경우 문제가 발생합니다. 즉, 클래스가 다른 프레임 워크 클래스에 의존하게됩니다.
내 실제 질문은 단순한 경우 종속성 삽입을 사용하지 않고 직접 엔터티/값 개체에서 하위 수준 인프라 클래스를 사용하는 것이 허용되는지 여부입니다.
"올바르게"이 예제를 구현하려면 느슨하게 결합하려는 목적으로 코드가 훨씬 복잡해집니다. isValid 함수에서 사용할 미리 구성된 EmailValidator의 인스턴스를 내 Value Object (Email) 클래스에 제공하는 EmailFactory를 작성해야합니다.
빌트인 프레임 워크 유효성 검사기는 로직을 캡슐화하고 상태 또는 컨텍스트에 의존하지 않는 '기능'만 있으면 괜찮습니다. –