blocks|key|1496724|text|我认为ADT是对继承的补充。它们都允许您创建可扩展代码，但可扩展性的工作方式是不同的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1496725|1496726|ADTs使您可以轻松地添加用于处理现有类型的新功能|unordered-list-item|offset|length|style|BOLD|1496727|+|1496728|您可以轻松地添加使用ADT的新函数，ADT具有一组固定的case+|1496729|另一方面，添加新case需要修改所有函数|1496730|1496731|​|1496732|1496733|Inheritance使添加新类型变得很容易当您具有固定的功能时|1496734|您可以轻松地创建继承的类并实现固定的虚函数集|1496735|另一方面，添加新的虚函数需要修改所有继承的虚函数|1496736|1496737|1496738|1496739|面向对象的世界和函数世界都开发了允许另一种类型的可扩展性的方法。在Haskell中，你可以使用类型类，在ML/OCaml中，人们可以使用函数字典或(?)函数来获得继承风格的可扩展性。另一方面，在OOP中，人们使用访问者模式，这本质上是一种获得类似ADT的东西的方法。|1496740|通常的编程模式在OOP和FP中是不同的，因此当您使用函数式语言编程时，您编写代码的方式更需要函数式可扩展性(在OOP中也是如此)。在实践中，我认为有一种语言可以让你根据你试图解决的问题同时使用这两种风格，这是很棒的。|1496741|entityMap^0|0|0|0|4|0|0|0|0|0|0|0|0|B|1|1|1|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1A|8|@$F|1B|G|1C|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1D|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|1E|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|1F|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1H|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|1J|8|@$F|1K|G|1L|H|I]]|9|@]|A|$]]|$1|V|3|W|5|E|7|1M|8|@]|9|@]|A|$]]|$1|X|3|Y|5|E|7|1N|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|11|3|R|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1R|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1S|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|17|$]]

I think that ADTs are complementary to inheritance. Both of them allow you to create extensible code, but the way the extensibility works is different:

<ul>
<li>ADTs make it easy to add new functionality for working with existing types

<ul>
<li>You can easily add new function that works with ADT, which has a fixed set of cases</li>
<li>On the other hand, adding new case requires modifying all functions </li>
</ul></li>
<li>Inheritance makes it easy to add new types when you have fixed functionality 

<ul>
<li>You can easily create inherited class and implement fixed set of virtual functions</li>
<li>On the other hand, adding a new virtual function requires modifying all inherited classes</li>
</ul></li>
</ul>

Both object-oriented world and functional world developed their ways to allow the other type of extensibility. In Haskell, you can use typeclasses, in ML/OCaml, people would use dictionary of functions or maybe (?) functors to get the inhertiance-style extensibility. On the other hand, in OOP, people use the Visitor pattern, which is essentially a way to get something like ADTs.

The usual programming patterns are different in OOP and FP, so when you're programming in a functional language, you're writing the code in a way that requires the functional-style extensibility more often (and similarly in OOP). In practice, I think it is great to have a language that allows you to use both of the styles depending on the problem you're trying to solve.

blocks|key|750686|text|Tomas+Petricek的基本原理是完全正确的；您可能还想看看Phil+Wadler关于“表达式问题”的文章。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|750687|我们中的一些人更喜欢代数数据类型而不是继承还有另外两个原因：|750688|750689|使用代数数据类型，编译器可以(并且确实)告诉你是忘记了大小写还是大小写是多余的。当对事物的操作比对事物种类的操作多得多时，这种能力特别有用。(例如，比代数数据类型多得多的函数，或者比面向对象构造函数多得多的方法。)在面向对象的语言中，如果您在子类中遗漏了一个方法，编译器将无法判断这是不是一个错误，或者您是否打算继承超类方法unchanged.|unordered-list-item|750690|This+one更加主观:许多人已经注意到，如果正确和积极地使用继承，算法的实现可以很容易地分散到六个类中，即使有一个很好的类浏览器，也很难理解程序的逻辑(数据流和控制流)。没有一个好的类浏览器，你就没有机会。如果你想看一个很好的例子，可以尝试在Smalltalk中实现bignums，在溢出时自动故障转移到bignums。这是一个很好的抽象，但是这种语言使得实现很难理解。使用代数数据类型上的函数，算法的逻辑通常都在一个地方，或者如果它被拆分，它被拆分成具有易于理解的契约的函数。|750691|750692|750693|附言:你在读什么？我不知道有哪个负责任的人会说"ADTs好，OO坏“。|750694|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|T|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|W|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|O|$]]

Tomas Petricek has got the fundamentals exactly right; you might also want to look at Phil Wadler's writing on the "expression problem".

There are two other reasons some of us prefer algebraic data types over inheritance:

<ul>
<li>Using algebraic data types, the compiler can (and does) tell you if you have forgotten a case or if a case is redundant. This ability is especially useful when there are many more operations on things than there are kinds of thing. (E.g., many more functions than algebraic datatypes, or many more methods than OO constructors.) In an object-oriented language, if you leave a method out of a subclass, the compiler can't tell whether that's a mistake or whether you intended to inherit the superclass method unchanged.</li>
<li>This one is more subjective: many people have noted that if inheritance is used properly and aggressively, the implementation of an algorithm can easily be smeared out over a half a dozen classes, and even with a nice class browser at can be hard to follow the logic of the program (data flow and control flow). Without a nice class browser, you have no chance. If you want to see a good example, try implementing bignums in Smalltalk, with automatic failover to bignums on overflow. It's a great abstraction, but the language makes the implementation difficult to follow. Using functions on algebraic data types, the logic of your algorithm is usually all in one place, or if it is split up, its split up into functions which have contracts that are easy to understand.</li>
</ul>

<hr>

P.S. What are you reading? I don't know of any responsible person who says "ADTs good; OO bad."

blocks|key|2464065|text|根据我的经验，人们通常认为大多数面向对象语言实现的继承“不好”的地方不是继承本身，而是子类修改超类(方法覆盖)中定义的方法的行为，特别是在存在可变状态的情况下。这是真正的最后一部分，这是踢球。大多数面向对象语言将对象视为“封装状态”，这等同于允许对象内部状态的猖獗变化。因此，例如，当超类希望某个方法修改私有变量，但子类覆盖该方法来做完全不同的事情时，就会出现问题。这可能会引入编译器无能为力的细微bug。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2464066|请注意，在Haskell的子类多态性实现中，不允许使用可变状态，因此您不会遇到这样的问题。|2464067|另请参见this+objection到子类型的概念。|2464068|entityMap|0|LINK|mutability|MUTABLE|url|http://apocalisp.wordpress.com/2009/08/27/hostility-toward-subtyping/^0|17|6|1T|A|0|0|4|E|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@]|D|@$9|Y|A|Z|1|10]]|E|$]]|$1|J|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

In my experience, what people usually consider "bad" about inheritance as implemented by most OO languages is not the idea of inheritance itself but the idea of subclasses modifying the behavior of methods defined in the superclass (method overriding), specifically in the presence of mutable state. It's really the last part that's the kicker. Most OO languages treat objects as "encapsulating state," which amounts to allowing rampant mutation of state inside of objects. So problems arise when, for example, a superclass expects a certain method to modify a private variable, but a subclass overrides the method to do something completely different. This can introduce subtle bugs which the compiler is powerless to prevent.

Note that in Haskell's implementation of subclass polymorphism, mutable state is disallowed, so you don't have such issues.

Also, see <a href="http://apocalisp.wordpress.com/2009/08/27/hostility-toward-subtyping/" rel="nofollow noreferrer">this objection</a> to the concept of subtyping.

blocks|key|748380|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|748381|我是一个长期的OO程序员和函数式编程新手。从我的经验来看，代数数据类型对我来说只是一个继承的特例，你只有一个层次结构，并且超类不能扩展到模块之外。|blockquote|748382|748383|748384|您正在描述闭合和类型，这是代数数据类型中最常见的形式，如F#和Haskell中所示。基本上，每个人都同意它们是类型系统中的一个有用的功能，主要是因为模式匹配使得通过形状和内容分析它们变得很容易，还因为它们允许穷举和冗余检查。|748385|但是，还有其他形式的代数数据类型。传统形式的一个重要限制是它们是闭合的，这意味着以前定义的闭合和类型不能用新类型构造函数来扩展(这是称为“表达式问题”的更一般问题的一部分)。OCaml的多态变体允许开放和闭合sum类型，特别是sum类型的推断。相比之下，Haskell和F#无法推断sum类型。多态变体解决了表达式问题，它们非常有用。事实上，有些语言完全建立在可扩展的代数数据类型上，而不是封闭的sum类型上。|748386|在极端情况下，你也有像Mathematica这样的语言，“一切都是表达式”。因此，类型系统中的唯一类型形成了一个微不足道的“单例”代数。这是“可扩展的”，因为它是无限的，并且，再一次，它在完全不同的编程风格中达到顶峰。|748387|748388|所以我的问题(可能很愚蠢)是:如果ADT只是继承的一种特殊情况(同样，这个假设可能是错误的；请在这种情况下纠正我)，那么为什么继承会受到所有的批评，而ADT会得到所有的赞扬？|748389|748390|748391|我相信你指的是实现继承(即覆盖父类的功能)，而不是接口继承(即实现一致的接口)。这是一个重要的区别。实现继承通常是令人讨厌的，而接口继承通常是受人喜爱的(例如，在F#中，它具有有限形式的ADT)。|748392|你真的想要ADT和接口继承。像OCaml和F#这样的语言同时提供了这两种功能。|748393|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|W|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|X|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|Y|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|10|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|11|7|@]|8|@]|9|$]]|$1|J|3|K|4|5|6|12|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|13|7|@]|8|@]|9|$]]|$1|M|3|N|4|C|6|14|7|@]|8|@]|9|$]]|$1|O|3|-4|4|5|6|15|7|@]|8|@]|9|$]]|$1|P|3|-4|4|5|6|16|7|@]|8|@]|9|$]]|$1|Q|3|R|4|5|6|17|7|@]|8|@]|9|$]]|$1|S|3|T|4|5|6|18|7|@]|8|@]|9|$]]|$1|U|3|-4|4|5|6|19|7|@]|8|@]|9|$]]]|V|$]]

<blockquote>
 I am a long time OO programmer and a functional programming newbie. From my little exposure algebraic data types only look like a special case of inheritance to me where you only have one level hierarchy and the super class cannot be extended outside the module.
</blockquote>

You are describing closed sum types, the most common form of algebraic data types, as seen in F# and Haskell. Basically, everyone agrees that they are a useful feature to have in the type system, primarily because pattern matching makes it easy to dissect them by shape as well as by content and also because they permit exhaustiveness and redundancy checking.

However, there are other forms of algebraic datatypes. An important limitation of the conventional form is that they are closed, meaning that a previously-defined closed sum type cannot be extended with new type constructors (part of a more general problem known as "the expression problem"). OCaml's polymorphic variants allow both open and closed sum types and, in particular, the inference of sum types. In contrast, Haskell and F# cannot infer sum types. Polymorphic variants solve the expression problem and they are extremely useful. In fact, some languages are built entirely on extensible algebraic data types rather than closed sum types.

In the extreme, you also have languages like Mathematica where "everything is an expression". Thus the only type in the type system forms a trivial "singleton" algebra. This is "extensible" in the sense that it is infinite and, again, it culminates in a completely different style of programming.

<blockquote>
 So my (potentially dumb) question is: If ADTs are just that, a special case of inheritance (again this assumption may be wrong; please correct me in that case), then why does inheritance gets all the criticism and ADTs get all the praise?
</blockquote>

I believe you are referring specifically to implementation inheritance (i.e. overriding functionality from a parent class) as opposed to interface inheritance (i.e. implementing a consistent interface). This is an important distinction. Implementation inheritance is often hated whereas interface inheritance is often loved (e.g. in F# which has a limited form of ADTs).

You really want both ADTs and interface inheritance. Languages like OCaml and F# offer both.

I am a long time OO programmer and a functional programming newbie. From my little exposure algebraic data types only look like a special case of inheritance to me where you only have one level hierarchy and the super class cannot be extended outside the module.

So my (potentially dumb) question is: If ADTs are just that, a special case of inheritance (again this assumption may be wrong; please correct me in that case), then why does inheritance gets all the criticism and ADTs get all the praise?

Thank you.

Why ADTs are good and Inheritance is bad?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我是一个长期的面向对象程序员和函数式编程新手。从我的经验来看，代数数据类型对我来说只是一个继承的特例，你只有一个层次结构，并且超类不能扩展到模块之外。所以我的问题(可能很愚蠢)是:如果ADT只是继承的一种特殊情况(同样，这个假设可能是错误的；请在这种情况下纠正我)，那么为什么继承会受到所有的批评，而ADT会得到所有的赞...

问为什么ADT是好的，而继承是坏的？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么ADT是好的，而继承是坏的？EN