디자인 모델 7 원칙 재 독

원본 링크:http://www.cnblogs.com/XiongMaoMengNan/p/7592702.html
GOF 라 는 책 에서 7 가지 디자인 원칙 을 제 시 했 는데 7 가지 원칙 은 이상 적 인 상태의 표현 이지 만 실제 프로젝트 개발 에서 이런 원칙 의 제한 을 깨 야 할 수도 있다.
1. 단일 직책 원칙 (Single Responsibility Principle, SRP): There should never be more than one reason for a class to change. 단일 직책 (최소 입자 도) 만 수행 해도 가능 한 한 클래스 변경 가능성 을 낮 출 수 있 고 서로 다른 직책 은 따로 정의 해 야 한 다 는 뜻 이다.사실 이 원칙 은 클래스 뿐만 아니 라 인터페이스 와 방법의 디자인 에 도 적용 된다.
2. 개폐 원칙 (Open - Closed Principle, OCP): Softeware entities like classes, modules and functions should be open for extension but closed for modifications.예 를 들 어 매개 변수 유형, 인용 대상 은 구체 적 인 실현 류 가 아니 라 인터페이스 나 추상 류 를 사용 해 야 한다.
3. 의존 반전 원칙 (Dependence Inversion Principle, DIP): High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. 의존 은 방법 매개 변수 에 많이 나타난다.고 층 모듈 은 저층 모듈 (구체 적 실현) 에 의존 해 서 는 안 된다. 저층 모듈 (구체 적 실현) 이 변화 하면 고 층 모듈 의 불필요 한 변 화 를 일 으 킬 수 있 고 고 층 모듈 위 에 더 높 은 모듈 이 존재 할 수 있 기 때문에 둘 다 이미지 추출 에 의존 해 야 한다.이 원칙 은 리 씨 교체 원칙 과 결합 하면 더욱 이해 하기 쉽 고 이런 원칙 들 이 시스템 디자인 에 고립 되 어 사용 되 지 말고 협동 하여 운용 해 야 한 다 는 것 을 알 수 있다.
4. 리 씨 대체 원칙 (Liskov Substitution Principle, LSP): Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. 모든 기본 클래스 가 나타 날 수 있 는 곳 에 하위 클래스 가 나타 날 수 있 으 며 기본 클래스 의 모든 규칙 에 따라 정의 해 야 합 니 다.하위 클래스 는 LSP 를 만족 시 켜 야 상속 을 허용 합 니 다. 그렇지 않 으 면 이러한 상속 관 계 를 끊 습 니 다.
5. 인터페이스 격 리 원칙 (Interface Segregation Principle, ISP): Client should not be forced to depend upon interfaces that they don 't use. dependecy of one class to another one should depend on the smallest possible interface. 여러 개의 격 리 된 연결 구 를 사용 하 는 것 이 하나의 인 터 페 이 스 를 사용 하 는 것 보다 좋 고 클래스 간 의 결합 도 를 낮 추 는 데 도 유리 하 다.클래스 간 의 의존 관 계 는 최소 인터페이스 위 에 세 워 져 야 하 며, 클래스 가 인터페이스 에서 자신 에 게 쓸모없는 방법 상황 이 나타 나 는 것 을 방지 해 야 한다.
6. 디 미트 법칙 (Law of Demeter, LoD) 은 최소 지식 원칙 (Least Knowledge Principle, LKP) 이 라 고도 부른다. Only talk to your immedate friends. 하나의 모듈 이나 서브 시스템 은 가능 한 한 다른 모듈 이나 서브 시스템 과 직접적인 상호작용 을 하지 않도록 해 야 한다. '인 스 턴 트 친구' 라 는 중개인 을 늘 려 서 통신 을 하고 '친구' 와 만 연락 하 며'낯 선 사람' 은 일체 만 나 지 않 습 니 다. 모듈 이나 서브 시스템 에 버 전 업그레이드 업데이트 나 환경 이식 이 나타 나 면 친구 가 변 하지 않 으 면 됩 니 다.
7. 합성 / 중합 복용 원칙 (Composite / Aggregate ReusePrinciple, CARP): 이 원칙 은 계승 을 사용 하 는 것 이 아니 라 디자인 에 있어 서 가능 한 한 합성 / 중합 을 사용 하여 재 활용 의 목적 을 달성 하도록 요구한다. 즉, 전 자 는 후자 보다 우선 하여 운용 된다 는 것 이다. 계승 은 기본 적 인 세부 사항 을 하위 클래스 에 노출 시 키 고 백 박스 재 활용 이 라 고도 부 르 며, 기본 클래스 가 바 뀌 면 하위 클래스 도 상응 하 게 변동 해 야 하 며, 다 중 계승 은 유지 하기 어렵다. CARP 는 거의 모든 환경 에 사용 할 수 있 으 며, 이에 따라 재 활용 할 수 있다.라이 소, 하지만 합성 / 취 합 으로 인해 클래스 의 여러 대상 을 관리 해 야 합 니 다. 다음은 CARP 가 사용 하 는 인 스 턴 스 입 니 다.

/**
*   
*/
class Person
{
    private $hand;
    
    public function Person()
    {
        $hand = New Hand();
    }
}

/**
*   
*/
class Person
{
    private $hand;
    
    public function setHand()
    {
        $this->hand = New Hand();
    }
}

다음은 상기 디자인 원칙 의 정신 을 표현 하 는 코드 (PHP) 입 니 다.

php
/**
*          《    》          。
*                   ，             。
*/


/**
*
* Calculation   add、sub、mul div                 。
*
*          ，                 ，          。
*
*/
interface Calculation
{    
    /**
    * do()              
    *
    *
    */
    public function do(float $operand1, float $operand2) : float;
}

/**
* AddCalculator      
*/
class AddCalculator implements Calculation
{
    /**
    *       
    */
    public function do(float $operand1, float $operand2) : float
    {
        return $operand1 + $operand2;
    }
}

/**
* SubCalculator      
*/
class SubCalculator implements Calculation
{
    /**
    *       
    */
    public function do(float $operand1, float $operand2) : float
    {
        return $operand1 - $operand2;
    }
}

/**
* MulCalculator      
*/
class MulCalculator implements Calculation
{
    /**
    *       
    */
    public function do(float $operand1, float $operand2) : float
    {
        return $operand1 * $operand2;
    }
}

/**
* DivCalculator      
*/
class DivCalculator implements Calculation
{
    /**
    *       
    */
    public function do(float $operand1, float $operand2) : float
    {
        return $operand1 / $operand2;
    }
}


class Calculator
{ 
    /**
    *      
    */
    private $calculator;
    
    /**
    *           ，          $operand1
    */
    private $result = NULL;
    
    public function __construct(Calculation $calculator = NULL)
    {
        $this->calculator = $calculator;
    }
    
    /**
    *        
    *
    * @return void
    */
    public function renewCalculator(Calculation $calculator)
    {
        $this->calculator = $calculator;
    }
    
    /**
    *     
    */
    public function do(float $operand1, float $operand2 = NULL, Calculation $calculator = NULL) : float
    {
        //  $calculator != NULL，        
        $this->calculator = $calculator ?? $this->calculator;
        
        if ($operand2 === NULL) {//         
            $operand2 = $operand1;
            $operand1 = $this->result;
        }
        
        $this->result = $this->calculator->do($operand1, $operand2);
        echo "{$this->result}
";
        
        return $this->result;
    }
}

$cal = new Calculator(new AddCalculator());
$cal->do(12, 104.5);//116.5
$cal->do(12);//128.5

$cal->renewCalculator(new SubCalculator());
$cal->do(12);//116.5
$cal->do(104.5);//12
$cal->do(12);//0
$cal->do(12, null, new AddCalculator());//12

$cal->renewCalculator(new MulCalculator());
$cal->do(12, 104.5);//1254
$cal->do(12);//15048

$cal->renewCalculator(new DivCalculator());
$cal->do(12);//1254
$cal->do(12);//104.5
$cal->do(0);//INF. Warning: Division by zero
$cal->do(INF);//NAN
$cal->do('INF');//Fatal error: Uncaught TypeError: Argument 1 passed to Calculator::do() must be of the type float, string given

 
다음으로 전송:https://www.cnblogs.com/XiongMaoMengNan/p/7592702.html