什么时候C#类没有方法设计不好？

Question

什么时候没有方法设计不好？

从我所读到的,没有方法(即没有行为)(AKA哑类)的类是糟糕的设计,数据传输对象(DTO)除外.这是因为DTO的目的是减少将数据传输到远程接口(本地DTO)时的开销.关于DTO和普通老类对象(POCO VS DTO)似乎存在一些争论,并且对贫血设计(贫血模型领域)的争论也在进一步展开.

那么,在有问题的哑类是本地对象(即不是用于传输数据)的情况下,你通常更好地重构哑类的属性并将它们实现为集合(例如Dictionary)？引用Bill K(如何为具有可扩展属性的资源编写DAO),"如果您使用了对象,请使用哈希表.对于属性名称,使用键,对于属性值,请使用哈希表中的值."

我在设计这个哑课时的想法是构图.另一个类由多个哑类对象(即哑类对象的集合)组成.我的想法错了吗？如果我要将哑类实现为集合,我将拥有一组属性的集合.

我对收藏品等收藏品的理解也很差.是否有一些指导原则来平衡这些明显的糟糕设计选择？

一如既往,任何见解或指导都值得赞赏.

关心香农

Answer 1

如果一个类没有逻辑,那么这将被视为数据结构.对于是否使用泛型集合与类型的问题,我会选择创建类型,因为它们的表现力.

以下面的例子为例.

var employee = new Dictionary<string, object>();
employee["FirstName"] = "Steve";
employee["LastName"] = "McQueen";
employee["DOB"] = new DateTime(1942, 1, 5);
employee["Salary"] = 215000m;

在这里你有问题

• 正在Stringly类型化
• 无法在"员工"中实施逻辑
• 不可能是不可改变的
• 无法重构

与此形成鲜明对比.

var employee = new Employee {
    FirstName = "Steve",
    LastName = "McQueen",
    DOB = new DateTime(1942, 1, 5),
    Salary = 215000m
};

你得到了好处

• 能够找到员工的参考
• 子类员工
• 重构员工(重命名DOB,以DateOfBirth无需做搜索和替换)
• 使属性不可变
• 编译时检查
• 如果需要,添加域逻辑
• 可以施加不变量

虽然这样做的一个缺点是你必须定义一个类,这意味着更多的打字,虽然我觉得它的好处大大超过了成本.

要详细说明上面的示例,假设您从返回员工的存储库中编写了一个方法.

var employee = employeeRepository.GetById(25);

如果employee在这个例子中是字典,我就没有Intellisense知道员工有哪些属性,更不用说他们的类型了,@ HighCore的评论也说明了这一点.确定这一点的唯一方法是

• 阅读文档(可能是过时的或不准确的)
• 执行方法并使用调试器进行检查(浪费时间,可能无法在每个场景中执行)

在持久化的情况下employee,字典遇到了相同的陷阱,现在你处于希望你刚刚执行的方法返回有意义的错误消息的危险.