面向对象与排列组合

__BlueGuy__

我不知道什么鸟鸭子类型
{0  1  2  3  4  5  6  7  8  9} 这么一个集合来表示 2^n 物品， 就是牛B

stonemason

有OIOIC的神韵

__BlueGuy__

Sevk 发表于 2012-11-14 10:42
天时，地理，人和，缺一不可。

恩，确实

starwing83

回复 19# __BlueGuy__


    首先要说一句：我已经不是OO的fans了。但要舍弃或者赞同一个观点，你至少要先了解它。你了解的只是C++所谓的OO，我来先说说什么才是真正的“面向对象”（而不仅仅是静态继承那一套）。之前我建议小乔写一篇面向对象的文章。我估计小乔也不会来这儿了。所以我先写一点东西你看看吧。

“面向对象”，之所以叫“面向对象”，而不是叫“面向类型”或者“面向继承”，是因为这个概念的核心是一个一个对象，而不是继承或者类型这些东西。对OO来说，每个对象都是一个“实体”，你可以认为它们是一个一个的“状态体”或者“图灵机”等等。OO所作的事情，实际上是向这些状态实体发送消息，而不关心它们如何处理这些消息。

从这个观点来看，OO实际上类似ADT——是的，OO就是在ADT的基础上提出并发展的。之所以叫OO而不是ADT，是因为OO关注的核心已经从数据结构的抽象，转换为对数据结构的操作的抽象上了。

假设你有一系列的对象，它们都和十个属性或多或少联系。这种观点是奇怪的。因为对象本身没有属性，对象只是一个“存在”，一个能区别于其他对象的“存在”。我们可以向某个对象发送消息。这样，既然你提到了属性，我们就假设能向对象发送的消息就是关于这些属性的。我们可以发送消息，要求对象修改或者从对象获取这些属性。这就成功地将属性这个概念从OO中去除了，我们只需要知道某个对象支持什么消息而已。

假设我们有100个对象——对，就算属性的组合是无限的（这个我同意），但是对象的数量也应该是有限的，取决于你实际的应用——那么，你所关注的，仅仅是需要向哪个对象发送哪些消息而已，比如一个对象仅支持修改1,2,5,8号属性，那么你也仅能对它发送这些消息来修改这些属性。其余的会引发一个错误（无论是编译期错误，运行时异常或者仅仅什么都不做都是错误的体现），在这个框架下，OO能完全避免掉无限的影响：请注意，这里的处理将无限避免掉了，我们只需要面对有限个对象，发送有限个消息而已。即使在数学上来说，这种将无限处理成有限的技巧也是很有用的。一个很直接的例子就是“数学归纳法”，这也是一种将无限处理成有限的方式。

现在的问题仅仅是，C++式的OO没法避免这个问题。C++必须要求每个对象隶属于某个类，而不允许这些对象的集合能够方便地组合——你可能需要写十个类，然后由这十个类互相继承，从而产生出合适的所有的类，进而产生你需要的所有对象，而这是繁琐的。这是C++的问题，而不是OO的问题。我们考察其他的几种方案。

我们如果能够将对象对消息的操作剥离出来，得到了十个“操作”，然后在这些操作的基础上直接得到“类”，这样我们就能直接处理对象，而不是类。这才是面向对象真正有用武之地的地方。

比如说，鸭子类型：我们不管类，我们只按照需求实现任何我们需要的**对象**，然后产生它们（类退化为一个构造函数），然后所有的函数都可以处理这些构造函数构造出来的鸭子对象——只要这些对象能够满足这个函数所需要这个对象处理的某些消息即可。比如这样的函数：

def square_add(a, b): return a*a + b*b

我们只需要a和b支持乘法和加法即可。至于a和b是什么，我们不关心。这就是鸭子类型的思想。这种“跳过继承/类直接处理对象”的方式，即是OO的最初形态。

别的方面，比如mixin类型：我们创造出能单独处理类型的“插件”，并对对象（而不是类）注入这些插件。这就意味着类这个概念无用了，对象仅仅是插件的集合。这种“平面结构”（而不是C++的继承结构）即是mixin类型。它同样能解决因为对象之间差异过大，而导致的继承问题。

最后说说C++为什么没有选择这些方案：很简单，性能。在C++的设计之初，性能就被作为一个重要的考虑要素，因此这些可能会导致性能降低的设计被排除出C++，也是很正常的事情了。凡事有得必有失。

然而，C++依然可以支持这些设计（即使是一个子集）。这就是泛型。泛型使C++得到了静态的鸭子类型的能力。实际上，按照你的心意去产生平面的类（没有继承），按照你的心意去处理这十个属性中的某几个，然后处理函数都是模板即可。模板不管实际的类型，只需要类型满足模板内部对对象的要求即可。这就是为什么STL强大的原因。

所以，如果遇到难题，先问问自己，是不是自己还没学到家，而不要去怀疑一个理论或者认为全世界人都是SB。在完全学到家以后，你才有权力去赞扬/抛弃它，而去学习新的架构。去体会架构后的思想。

记住，谦卑是美德，自大使人迷茫。

starwing83

回复 21# __BlueGuy__


    鸭子类型就是能解决这样的集合无限问题。Lua本身没有对象，但可以用表来表示这样的问题，其描述能力也是无限的， 原因就在这里。

但是你分析问题要分析绝对。Lua的表抽象比OO更强大，因此可以表达这样的集合，但这不意味着OO就不够强大以至于无法表达这样的集合。只是你不理解OO而已。

一定要记得，如果一个工具无法满足你的要求，在“工具不合适”这个理由以外，你要先去想想，你用对了这个工具没有。

__BlueGuy__

starwing83 发表于 2012-11-14 11:00
回复 21# __BlueGuy__

你先说说表怎么解决这样的问题？
你又怎么理解OO了 ？

老子不认识什么Lua, 老子只认c ，你说说c 怎么解决这个问题

__BlueGuy__

比如这样的函数：

def square_add(a, b): return a*a + b*b

我们只需要a和b支持乘法和加法即可。至于a和b是什么，我们不关心。这就是鸭子类型的思想。这种“跳过继承/类直接处理对象”的方式，即是OO的最初形态。

// 这些都太小儿科了， 我早就知道 程序的本质在与怎么放置数字
我不是说过了，会有无数个函数名来解决计算问题
谁管a, b是什么了，我不是说计算机的一切都是数字嘛？

大家都看到我不管了， 你还在假设我在管...
俺有点事， 回头再跟你讨论鸭子类型

starwing83

……………………你没救了。

该说的我都说了，没听进去是你的事儿。

__BlueGuy__

假设我们有100个对象——对，就算属性的组合是无限的（这个我同意），但是对象的数量也应该是有限的，取决于你实际的应用——那么，你所关注的，仅仅是需要向哪个对象发送哪些消息而已，比如一个对象仅支持修改1,2,5,8号属性，那么你也仅能对它发送这些消息来修改这些属性。其余的会引发一个错误（无论是编译期错误，运行时异常或者仅仅什么都不做都是错误的体现），在这个框架下，OO能完全避免掉无限的影响：请注意，这里的处理将无限避免掉了，我们只需要面对有限个对象，发送有限个消息而已。即使在数学上来说，这种将无限处理成有限的技巧也是很有用的。一个很直接的例子就是“数学归纳法”，这也是一种将无限处理成有限的方式
//
我已经把所有的被选方案都考虑到了，
你总是在我说的集合的子集里解决问题，你把 1,2,5,8当成了所有的对象，还振振有辞
你懂什么叫宏观上把握问题吗？， 你那个想法JB用没有，我要是遇到1,2,3,8这么简单的一个对象，还用的着 面向对象，
面向过程都直接干了