过多的抽象？后续

引言

我问了一个问题，关于如何知道你的代码中抽象是否过多？以及更多的抽象是否意味着更好的设计？我承诺会写一篇后续文章，给出我谦逊的看法。所以，开始吧...

作为一名架构师，我经常使用抽象。它允许我隐藏实现细节并为我的消费者创建 API。此外，它使我能够在项目的后期阶段根据需要更改实现，当然，它也使代码更易于测试。 抽象的另一个好处是，它们解耦了我们编写的代码，这是一件好事。但正如所有美好的事物一样，它也可能被滥用。

我曾经在为客户提供架构咨询时说过这样一句话：“抽象过多会让你崩溃”。我的意思是，由于我们可以抽象一切，我们需要掌握何时使用这种方法的“感觉”。

在客户的代码中，存在多层抽象，这些抽象提供的细节更少，或者接口与它们试图抽象的内容相同。在这种情况下，我更倾向于遵循 KISS 原则，并删除一些抽象。现在，解决方案更清晰、更易读，并且减少了不必要的抽象。

客户的例子表明，即使抽象是一种好的做法，你也应该理解在哪里应用它们。例如，抽象你的基础设施是一个非常好的做法。可以查看 Enterprise Library 或 Spring.NET 代码，了解如何利用抽象。另一方面，为数据传输对象 (DTO) 创建一个抽象其属性的接口，是我更愿意避免的。原因是 DTO 旨在作为没有行为的数据持有者。如果我抽象了属性，我将无法获得任何好处，因为在大多数情况下，实现将只是一个 getter 和一个 setter，仅此而已。这两个例子正是当我写到你应该理解在哪里应用抽象时所表达的意思。

总而言之，有时我们在代码中使用过多的抽象。如果一个抽象没有增加任何价值，你不应该创建它，因为它会使你的代码变得复杂。没有一个指南针可以告诉你何时需要抽象，或者何时你创建了太多的抽象。这就是为什么我从一个简单的实现开始，然后重构我的代码并创建所需的抽象。最后声明一下，更多的抽象并不意味着更好的设计。