这是非常基础的内容，但我想说一下。我发现我从来不能确定我把大类分成较小类的方法是否会使事情更容易维护还是更难以维护。我对设计模式有所了解，但不是很深入，并且也熟悉面向对象设计的概念。除了所有花哨的规则和指南，我正在寻求您的建议，针对一个非常简单的场景，希望您能告诉我什么是我所不知道且缺少经验的东西，例如：" ...由于某种设计，这将使它更加困难" 等等。
假设您需要编写一个基本的“文件阅读器/文件写入器”类来处理特定类型的文件。让我们把这个文件称为YadaKungFoo文件。YadaKungFoo文件的内容与INI文件基本相似，但存在细微差异。
它们都有各自的部分和值：
[Sections]
Kung,Foo
Panda, Kongo
[AnotherSection]
Yada,Yada,Yada
Subtle,Difference,Here,Yes
[Dependencies]
PreProcess,SomeStuffToPreDo
PreProcess,MoreStuff
PostProcess,AfterEight
PostProcess,TheEndIsNear
PostProcess,TheEnd
好的，这可以产生3个基本类：
public class YadaKungFooFile
public class YadaKungFooFileSection
public class YadaKungFooFileSectionValue
后两个类本质上只是带有 ToString() 覆盖的数据结构，用一些泛型列表存储值的字符串列表。这足以实现 YadaKungFoo 文件保存功能。
随着时间推移，YadaYadaFile 开始增长。包括 XML 等多种格式的几个重载版本，并且文件开始向 800 行左右发展。 现在真正的问题：我们想要添加一个功能来验证 YadaKungFoo 文件的内容。首先想到的当然是添加：
var yada = new YadaKungFooFile("C:\Path");
var res = yada .Validate()
我们完成了（我们甚至可以从构造函数调用该方法）。问题是验证过程相当复杂，使得类变得非常庞大，因此我们决定创建一个新类，如下所示：
var yada = new YadaKungFooFile("C:\Path");
var validator = new YadaKungFooFileValidator(yada);
var result = validator.Validate();
很明显，这个例子非常简单、琐碎而且微不足道。上述两种方式都可能没有太大的区别，但我不喜欢的是：
- 按照这种设计，YadaKungFooFileValidator类和YadaKungFooFile类似乎耦合度非常高。一个类的更改可能会触发另一个类的变化。
- 我知道，“Validator”、“Controller”、“Manager”等短语表示的类关注其他对象的状态，而不是自己的“业务”，因此违反了关注点分离原则和消息发送原则。
总之，我认为我没有足够的经验来理解一个设计为什么不好、在什么情况下它并不重要以及哪个问题更加重要：小型类还是更具内聚性的类。它们似乎是相互矛盾的要求，但也许我错了。也许验证器类应该是一个组合对象？
实质上，我正在寻求对上述设计可能产生的利弊的评论。有什么可以做得不同吗？（基于FileValidator类、FileValidator接口等）。考虑到YadaKungFooFile功能随着时间的推移而不断增长。