物件导向
OOP
Object-Oriented Programming
OOA
Object-Oriented Analysis
从以前就从网络上得知有四大观念
但没真正搞懂这两个东西
abstraction
polymorphism
网络上的说法也不太一致
最近又再重看了一次
我这次的想法是这样
abstraction 几乎是所有 OOP 的核心思想
用简单的东西表达复杂的东西
只需要知道如何操作各种东西
不需要知道那个东西到底是怎么被做出来的
只是 OOP 着重于用 object 来做到 abstraction
而 functional programming 着重于用 function 来做到
也因次 OOP 衍生出其他三大观念
encapsulation
inheritance
polymorphism
其中
polymorphism 在网络上也是有很多解释
我觉得只要是能用一个百变怪来代表多个东西
那就是 polymorphism
1.
如果 A1 A2 A3... 和 B 的关系
是 extends 或 implements
让 B b = (其中一个 A) a
这时百变怪 b 是(其中一个 A)
b 的函式其实是(其中一个 A)的函式
2.
override
和 1. 有点类似
但只侷限于 extends 的关系
3.
overload
同一个函式名称可以代表多个功能类似但细微不同的运算
不知道我这样想对不对？

可以看一下 #1A4lZ_dX

has-a = interface的说法哪来的? has-a是composition吧interface...就是interface，从外显的功能来定义你用车子和飞机会觉得冲突，是因为你定义的Car = 路上走Airplane = 空中飞，这很明显是从外显功能定义是interface继承关系是以实作为本体的，Car应该是指由底盘车身引擎...以特定方式组成的类别，如果未来可以飞的车，组成方式是以现在的车子加上飞行功能，那就是Car : Flyable不然不用未来，现在飞机就能在路上走了啊如果这个外显功能不只是描述，还包含实作，现在interface也支援default method了(在OOP叫Mixin)

那说法不是我说的所以你的说法是 功能用interface分 实体用extends class那如果飞机越做越像车子 车子也越做越像飞机你还是会遇到多重继承的问题你只是硬套上一个实体(架构 组成方式)不会改变的限制我猜想在这种情况下你可能就选一边站 飞机或车子或是另开一个class

说真的如果两个东西接近到可以用一个类别来modeling，那refactor成一个也是很正常的，我觉得不能多重继承是限制，但不是缺陷，不用提这个例子也有无数该重写的情况了