2009-12-03 2 views
3

Google은 여러 가지 방법으로 고객에게 청구서를 발행하는 인보이스 모델을 보유하고 있습니다. 간결함을 기하기 위해 인상 당 비용 및 전화 당 비용 조회에 대해 중점적으로 다룰 것입니다. 내 생각은 이들 (및 나머지) 전략을 구현 한 다음 인보이스 클래스에 동적으로 혼합하는 것이 었습니다.계산에 다른 데이터를 사용하는 청구 모델의 전략 패턴?

노출 수/통화 수를 결정하는 데 사용되는 다양한 정보 소스가 있기 때문에 적절합니다. Invoice 클래스의 기본 수식을 유지하면서 전략에 캡슐화 할 수 있습니다.

인상 당 비용 계산은 간단합니다 : num impressions X cost per impression.

전화 문의 계산은 좀 더 복잡합니다 : num calls X cost per call.

class Invoice 
    def self.strategy 
    self.class_eval <<-EOS 
    include #{billing_type} 
    EOS 
    end 

    def invoice_amount 
    # this will used the module mixed in above 
    self.rate * calculate_impressions 
    end 
end 

그런 다음 모듈이 될 수있다 : 그러나

module PerImpressionCalculation 
    def calculate_impressions 
    # get the number of impessions from source a... 
    end 
end 

module PerInquiryCalcuation 
    def calculate_impressions 
    # get the number of impessions from source b... 
    end 
end 

, 호출의 길이를 기준으로하고이 모델에 따라 변화하는 통화 횟수 여부. 따라서 전화 로그를 검색 할 때이 값을 가져야합니다.

제 질문은이 값을 어디에 저장합니까? 10 초 통화를 기반으로 한 인보이스 및 30 초 통화를 기반으로하는 인보이스에 대한 전략을 세울 수 있지만 낭비입니다. 임계 값이 15 초가 되길 원하는 거래가 나오면 새로운 전략을 작성해야합니다. 이 문제를 해결하기위한 최상의 설계 선택은 무엇입니까?

답변

0

클래스 메서드 ancestors을 사용하여 모든 혼합 모듈과 기본 클래스를 검색 할 수 있습니다. 따라서 인스턴스가 myInvoice 인 경우 myInvoice.class.ancestors을 사용하면됩니다. 포함 여부를 확인할 수 있도록 상수 배열을 반환합니다.

사실,이 컨텍스트에서 전통적인 구성/집계가이 경우 더 적절하다고 생각합니다. 동시에 여러 가지 전략이 공존하는 경우 더 안전합니다. 기본 클래스에 영향을 주었기 때문에 모든 송장 전략을 변경하지 않으려 고합니다.

3

전략을 모듈 mixins로 구현하지 마십시오. 공개 PerInquiryCalculation 메서드를 사용하여 완전한 클래스로 구현하고 해당 생성자를 사용하여 Invoice 클래스에 올바른 메서드를 삽입합니다.

이 방법을 사용하면 각 전략 클래스는 구성 중에 자체 상태 변수를 설정할 수 있습니다. PerInquiryStrategy의 생성자는 PerInquiryCalculation 메서드가 수수료를 계산하는 데 사용하는 지속 시간 임계 값을 사용할 수 있습니다.