我正在开发一款iOS应用，我们根据需要为每位客户提供不同的二进制文件。客户可能想要更改所有颜色，图标和文本。我们可以通过白色标签流程来实现。但问题是，当他们要求不同的行为时，例如，删除登录屏幕并使其可选择登录。
我认为我们可以使用依赖注入，并在需要时为每个客户使用不同的处理程序。例如，我们可以使用LoginHandler1和LoginHandler2，它们都实现ILoginHandler并从UIViewController继承。
然而，使用依赖注入成本很高，它会减慢应用程序的速度，因为与正常实例化相比，解析成本很高。
另一种方法是在应用程序中定义所有这些行为，并在plist文件中启用/禁用它们。喜欢“登录是可选的吗？是/否”
有什么建议吗？
由于
答案 0 :(得分：1)
您应该在合成根中预先创建整个对象图。只要你的构造函数没有做任何实际工作，对象创建和构造函数注入就不应该花费太多时间。
话虽如此，有时在应用程序开始时创建整个对象图形可能需要比可接受的时间更长的时间。在这些情况下，您可以使用lazy-loading将昂贵的初始化推迟到以后 - ，同时仍然在合成根中创建对象。
马克·西曼在这里更详细地描述了这种方法：Compose object graphs with confidence。
答案 1 :(得分：1)
我认为我们可以使用依赖注入，并在需要时为每个客户使用不同的处理程序。
你认为没错。灵活性是人们使用DI的主要原因之一。
然而，使用依赖注入成本很高，它会减慢应用程序的速度，因为与正常实例化相比，解析成本很高。
它真的不花那么多钱。你自己尝试过吗？除非有问题的对象（即被注入的对象）实例化非常昂贵，否则你没有真正的理由远离DI和Inversion Of Control。另外，正如@Lilshieste上面提到的那样，预先创建对象图（请参阅AppDelegate）可能会使问题变得更少。
这里描述了一种很好的方法： http://cocoapatterns.com/passing-data-between-view-controllers/和http://cocoapatterns.com/ios-view-controller-transitions-mediator-pattern/
另一种方法是在应用程序中定义所有这些行为，并在plist文件中启用/禁用它们。喜欢“登录是可选的吗？是/否”
虽然不那么“优雅”，但这个解决方案非常有用，特别是如果项目在类和VC的数量方面不是很大。如果应用程序代码已经布局并且引入主要设计更改会要求进行大量重构，那么它也是最容易实现的。
始终根据手头的任务采取行动，很少有解决软件设计问题的单一解决方案。