服务层和简化类
我有一个关于我的代码结构以及如何保持类简单的问题。我正在努力简化C＃项目的服务层。大部分代码没有考虑到OOP实践，并且有200多行的方法很少有类。我已经开始提取出更小的方法，但对如何做到这一点有一个快速查询。服务层和简化类
作为一个例子，我有一个方法来检索特定于客户的文件目录，然后检查它们是否存在，如果它们不存在则创建它们，最后返回一个带有这些目录列表的对象。我想坚持不使用私有方法的原则，并将其提取到新类中，尽管传统的我会创建私有方法来检查目录是否存在，另一个用于创建它们，第三个用于检索文件夹名称并返回对象和公共方法使用单个方法按顺序调用所有这些方法。
我应该为这些私有方法中的每一个创建新的类吗？如果是的话，他们是否都需要一个接口？或者让他们全部公开并从别处打电话给他们？
在此先感谢！
简答：你不应该做那些事情。
如果你想从面向对象的角度来处理这个问题，那么暂时忘记这些方法正在做什么。想想代码约为。您只提到“客户”作为可能的“业务”相关的事情。试着想出其他商业相关的东西。这些文件是什么？报告？ ActivityLogs？消息？ CreditReports :)？
问题是，面向对象并不是仅仅在不同类中有方法。类别和方法必须具有一定的商业意义。如果他们没有任何意义，那么没有真正的理由让他们摆在首位！
由此可见，“StorageManager”，“StorageUtil”等类似的东西不应该存在，因为它根本没有任何商业意义。
因此，从找出应用程序约为（事情）开始，然后您可以将某些职责移动到适当的位置。
谢谢你的回复。这使我从不同的角度看待该节目。我可以将商业逻辑应用于此，因为我正在处理订单文件。所以如果我有一个与处理订单文件相关的类，那么使用私有方法还是创建与订单文件处理的一部分有关的新类会更好。最后，那些也需要接口.....我假定在库和服务层中的所有东西都应该有接口。 – Boggot
我怀疑这个问题将被关闭。无论如何，下面是我如何处理它：在具有专用文件存储的应用程序中，我倾向于创建一个'StorageManager'类，它负责为我希望使用的每个文件路径提供服务。它的设置方式是，如果返回的文件路径不存在，则自动创建所有返回的文件路径。如果您有多个存储（使用不同的文件夹结构），我倾向于从'StorageManager'继承并覆盖路径生成。不知道这种方式是否客观是最好的方式，但我觉得这是一种干净的方法。 – Flater