鸭子类型与静态类型相比有哪些优点？

Question

我正在对 Groovy 进行更多的研究和实验，并且我正在努力思考在 Groovy 中实现我在 Java 中不能/不做的事情的优缺点。 动态编程对我来说仍然只是一个概念，因为我已经深入了解静态和强类型语言。

Groovy 使我能够duck-type，但我无法真正看到其价值。 鸭子类型如何比静态类型更高效？ 在我的代码实践中我可以做哪些事情来帮助我掌握它的好处？

我问这个问题时考虑的是 Groovy，但我知道这不一定是 Groovy 问题，所以我欢迎来自每个代码营的答案。

Answer 1

这是一种鸭子类型可以节省工作量的场景。

这是一个非常简单的类，

class BookFinder {
    def searchEngine

    def findBookByTitle(String title) {
         return searchEngine.find( [ "Title" : title ] ) 
    }
}

现在进行单元测试：

void bookFinderTest() {
    // with Expando we can 'fake' any object at runtime.
    // alternatively you could write a MockSearchEngine class.
    def mockSearchEngine = new Expando()
    mockSearchEngine.find = {
        return new Book("Heart of Darkness","Joseph Conrad")
    }

    def bf = new BookFinder()
    bf.searchEngine = mockSearchEngine
    def book = bf.findBookByTitle("Heart of Darkness")
    assert(book.author == "Joseph Conrad"
}

由于缺少静态类型检查，我们能够用 Expando 替换搜索引擎。 通过静态类型检查，我们必须确保 SearchEngine 是一个接口，或者至少是一个抽象类，并创建它的完整模拟实现。 这是劳动密集型的，或者您可以使用复杂的单一用途模拟框架。 但鸭子类型是通用的，并且对我们有帮助。

由于鸭子类型，我们的单元测试可以提供任何旧对象来代替依赖项，只要它实现被调用的方法即可。

强调一下 - 您可以使用静态类型语言来完成此操作，并仔细使用接口和类层次结构。 但通过鸭子打字，你可以用更少的思考和更少的击键来完成它。

这是鸭子类型的优点。 这并不意味着动态类型是在所有情况下使用的正确范例。 在我的 Groovy 项目中，当我觉得有关类型的编译器警告会对我有所帮助时，我喜欢切换回 Java。

Answer 2

恕我直言，当您遵守某些约定（例如以一致的方式命名变量和方法）时，鸭子类型的优势就会被放大。 以 Ken G 为例，我认为读起来最好：

class SimpleResults {
    def mapOfListResults
    def total
    def categories
}

假设您在名为“calculateRating(A,B)”的某个操作上定义了一个合约，其中 A 和 B 遵守另一个合约。 在伪代码中，它会这样写：

Long calculateRating(A someObj, B, otherObj) {

   //some fake algorithm here:
   if(someObj.doStuff('foo') > otherObj.doStuff('bar')) return someObj.calcRating());
   else return otherObj.calcRating();

}

如果你想在 Java 中实现这个，A 和 B 都必须实现某种接口，其内容如下：

public interface MyService {
    public int doStuff(String input);
}

此外，如果你想概括你的计算评级的契约（假设你有另一个评分计算算法），您还必须创建一个接口：

public long calculateRating(MyService A, MyServiceB);

使用鸭子类型，您可以放弃您的接口，只依赖于运行时，A和B都会正确响应您的doStuff () 调用。 不需要特定的合同定义。 这可能对你有利，但也可能对你不利。

缺点是您必须格外小心，以保证您的代码在其他人更改时不会中断（即其他人必须了解方法名称和参数上的隐式约定）。

请注意，这在 Java 中尤其严重，因为 Java 的语法并不那么简洁（与 Scala 相比）例如）。 一个反例是 Lift 框架，他们说该框架的 SLOC 计数类似于 Rails，但测试代码行数较少，因为它们不需要在测试中实现类型检查。

Answer 3

这并不是说鸭子类型比静态类型更有效率，而只是不同而已。 使用静态类型，您始终需要担心数据的类型是否正确，而在 Java 中，它是通过转换为正确的类型来显示的。 使用鸭子类型，只要它有正确的方法，类型并不重要，因此它实际上消除了类型之间的强制转换和转换的许多麻烦。

Answer 4

对我来说，如果您将动态类型语言视为静态类型的一种形式，其中所有内容都继承自足够抽象的基类，那么它们并没有太大的不同。

正如许多人指出的那样，当你开始对此感到奇怪时，问题就会出现。 有人指出一个函数返回单个对象、集合或 null。 让函数返回特定类型，而不是多个类型。 单个函数与集合函数使用多个函数。

归根结底，任何人都可能写出糟糕的代码。 静态打字是一种很好的安全装置，但有时当你想感受风吹过头发时，头盔会妨碍你。

Answer 5

如果您使用 Haskell，静态类型没有任何问题，它具有令人难以置信的静态类型系统。 然而，如果您使用像 Java 和 C++ 这样的语言，它们的类型系统非常严重，那么鸭子类型绝对是一种改进。

想象一下尝试在 Java 中使用像“map”这样简单的东西（并且不，我的意思不是 数据结构）。 即使是泛型也得不到很好的支持。

Answer 6

有了TDD + 100% 代码覆盖率 + IDE 工具来不断运行我的测试，我不再需要静态类型了。 没有强类型，我的单元测试变得如此简单（只需使用映射来创建模拟对象）。 特别是，当您使用泛型时，您可以看到区别：

//Static typing 
Map<String,List<Class1<Class2>>> someMap = [:] as HashMap<String,List<Class1<Class2>>>

vs

//Dynamic typing
def someMap = [:]   

Answer 7

在您使用一段时间之前，要了解鸭子类型的价值有点困难。 一旦习惯了它，您就会意识到不必处理接口或不必担心某些东西到底是什么类型，这会给您带来多大的负担。

Answer 8

接下来，EMACS 和 vi 哪个更好？ 这是正在进行的宗教战争之一。

可以这样想：如果语言是静态类型的，任何正确的程序都将是正确的。 静态类型的作用是让编译器有足够的信息来在编译时而不是运行时检测类型不匹配。 如果您进行增量编程，这可能会很烦人，尽管（我认为）如果您清楚地思考您的程序，这并不重要； 另一方面，如果您正在构建一个非常大的程序，例如操作系统或电话交换机，有数十人、数百人或数千人在处理它，或者具有非常高的可靠性要求，那么让编译器能够为您检测一大类问题，而无需测试用例来执行正确的代码路径。

这并不是说动态类型是一个新的、不同的东西：例如，C 就是有效的动态类型，因为我总是可以将 foo* 转换为 bar*。 这只是意味着，当地址真正指向 foo* 时，作为 C 程序员，我有责任永远不要使用适合 bar* 的代码。 但由于大型程序的问题，C 开发了像 lint(1) 这样的工具，使用 typedef 增强了其类型系统，并最终在 C++ 中开发了强类型变体。 （当然，C++ 反过来又开发了围绕强类型的方法，包括各种类型的强制转换、泛型/模板以及 RTTI。

不过，还有一件事——不要将“敏捷编程”与“动态语言”混淆”。敏捷编程是关于人们在项目中协作的方式：项目能否适应不断变化的需求以满足客户的需求' 需要同时为程序员维护一个人性化的环境吗？这可以用动态类型语言来完成，而且通常是这样，因为它们可以提高生产力（例如，Ruby，Smalltalk），但它可以做到，并且已经成功做到了， C 甚至汇编程序 事实上，Rally Development 甚至使用敏捷方法（特别是 SCRUM）来进行营销和文档编写。 。

Answer 9

鸭子类型会削弱大多数现代 IDE 的静态检查功能，静态检查可以在您键入时指出错误。 有些人认为这是一个优势。 我希望 IDE/编译器尽快告诉我我做了一个愚蠢的程序员把戏。

我最近最喜欢的反对鸭子类型的论点来自 Grails 项目 DTO：

class SimpleResults {
    def results
    def total
    def categories
}

其中 结果 结果类似于 Map> 。 ，只能通过跟踪不同类中的方法调用来发现它，直到找到它的创建位置。 对于极度好奇的人来说，total 是 List 的大小总和，categories 是 的大小地图

最初的开发人员可能已经很清楚了，但是糟糕的维护人员（ME）在追踪这个问题时损失了很多头发。

Answer 10

许多关于鸭子打字的评论并没有真正证实这些说法。 不“不必担心”类型对于维护或使应用程序可扩展来说是不可持续的。 在我的上一份合同中，我确实有一个很好的机会看到 Grails 的运行，而且看起来真的很有趣。 每个人都对能够“创建应用程序”并开始工作所获得的收益感到高兴 - 遗憾的是，这一切都在后端赶上了你的脚步。

Groovy 对我来说似乎也是如此。 当然，你可以编写非常简洁的代码，并且在我们如何使用属性、集合等方面肯定有一些很好的糖分……但是不知道来回传递的到底是什么的成本只会变得越来越糟。 有时您会挠头，想知道为什么该项目变成了 80% 的测试和 20% 的工作。 这里的教训是“更小”并不意味着“更易读”的代码。 抱歉，各位，它的逻辑很简单 - 您必须直观地了解越多，那么理解代码的过程就会变得越复杂。 这就是为什么 GUI 多年来不再变得过于标志性——看起来确实很漂亮，但发生的事情并不总是显而易见的。

该项目的人们似乎很难“确定”所学到的经验教训，但是当您有方法返回 T 类型的单个元素、T 数组、ErrorResult 或 null 时……它就变得相当明显了。

然而，使用 Groovy 为我做了一件事 - 很棒的计费时间！