2014-02-20 2 views
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를 작성해야합니다.

+0

빌트인 프레임 워크 유효성 검사기는 로직을 캡슐화하고 상태 또는 컨텍스트에 의존하지 않는 '기능'만 있으면 괜찮습니다. –

답변

0

외부 함수가 필요하지 않으면 I 의존성을 직접 재사용하고 주입을 피할 것입니다.

도메인 개체는 도메인 규칙을 캡슐화하고 이러한 규칙을 보장하는 데 필요한 모든 정보를 포함해야합니다. 낮은 결합보다 높은 응집력 주위에 더 많이 설계되었습니다 (응집체 자체의 개념은 상호 의존성을 줄이기위한 수단으로 사용됩니다).

예에서 Email 클래스는 전자 메일 주소 유효성 검사를위한 단일 실패 지점이어야합니다. 모든 도메인 객체가 해당 클래스를 통해 전자 메일의 유효성을 검사하면 기존 프레임 워크 (또는 제 3 자) 기능을 재사용하는 것이 구현 세부 사항이며 느슨한 결합과 관련하여 문제가되지 않습니다. 유효성 검사 규칙이 변경되면 Zend_Validate_Email 또는 일부 사용자 지정 코드를 사용하여 함수를 다시 구현해야합니다.그것으로 많은 문제를 가져올 것입니다 단체 또는 값 객체에 유효성 검사 논리를 주입

: 도메인 개체에 속하는

  • 논리는 일반적으로 엔티티로 서비스를 주입 다른 클래스
  • 로 이동 될 것입니다 만 EmailValidator 클래스 인터페이스를 도입 not advised
  • Reused Abstractions Principle
  • 가에 isValid 정적 메소드를 호출 위반불가능합니다

드물게 유효성 검사 로직에 외부 리소스가 필요한 경우에만 주입 된 서비스가있는 팩토리를 사용하는 경향이 있지만 도메인 객체 생성시 유효성을 검사하는 경향이 있습니다.하지만 디자인을 다시 생각한 후에 도메인 모델의