是正确的绑定具体实现吗？答案

【问题标题】：Is correct bind concrete implementations?是正确的绑定具体实现吗？
【发布时间】：2016-12-18 04:40:22
【问题描述】：

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

我的想法是这样的场景：

默认情况下，控制器依赖于一些自定义请求（具体）。当客户问我另一个业务规则时，我必须扩展这个自定义请求并将这个子实现绑定到父实现。在我的 Provider 上做这样的事情：

$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'
      ];
   }

}

现在一切正常，我的默认系统逻辑正常！ 但我的软件是其他项目的基础，我们将通过 composer 使用它，在最终项目中只是特定代码将属于应用路径。

当客户要求对业务逻辑进行一些修改时，我们需要覆盖旧的。我的问题是：它正确吗？从概念上讲，我可以执行以下代码吗？

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

}

【问题讨论】：

您能否更具体地解释一下这个问题？你的解释太抽象了，很难理解。
@SupunWijerathne 我编辑了它:)

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

【解决方案1】：

与我的一位老师交谈时，他说我做不到完美的工作。我总是需要重新处理它。我问的可能不是错误的模式，但软件的概念可能是错误的。

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

开发极其抽象的软件可能是错误的。它可以做任何事情，而不是特定于客户的需求。它总是需要被分析。没有规则，每个软件都是不同的故事

【讨论】：