是正确的绑定具体实现?

时间:2016-08-11 12:27:11

标签: php oop design-patterns architecture laravel-5.2

我使用Laravel 5.2来构建抽象系统。当客户需要一些特定的实现时,我需要覆盖代码的某些部分。

我想的是这种情况:

默认情况下,Controller依赖于某些自定义请求(具体)。当客户问我另一个业务规则时,我必须扩展此自定义请求并将此子实现绑定到父级。在我的提供商上做这样的事情:

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

谈到软件架构概念,我能做到吗?这是对的吗?

[编辑]

一个具体的例子,我有一个使用这样的请求的动作:

class SomeController extends Controller
{

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

}

我的请求有一些业务验证逻辑:

class ParentRequest extends Request
{

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

}

现在一切正常,我的默认系统逻辑还可以! 但我的软件是其他项目的基础,我们将通过作曲家和最终项目使用它只是特定代码将属于应用程序路径

当客户要求对业务逻辑进行一些修改时,我们需要覆盖旧的。我的问题是:这是正确的吗?从概念上讲,我可以像下面的代码那样做吗?

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);
   }

}

1 个答案:

答案 0 :(得分:0)

和我的老师谈话,他说我做不好。我总是要重新开始工作。我问的可能不是一个错误的模式,但软件的概念可能是错误的。

我会以较小的规模制作大量基础包,以便更容易重构。当一些客户要求新功能或新业务规则时,我会开发它。

开发极其抽象的软件可能是错误的。它可以做任何事情,而不是专门针对客户的需求。它总是必须进行分析。没有规则,每个软件都是不同的故事