[php] 특성과 인터페이스

공공 서비스 발표 :

나는 특성이 거의 항상 코드 냄새이며 구성을 위해 피해야한다고 기록에 대해 진술하고 싶습니다. 단일 상속이 반 패턴이되고 여러 상속이이 문제를 복잡하게한다는 점에서 단일 상속이 자주 남용된다고 생각합니다. 대부분의 경우 상속보다 구성을 선호하여 훨씬 더 나은 서비스를 제공 할 수 있습니다 (단일 또는 다중). 특성과 인터페이스와의 관계에 여전히 관심이 있다면 …

이 말로 시작하자 :

객체 지향 프로그래밍 (OOP)은 파악하기 어려운 패러다임이 될 수 있습니다. 클래스를 사용한다고해서 코드가 객체 지향 (OO)이라는 의미는 아닙니다.

OO 코드를 작성하려면 OOP가 실제로 객체의 기능에 관한 것임을 이해해야합니다. 실제로 하는 것 대신 할 수있는 것의 관점에서 클래스에 대해 생각 해야 합니다. 이것은 약간의 코드를 “무언가로 만드는”것에 중점을 둔 전통적인 절차 적 프로그래밍과는 완전히 대조적이다.

OOP 코드가 계획 및 설계에 관한 것이라면 인터페이스는 청사진이며 객체는 완전히 구성된 집입니다. 한편, 특성은 단순히 청사진 (인터페이스)으로 구성된 집을 짓는 데 도움이되는 방법입니다.

인터페이스

그렇다면 왜 인터페이스를 사용해야합니까? 간단히 말해서 인터페이스는 코드의 취성을 떨어 뜨립니다. 이 진술이 의심 스러우면 인터페이스에 대해 작성되지 않은 레거시 코드를 유지하도록 강요받은 사람에게 문의하십시오.

인터페이스는 프로그래머와 코드 간의 계약입니다. 인터페이스는 “내 규칙에 따라 플레이하는 한 원하는대로 구현할 수 있으며 다른 코드는 중단하지 않겠다고 약속합니다.”라고 말합니다.

예를 들어, 실제 시나리오 (자동차 또는 위젯 없음)를 고려하십시오.

웹 애플리케이션이 서버로드를 줄이기 위해 캐싱 시스템을 구현하려고합니다.

APC를 사용하여 요청 응답을 캐시하는 클래스를 작성하여 시작하십시오.

class ApcCacher
{
  public function fetch($key) {
    return apc_fetch($key);
  }
  public function store($key, $data) {
    return apc_store($key, $data);
  }
  public function delete($key) {
    return apc_delete($key);
  }
}

그런 다음 HTTP 응답 오브젝트에서 실제 응답을 생성하기 위해 모든 작업을 수행하기 전에 캐시 적중을 점검하십시오.

class Controller
{
  protected $req;
  protected $resp;
  protected $cacher;

  public function __construct(Request $req, Response $resp, ApcCacher $cacher=NULL) {
    $this->req    = $req;
    $this->resp   = $resp;
    $this->cacher = $cacher;

    $this->buildResponse();
  }

  public function buildResponse() {
    if (NULL !== $this->cacher && $response = $this->cacher->fetch($this->req->uri()) {
      $this->resp = $response;
    } else {
      // Build the response manually
    }
  }

  public function getResponse() {
    return $this->resp;
  }
}

이 방법은 효과적입니다. 그러나 몇 주 후에 APC 대신 파일 기반 캐시 시스템을 사용하기로 결정했습니다. 이제 ApcCacher클래스의 기능을 표현하는 인터페이스가 아닌 클래스 의 기능을 사용하도록 컨트롤러를 프로그래밍 했으므로 컨트롤러 코드를 변경해야합니다 ApcCacher. 위 대신에 당신이 Controller클래스 CacherInterface대신에 콘크리트 대신에 의존하게 만들었다 고 가정 해 봅시다 ApcCacher.

// Your controller's constructor using the interface as a dependency
public function __construct(Request $req, Response $resp, CacherInterface $cacher=NULL)

이와 함께 인터페이스를 다음과 같이 정의하십시오.

interface CacherInterface
{
  public function fetch($key);
  public function store($key, $data);
  public function delete($key);
}

그리고 당신은 당신 ApcCacher과 당신의 새로운 FileCacher클래스를 구현 하고 인터페이스에 필요한 기능을 사용하도록 클래스를 CacherInterface프로그래밍합니다 Controller.

이 예제는 인터페이스 프로그래밍이 변경 사항으로 인해 다른 코드가 손상 될 염려없이 클래스의 내부 구현을 변경하는 방법을 보여줍니다.

특성

반면에 특성은 단순히 코드를 재사용하는 방법입니다. 인터페이스는 특성에 대한 상호 배타적 인 대안으로 생각해서는 안됩니다. 실제로 인터페이스에 필요한 기능을 충족시키는 특성을 만드는 것이 이상적인 사용 사례 입니다.

여러 클래스가 동일한 기능을 공유 할 때 (같은 인터페이스에 의해 지시 될 수 있음) 특성 만 사용해야합니다. 특성을 사용하여 단일 클래스에 기능을 제공하는 것은 의미가 없습니다. 이는 클래스의 기능을 난독 화하고 더 나은 디자인은 특성의 기능을 관련 클래스로 옮길 것입니다.

다음 특성 구현을 고려하십시오.

interface Person
{
    public function greet();
    public function eat($food);
}

trait EatingTrait
{
    public function eat($food)
    {
        $this->putInMouth($food);
    }

    private function putInMouth($food)
    {
        // Digest delicious food
    }
}

class NicePerson implements Person
{
    use EatingTrait;

    public function greet()
    {
        echo 'Good day, good sir!';
    }
}

class MeanPerson implements Person
{
    use EatingTrait;

    public function greet()
    {
        echo 'Your mother was a hamster!';
    }
}

더 구체적인 예 : 인터페이스 토론에서 귀하 FileCacher와 귀하 ApcCacher의 인터페이스 항목이 동일한 방법을 사용하여 캐시 항목이 오래되어 삭제되어야하는지 여부를 결정 한다고 상상해보십시오 (실제로는 그렇지 않지만 실제로는 마찬가지입니다). 특성을 작성하고 두 클래스 모두 공통 인터페이스 요구 사항에이를 사용할 수 있습니다.

주의해야 할 마지막 말 : 특성으로 배 밖으로 나가지 않도록주의하십시오. 독특한 클래스 구현으로 충분할 때 특성이 열악한 디자인의 버팀목으로 사용되는 경우가 종종 있습니다. 최상의 코드 디자인을 위해서는 특성을 인터페이스 요구 사항을 충족하도록 제한해야합니다.

답변

trait myTrait {
    function foo() { return "Foo!"; }
    function bar() { return "Bar!"; }
}

class MyClass extends SomeBaseClass {
    use myTrait; // Inclusion of the trait myTrait
}

                      -----------------------------------------------
                      |   Interface   |  Base Class   |    Trait    |
                      ===============================================
> 1 per class         |      Yes      |       No      |     Yes     |
---------------------------------------------------------------------
Define Method Body    |      No       |       Yes     |     Yes     |
---------------------------------------------------------------------
Polymorphism          |      Yes      |       Yes     |     No      |
---------------------------------------------------------------------

class BaseClass {
    function SomeMethod() { /* Do stuff here */ }
}

interface IBase {
    function SomeMethod();
}

trait myTrait {
    function SomeMethod() { /* Do different stuff here */ }
}

class MyClass extends BaseClass implements IBase {
    use myTrait;

    function SomeMethod() { /* Do a third thing */ }
}

trait ToolKit
{
    public $errors = array();

    public function error($msg)
    {
        $this->errors[] = $msg;
        return false;
    }
}

class Something
{
    use Toolkit;

    public function do_something($zipcode)
    {
        if (preg_match('/^[0-9]{5}$/', $zipcode) !== 1)
            return $this->error('Invalid zipcode.');

        // do something here
    }
}

trait SayWorld {
    public function sayHello() {
        echo 'World!';
    }
}

class MyClass{
  use SayWorld;

}

$o = new MyClass();
$o->sayHello();

  interface SayWorld {
     public function sayHello();
  }

  class MyClass implements SayWorld {
     public function sayHello() {
        echo 'World!';
     }
}

class SlidingDoor extends Door implements IKeyed
{
    use KeyedTrait;
    [...] // Generally not a lot else goes here since it's all in the trait  
}