wuxuan
2023 年12 月 31 日 01:35
1
源自 此演讲 中的此页：
Babara Liskov 论文：Programming with Abstract Data Types
圆与椭圆问题 wiki 页 开头简介：
The circle–ellipse problem in software development (sometimes called the square–rectangle problem ) illustrates several pitfalls which can arise when using subtype polymorphism in object modelling . The issues are most commonly encountered when using object-oriented programming (OOP). By definition, this problem is a violation of the Liskov substitution principle , one of the SOLID principles.
The problem concerns which subtyping or inheritance relationship should exist between classes which represent circles and ellipses (or, similarly, squares and rectangles ).
duzc21
2023 年12 月 31 日 04:43
2
在我看来，这是一个应用领域的问题。讨论这个问题应该在具体应用场景中讨论。在编程语言中，至少包含语法和标准库2个方面，语法层面应该不涉及这种分类问题，在标准库层面可能会遇到。
我在学校学到的“圆是特殊的椭圆”、“正方形是特殊的长方形”这种说法。但 “特殊”在编程领域对应的词语是什么？ 是 实例化、满足特定要求的值、还是 子类？
分类问题是系统工程的一部分，一个事物从不同角度和层面去观察，得到的分类结果可能也是不同的。比如 人，可以分为男人和女人，也可以分为成年人和未成年人，关键在于我们观察的角度和层面。
我猜从具体应用的场景出发，应该很容易得到结论。
比如，订单，如何定义个订单，订单应该包含哪些字段，这不是标准库能决定的。
这段讨论没有正面回答问题，而是提供一个思路，把问题抛给使用场景。
1 个赞
wuxuan
2023 年12 月 31 日 06:50
3
@ice1000 关于椭圆可被视为圆的扩展，wiki里“Challenge the premise of the problem”一个视角挺有意思：
By analogy, then, a Circle is not an Ellipse, because it lacks the same degrees of freedom as an Ellipse.
Applying better naming, then, a Circle could instead be named OneDiameterFigure and an ellipse could be named TwoDiameterFigure. With such names it is now more obvious that TwoDiameterFigure should extend OneDiameterFigure, since it adds another property to it; whereas OneDiameterFigure has a single diameter property, TwoDiameterFigure has two such properties (i.e., a major and a minor axis length).
duzc21
2023 年12 月 31 日 09:39
4
这段我有看到，并且赞同正圆不是椭圆的说法。
如果特定领域的库需要，他应该自己来协调这个关系，由这个库来定义正圆和椭圆的关系。
1 个赞
我认为语言应该提供一个更具扩展性的、简单的、容易理解的、静态类型系统，而非严格定义的、满足一切需求的类型系统。
借用 wiki的例子（“Description”部分），当下大多数OO语言的类型系统设计是子类（subclass）必须实现基类（base class）的所有接口。在此设计下：
假如将圆定义为椭圆的子类，而椭圆类添加了“拉伸x轴”接口，那么圆类必须实现此接口，但会导致圆不再为圆。
假如反过来将椭圆定义为圆的子类，而圆类添加了“求半径”接口，那么椭圆必须实现此接口，但无法实现。
从设计的角度看，当前的这一基类-子类关系设计是否有改良的空间呢？抑或在大多数场景下不会有类似问题因而不值得将此设计其复杂化、由开发者自行规避？
看到狮偶中支持 添加数据类型方法 ，当前的设计是可以自定义类型但各类型间除了引用之外没有其他关联吗？这样的话的确规避了继承导致的问题。
顺便请问一下，每个名称后面的“类型”是何意呢？比如“名称 id 类型
目前类型之间只能引用。数据结构 跟 C语言的结构体类似，没有函数，没有逻辑，纯数据。需要复用就组合。
用 degrees of freedom 来解释是合理的，但我觉得大部分持有「椭圆是圆的扩展」这一看法的人是不理解什么叫 degrees of freedom 的
看到 matplot.patches.Circles 是把圆作子类的，还正好有 ellipse.set_height 这个导致圆不为圆的接口。
JavaFx 是把两者并列为 Shape 子类 。
反过来的尚未找到。
个人猜度，也许在API设计时，如果 椭圆 的专用接口太多，塞进 圆 里感觉不合适，就倾向把椭圆作为子类了。
在我的理念里,操作是最基础的,应该从"操作"来推导出继承链.
所以园和椭圆两种对象,谁继承谁,看各自有什么操作.
现在的编程语言走类型的路子搞的太复杂了。
改善图灵机的过程模型，而不是为了抽象直接在一个系统里嵌入另一个系统，或许是一种可以尝试的改进。
1 个赞
