API 인터페이스 우수 사례 : 배열 또는 객체를 전달하여 작업 하시겠습니까?

Question

저는 같은 인터페이스를 통해 지불 프로세서를 구현할 수있는 지불 라이브러리를 만들고 있습니다. 지금 가지고있는 문제는 프로세서에 공급되는 데이터의 방식을 개선하고 싶습니다. 지금은 배열이고 나는 그 배열에 만족하지 않습니다. 문제는 사전에 모든 필드를 알지 못하면 통지로 끝나거나 프로세서 코드 자체에 지옥이 필요하다는 것입니다. 아이디어는 응용 프로그램마다 다르며 프로세서와 함께 작동하도록하지만 프로세서가 필요한 데이터 피드를 확보하도록하기 때문에 모든 종류의 데이터 구조를 취할 수 있어야합니다.

내 아이디어는 이제 그것을 개체로 변경하는 것입니다. 객체는 모든 프로세서가 필요로하고 일반적으로 공통으로 사용하는 제한된 필드 집합과 함께 제공되지만 객체는 추가 필드를 가져올 수 있도록 확장 될 수 있습니다.

그 이점은 지불 객체가 전달되도록 프로세서에서 유효성을 검사 할 수 있고 예외를 throw하지 않으면 모든 필수 필드를 구현하는지 확인할 수 있다는 것입니다.

이것이 좋은 접근 방법인가, 아니면 모든 프로세서가 전달 된 데이터에 의존 할 수 있는지 확인하는 더 나은 방법과 실패한 방법이 있습니까?

Answer 1

, 나는 다음과 유사한 아키텍처를 사용할 수 있습니다 특정 프로세서가 프로세서 별 로직을위한 추가 데이터를 수용 할 수있는 특정 구현. 유효성 검사 규칙에 따라 성공적으로 구성 할 수없는 경우에도이 개체를 지불 처리 논리로 전달할 필요가 없습니다.

인터페이스 payment_processor ->이 인터페이스는 프로세서 고유의 구현 클래스가 기본 payment_data 객체를 처리 할 수 ​​있어야하는 공통 메소드를 정의합니다. payment_processor 구현

프로세서 고유의 클래스 ->이 클래스는 모든 기본 payment_data 개체를 처리 할 수있을 것이지만, 선택적으로 해당 프로세서를위한 추가 기능을 구현 payment_data의 프로세서 고유의 서브 클래스를 전달 할 수 있습니다.

Answer 2

개체가 좋은 접근 방법입니다. 그것은 당신에게 꽤 많은 유연성을 제공 할 정도로 일반적입니다. 유연성을 최대화하기 위해 인터페이스에 코딩해야합니다.

물론 개체를 디자인하는 방법은 ...

Answer 3

당신은 맞는 생각이 있습니다. 나는 당신이 필요로하는 모든 요소들에 대한 __construct를 가진 모델을 사용하고 다른 곳에서는 필요에 따라 모델 (당연히 객체이다)을 삽입 할 것을 권한다. 이 방법으로 인터페이스를 통해 다양한 모델을 매우 쉽게 사용할 수 있습니다. >이 클래스는 모든 일반적인 필드가 가능성 몇 가지 일반적인 데이터 유효성 검사를 제공 할 것이다, 당신은 또한 특정 프로세서 -와이 하위 클래스 수 -

가

클래스 payment_data :

귀하의 경우

Answer 4

나는 당신이하고있는 일을 정확하게 수행했으며 배열을 고수했습니다. 필요한 "필드"가 누락되어 있으면 배열 검사가 매우 빠릅니다. 배열 키가 필드 이름 인 경우 필수 필드의 배열을 만들고이 필드를 사용하여 필수 필드의 존재 여부를 테스트하십시오.

function loadData($data) { 
    static $rqd_fields = array('field1','field2','field3'); 
    $passed_fields = array_keys($data); 
    $missing_fields = array_diff($rqd_fields, $passed_fields); 
    if (count($missing_fields)>0) { 
     // error, return $missing_fields 
    } else { 
     // ok, continue 
    } 
}