하위 클래스를 반복하거나 더 좋은 방법이 있습니까?

Question

나는 보험 중개인을 위해 일하고 있으며 여기에 제가 구현 한 것들 중 하나는 고객의 내용을 입력으로 받아들이고 여러 보험 회사에 대한 견적 목록을 응답으로 제공하는 견적 서비스입니다. - 이러한 스크립트는 인덱스의 배열에 나와있는

• 인덱스 페이지는
• 인용 데이터가 차례로 각 보험사의 계산 스크립트로 전송 된 JSON 문자열에 인용 데이터를 수신 다음과 같이

  그것은 현재 작동 페이지

  • 각 보험사의 계산이 데이터가 특정 스크립트로 전송되는 보험
  • 를 시작 날짜를 지정 사용해야 요금의 어떤 설정을 참조하는 데이터베이스 테이블을 협의하고 속도는 생성이다 D 및 인덱스
• 인덱스를 반환 오름차순으로 정렬 결과 및 발신자 용액의 문제점

에 JSON 문자열로로 리턴하는 단계이다 :

• 테스트하기가 어렵다 - 각 속도 집합은 모 놀리 식 코드 블록이므로 조각을 개별적으로 테스트 할 수 없다.
• 유지 보수가 어렵다 - 보험자에게 새로운 속도 집합을 추가하는 것은 현재 속도를 새로운 스크립트에 복사하는 것이다. m 필요한 변경을 요구하고 새 요율의 시작 날짜와 함께 데이터베이스 테이블에 새 항목을 작성합니다. 차례로 이것은 리드 : 요금
사이의 코드 중복의
• 많은 나의 새로운 부분적으로 형성 솔루션은 보험 회사 또는 제품과 Insurer1, Insurer2 등에 관계없이 모든 따옴표에 공통 기능을 포함하는 주요 Quoteservice 클래스를 가지고있다

인덱스 페이지에서 호출하여 견적 비율을 얻는 하위 클래스. 이것들은 각 속도 집합 (Insurer1May2012, Insurer1July2012 등)에 대한 서브 클래스를 갖습니다. 내 문제는 시작일에 대해 올바른 비율을 선택하는 데이터베이스 테이블의 필요성을 없애려는 데있다.

내가

$quoteresults=array(); 
$quoteresults=array_merge(Insurer1->getQuote($quotedata), $quoteresults); 
$quoteresults=array_merge(Insurer2->getQuote($quotedata), $quoteresults); 

을 말할 수 있기를 각각 InsurerX 객체가 시작 날짜에 따라 올바른 서브 클래스 (InsurerXMay2012, InsurerXJuly2012 등)를 사용하는 거라고 - 아마 각 함수 getStartdate()를 호출하여 서브 클래스의 레이트가 시행되었을 때의 일자 (또는 타임 스탬프)를 돌려주는 서브 클래스의 불행히도, 클래스의 하위 클래스를 순환하는 가장 좋은 방법을 찾은 후에 이것이 최선의 방법이 아닐 수도 있습니다.

궁극적 인 목적은 복수 파일 및/또는 데이터베이스 테이블을 변경하지 않고 요금 변경을 위해 Insurer1Sept2012 유형의 하위 클래스 하나를 추가하는 것입니다.(이전 요금을 덮어 쓰기하는 것은 선택 사항이 아닙니다 - 조정 과정은 그들이 대체 한 후 최대 12 개월 동안 요금을받을 수 있어야합니다) 내가 일하는 새로운 버전을 확인하는 방법

예

abstract class Quoteservice 
{ 
    // Various common functionality here... 
} 

class Insurer1 extends Quoteservice 
{ 
    public function getQuote($quotedata) 
    { 
     $subclass=null; 
     // This is the bit I'm not sure of... 
     // Maybe something like: 
     foreach($subclasses as $thissubclass) 
     { 
      $subclassstart=$thissubclass->getStartdate(); 
      // Ignore all start dates greater than proposed start date 
      if($subclassstart < $quotedata['startdate']) 
      { 
       $subclasses[$subclassstart]=$thissubclass; 
      } 
     } 
     ksort($subclasses); 
     $subclass=array_pop($subclasses); 
     return $subclass->getQuote() 
    } 
} 

class Insurer1May2012 extends Insurer1 
{ 
    public function getStartdate() 
    { 
     return 1335830400; // unix time stamp for 1st May 2012 
    } 

    public function getQuote($quotedata) 
    { 
     // Calculate May's rate here... 

     return $quoteinfo; 
    } 
} 

class Insurer1July2012 extends Insurer1 
{ 
    public function getStartdate() 
    { 
     return 1341100800; // unix time stamp for 1st July 2012 
    } 

    public function getQuote($quotedata) 
    { 
     // Calculate July's rate here... 

     return $quoteinfo; 
    } 
} 

Answer 1

가능하지만 클래스 이름에 변수 데이터를 저장

은 내가 추천하는 방법이 아니다. PHP 언어에서 이러한 종류의 데이터 저장을위한 기본 제공 구조가 이미 있습니다.

견적의 각 날짜에 대해 하위 하위 클래스를 사용하는 대신 클래스 생성자을 사용하여 필요한 따옴표를 계산할 수있는 날짜 변수를 사용합니다. 예를 들어

다음 Quoteservice 클래스는 Quoteservice의 모든 인스턴스에 사용할 수 등 getStartDate() 등의 방법을 구현할 수

class Insurer1 extends Quoteservice { 
    public function __construct(DateTime $date) { 
     // Do something with the data. 
    } 
} 

// ... would be initialised like this: 

$quoteResults = array(); 
$quoteResults[] = new Insurer1("2012-07-30"); 
$quoteResults[] = new Insurer2("2012-07-21"); 

.

Insurer1, Insurer2 ... 클래스의 필요성을 완전히 없애고 보험자의 이름을 다른 인수로 생성자에 전달할 수도 있습니다.

$someQuote = new Quoteservice("2012-07-30", "Insurer1"); 

Answer 2

단일 PHP 페이지/스크립트로 구현하려는 것은 비 스타트입니다. 그리고 일단 논리를 분리하기 시작하면 다른 모든 것이 훨씬 간단 해집니다.

인용 데이터가

차례

각 보험사의 계산 스크립트로 전송됩니다 나는 성능이 너무 큰 시간을 빨아 내기. 조각 그리고 최소한, 그것은 보험 회사 당 하나 개의 URL이어야 개별적으로

을 테스트 할 수 있도록

요금의 각 세트는 코드의 모 놀리 식 블록은 다시 라우팅을 구현할 수있는 것입니다 해당 보험 회사와 관련된 다른 URL 그리고 물론 당신은 웹 서비스를 집계을위한 전면 컨트롤러로 스크립트를 구현합니다. 캡슐화 -

당신은 객체 지향 프로그래밍의 핵심 포인트를 누락 될 것으로 보인다 클래스의 서브 클래스를 통해 루프 최선의 방법을 검색 한 후 보인다.

올바른 서브 클래스 (InsurerXMay2012 ....

OMG, NO!

당신은 코드와 데이터를 혼동를 사용합니다.당신이 당신의 이메일을 확인할 때 서브 클래스

의 각 기능 getStartdate()를 호출하여 의심 할 여지 each set of rates is a monolithic block of code 아마

, 당신은 POP 서버가 모든 그것이 사람을 찾기 위해 단지 보유하고 이메일을 읽고 생각하지 않습니다 어느 주소로 왔습니까?

최적의 솔루션은 여러 집계 된 URL (예 : HTTP 레벨 아키텍처)에서 기능을 분리하고 라우팅은 데이터 구조 (예 : 데이터베이스)에 의해 주도되어야한다고 생각하지만 합리적으로 원하는 결과를 얻을 수 있습니다 시스템은 객체 지향 PHP를 사용합니다. 그러나 문제를 분리 할 때까지 코드 아키텍처를 계층화하고 코드와 데이터를 분리하고 실행 스레드를 코드를 통해 올바르게 라우팅하는 방법을 연습 한 다음 스파게티 코드를 엉망으로 만듭니다.

Answer 3

나는 Insurer이 QuoteService을 확장해야한다고 생각하지 않습니다. 그것들은 때때로 (때때로 겹쳐지는) 다른 기능을 가지고있다. QuoteService은 InsuranceQuotes의 집합입니다. Insurer은 InsuranceQuote을 제공하는 업체입니다. InsuranceQuote는 Insurer이하고 Insuree이 될 수있는 사람에 따라 달라집니다. 이 같은 클래스와

$client= new Insuree; 
$quoter= new QuoteService; 
$quoter->calculate($client); 
$quoter->show_quotes(); 

:

class Insuree { 

    protected $age; 
    protected $gender; 
    protected $marital_status; 
    protected $drivers_license; 
    protected $address; 
    //etc. with constructor and getters/setters 
} 

class Insurer { 

    function get_quote(Insuree $client, $args=null) { 
    //do stuff 
    return $quote; //InsuranceQuote obj. 
    } 
} 

class InsuranceQuote { 
    protected $period; 
    protected $total; 
    //etc. with constructor, getters, setters 

    function out(){ 
    //echo something 
    } 
} 

class QuoteService { 

    protected $insurers; //SplObjectStorage containing Insurer objects 
    protected $quotes; //SplObjectStorage containing InsuranceQuote objects 

    function __construct($args=null){ 
    $this->get_insurers($args); //limit the list with $args if you like 
    $this->quotes=new SPLObjectStorage; 
    } 

    protected function get_insurers($args){ 
    $this->insurers=new SPLObjectStorage; 
    //access list of insurers from db(?) 
    while($row = $list->fetch_assoc()){ 
     $i=new Insurer($list); 
     $this->insurers->attach($i); 
    } 
    } 

    function calculate(Insuree $client, $args=null) { 
    foreach($this->insurers as $quoter){ 
     $this->quotes->attach($quoter->get_quote($client, $args)); 
    } 
    } 

    function show quotes(){ 
    foreach($this->quotes as $quote) $quote->out(); 
    } 

} 

Insurer를 서브 클래 싱하는 방법에 관한 : 그래서 이런 식으로 뭔가 갈 수있는 각 Insurer에 데이터를 특정하는 것은 어딘가에 저장해야합니다. 표준 형식으로 저장할 수 있다면 Insurer 클래스가 하나만 필요합니다. 이 데이터를 보유 할 테이블을 설계하는 것이 설계 프로세스에서 가장 어려운 부분입니다. 그리고 데이터의 모양에 대해 더 많이 알지 못해도 구조를 제안하고 싶지 않습니다.