拥有大量代码，需要某种原则来使其易于管理。 SOLID是更常用的原理集之一。即使解决了问题，它似乎也会创建另一个。
随着代码库的变化，遵循SOLID模型将大大增加类，接口和注入的数量。
第一个问题是，当我找到一个对象时，并不总是很清楚该对象或该如何使用它可以做什么。
例如，如果我想显示它，通常我只需要键入对象并点击点，列表就会显示我可以使用该对象做什么。使用SOLID，将有另一个类“某处”处理显示样式。我如何找到这个班？我怎么知道它甚至存在？引用听起来像是要走的路，但它可能会显示超过100个引用，并且其中很多可能与该类的功能无关。
第二问题（可能不是SOLID问题）是，在使用注入时，可能不清楚在特定流程中实际执行的代码是什么。注入使用接口，并且可以有多个类实现此接口。因此，在研究特定流并遇到注入时，我们需要深入了解真正注入的对象，以了解执行了哪些代码。在大型代码中，这可能会耗费大量时间。
我以错误的方式使用SOLID还是要解决问题？
答案 0 :(得分：0)
可能会有更多的代码，并且可以肯定的是，每个实现都会花费更多的钱，例如，除了修改特定的服务之外，您还必须创建一个与现有基础结构交互的新服务，并且如果您进行修改，这也将影响其他模块化部分，因此您必须重构所有其他相关接口，而无需耦合模型，服务等。
模块/服务必须交互，但不必耦合。解耦的零件越多，花费的时间（精力/精力）就越多。第一个问题是，您对一个真正的强大SOLID应用程序有多少兴趣，您对实现它有什么好处？
无论如何，当你说：
引用听起来很像，但它可能会显示超过100个引用，并且其中很多可能与该类的功能无关。
这似乎与I原则相反：接口隔离原则
因为您应该拥有更具体，更小的接口，而不是胖接口。但可以肯定的是，您可能会有更多的嵌套调用（例如，通过接口交互服务）
您的第二个问题也是：
因此，在调查特定流并遇到注入时，我们需要深入了解实际注入了什么对象才能知道执行了哪些代码
与问题1相关的问题。因为使用更小和更具体的界面和特定的流程，您应该了解所涉及的代码，并且它比非SOLID应用程序还要清晰