Question

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

从我所读到的，没有方法（即没有行为）（AKA哑类）的类是糟糕的设计，数据传输对象（DTO）除外。这是因为DTO的目的是减少将数据传输到远程接口（Local DTO）时的开销。关于DTO和普通老类对象（POCO VS DTO）似乎存在一些争论，并且进一步讨论贫血设计（Anemic Model Domain）。

那么，在有问题的哑类是本地对象（即不是用于传输数据）的情况下，你通常更好地重构哑类的属性并将它们作为集合（例如Dictionary）实现？引用Bill K（How can i write DAOs for resources with extensible properties）， “如果您使用了对象，请使用哈希表。对于属性名称，使用键，对于属性值，请使用哈希表中的值。”

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

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

一如既往，任何见解或指导都会受到赞赏。

此致香农

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 Typed
无法在“员工”
不可能成为immutable
无法重构

与此对比。

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的情况下，字典遇到了相同的陷阱，现在你处于希望你刚刚执行的方法返回有意义的错误消息的危险。

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

1 个答案: