바인드 콘크리트 구현이 올바른가요?

Question

저는 추상 시스템을 구축하기 위해 Laravel 5.2를 사용하고 있습니다. 고객이 특정 구현을 필요로 할 때 코드 일부를 재정의해야합니다.

컨트롤러는 기본적으로 일부 사용자 지정 요청 (콘크리트)에 따라 달라집니다 : 내가 생각하고 무엇

이 시나리오 같은 것입니다. 고객이 나에게 다른 비즈니스 규칙을 요청하면이 사용자 지정 요청을 확장하고이 하위 구현을 부모에게 바인딩해야합니다.

$this->app->bind(ParentImpl::class, ChildImpl::class); 

소프트웨어 아키텍처 개념에 대해 이야기하고 싶습니다. 어떻게해야합니까? 맞습니까?

[편집]

구체적인 예를 들어,이 같은 요청 사용하는 동작이 있습니다

class ParentRequest extends Request 
{ 

    public function rules() 
    { 
     return [ 
     'a_field' => 'required', 
     'b_field' => 'max:100' 
     ]; 
    } 

} 

이제 모든 :

class SomeController extends Controller 
{ 

    public function someAction(ParentRequest $request) 
    { 
     # perform action 
    } 

} 

내 요청이 일부 비즈니스 유효성 검사 논리가를 작동, 내 기본 시스템 논리는 괜찮습니다! 하지만 내 소프트웨어는 다른 프로젝트의 기본입니다, 우리는 작곡가를 통해 그것을 사용하고 특정 코드는 애플 리케이션 경로에 속하는 것입니다.

고객이 비즈니스 로직의 수정을 요청하면 이전 버전을 재정의해야합니다. 내 질문은 : 맞습니까? 개념적으로 말하면서 아래의 코드와 같은 것을 할 수 있을까요?

class ChildRequest extends ParentRequest 
{ 

    public function rules() 
    { 
     return [ 
     'a_field' => '', 
     'b_field' => 'max:255' 
     ]; 
    } 

} 

그리고, 프로젝트의 모든 종속성을 대체 할 바인딩 :

class AppServiceProvider extends ServiceProvider 
{ 

    public function register() 
    { 
     $this->app->bind(ParentImpl::class, ChildImpl::class); 
    } 

} 

Answer 1

내 선생님과 대화 나누기, 그는 내가 완벽하게 일을 할 수 없다고. 나는 항상 다시 작업해야 할 것이다. 내가 물었던 것은 어쩌면 틀린 패턴이 아니 겠지만, 소프트웨어의 개념은 아마 잘못되었다.

기본 팩키지를 리팩터링하기 쉽도록 작은 규모로 만들 계획입니다. 어떤 고객이 새로운 기능이나 새로운 비즈니스 규칙을 요구할 때 그것을 개발합니다.

매우 추상적 인 소프트웨어를 잘못 개발했습니다. 그것은 모든 것을 할 수 있으며 고객의 필요에 따라 구체적이지 않습니다. 항상 분석되어야합니다. 아무 규칙도 없다, 모든 소프트웨어는 다른 이야기이다