使用SOLID原则时，开发人员的可发现性是否成问题？

我从事一系列商务应用程序，在这些应用程序中，所有其他开发人员都习惯于使用基本的CRUD应用程序，或者只专注于创建漂亮/功能强大的界面，因此，我得到了很多帮助。

“通过我们使用的方式，员工将拥有您可能对员工所做的所有事情。” 这是真的。那个“班级”有成千上万的代码行，您在那里可以与一名员工一起做的任何事情。甚至更糟的是，有一张员工数据表，每个开发人员都想出了如何在事件处理程序中做他们想做的事情。

关于这种方法的所有坏事都是对的，但是至少使用雇员的开发人员可以在不查阅其他文件的情况下，弄清楚如何使雇员参加健康计划，加薪，解雇，雇用，调动等。经理和其他所有主要想法。或者，如果他们使用员工其他需要的数据表，则可以做他们想要的事情。

是的，有很多重复的代码。是的，这是非常脆弱的代码。是的，测试比必要的困难得多。是的，不断变化的功能导致恐惧，而复制粘贴由于这种方法是很自然的。

但是他们至少可以通过创建一个类来发现可用的东西，或者他们可以做他们需要做的事情而不必了解接口，抽象类，具体类等之间的区别。他们不必搜索任何东西由intellisense返回的方法，或知道数据所在的表。

我已经用谷歌搜索/搜索甚至是yahoo！d，但是我没有发现任何对此问题的认可。

因此，也许没有问题，而我只是想念一些东西。我竭尽全力试图找到一个解决方案，使不执行实际行为/设计的开发人员可以轻松地发现如何做某事，而不必引用任何外部文档或扫描各个组件/中的类名。项目，寻找听起来可行的方案。

我唯一能想到的就是这些，因为缺少更好的名称，“ Content Class Table”不执行任何操作以返回实际的类（实际上，大多数是接口，但它们不是了解其他开发人员可以用来执行所需实际任务的区别甚至是关心。仍然会出现真正的大类，但其中几乎没有行为。

有没有更好的方法不需要对SOLID的实际实现发生在中间层的深入了解？

基本上，我要问的是有一种方法可以允许CRUD类型的开发人员继续在非常复杂的系统中成为CRUD开发人员。

看来您所描述的（即Employee类具有您可以与员工一起执行的所有可能的代码）是一种非常常见的模式，我个人已经看到了很多。在我不了解之前，我已经编写了一些代码。

它从一个类开始，该类应该表示具有可管理方法集的单个实体，但由于每个功能和每个发行版不断向同一个类添加越来越多的内容，因此变成了噩梦般的维护。这确实违反了SOLID原则，即您应该编写一次类，并避免一遍又一遍地修改它的冲动。

前一段时间（在我发现其他人推广的设计模式或SOLID之前），我决定为我的下一个项目进行一些改动。我在服务器上工作，该服务器充当了两个非常大的平台之间的接口。最初，只需要同步配置，但是我可以看到这对于许多其他功能而言是合乎逻辑的。

因此，我没有写一个暴露方法的类，而是写了代表方法的类（原来是GoF的“命令”模式）。我的所有主要应用程序类不再是为客户端做的工作，而是成为持久性状态持有者，并且它们的长度变得短得多。每次我必须向服务本身添加新的接口方法时，我都会简单地创建一个具有Execute（）方法的新类，该方法启动所有操作。如果多个命令具有某些共同点，则它们是从共同的基类派生的。最终，该事物具有70多个不同的命令类，并且整个项目仍然非常易于管理，并且实际上很高兴进行。

您的“ TOC班”与我所做的相差不远。我有一个抽象工厂（GoF），它负责实例化命令。在工厂类内部，我将大多数细节隐藏在基类和ATL风格的宏后面，因此当程序员不得不添加或查找请求时，他们进入了那里，所看到的只是：

BEGIN_COMMAND_MAP()
    COMMAND_ENTRY( CChangeDeviceState )
    COMMAND_ENTRY( CSetConfiguration )
    ....
END_COMMAND_MAP()

作为替代（或补充），您可以将所有实际命令类放入一个单独的命名空间中，这样当人们进行编码并需要运行某些内容时，他们只需键入命名空间名称，Intellisense就会列出您已定义的所有命令。然后，每个命令都包含所有用于确定确切输入和输出参数的get / get / set方法。

您还可以探索外观（GoF）模式的使用。与其向您的CRUD工程师公开1000多个类。将它们全部隐藏在只暴露所需内容的单个类后面。我仍然坚持将每个“动作”作为自己的类，但是您的Facade类可以具有实例化每个动作的方法，并且通过Intellisense，他们可以立即看到可用的方法。或者让Facade有实际的方法，但在内部使它们实例化命令，将它们排队，等待响应。然后返回，就像进行常规方法调用一样。

（*）我不想涉及太多细节，但是实际上我有“ Command”和“ CommandHandler”类集。这将管理/排队/序列化输入/输出参数的职责与实际“处理”那些命令的类分开。

可能是个问题。尤其是如果您的名字不好。但是有许多解决方法，而不必求助于复杂的类。哎呀，使用太多方法的类可能同样难以使用Intellisense进行导航。

尝试使用名称空间（C＃）或包（Java）或您的语言所具有的任何类似概念（我将它们全部称为名称空间）来简化问题。

以您的公司名称开头。这就将Intellisense限制为仅由您自己编写的名称空间。然后，如果您有多个应用程序，请使用名称空间的第二部分来拆分它们。包括Core命名空间，用于跨应用程序存在的内容。下一步将功能分解为功能类型。等等。

如果正确执行此操作，最终将获得非常容易发现的项目。

以您的示例为例，如果需要用户验证，请键入“ MyCo”。它为我提供了应用程序名称空间的列表。我知道我们所有的应用程序中都使用了User数据库，因此我键入“ Core”。然后我得到功能类型的列表。其中之一就是“验证”，因此这似乎是一个显而易见的选择。在Validation中，有“ UserValidator”及其所有功能。

碰巧的是，对于我经常使用的东西，我会很快记住名称或至少是约定。因为我对验证规则做了很多更改，所以我将知道所有验证类都称为FooValidator，其中Foo是表的名称。因此，我实际上不需要遍历名称空间。我只需要输入UserValidator并让IDE完成其余的工作即可。

但是对于我不记得的事情，找到它们仍然很容易。然后，我可以删除名称空间前缀。

由于您将他们视为基本的“ CRUD”开发人员，因此我们假设您认为他们不是很好。我们不知道这是否意味着他们也不了解您的业务领域。如果他们了解领域，则这些类对他们来说应该是有意义的。知道已经构建了几个类之​​后，他们应该首先看一看，然后再问一遍，考虑从头开始构建作为第三种选择。

至于仅仅通过查看类就知道如何自动知道如何使用/重用一个类，这应该不是第一次。您将需要记录文档，并可能需要通过培训或在代码审查过程中提供其他解释。

许多API和开源项目都提供文档，代码示例和其他说明。您可能不需要与用户一样友好，但是没有解决的办法。教好他们。