敲响OO时代的丧钟！——DJ对于数据持久化的支持(3)

OO设计原则批判

http://spaces.msn.com/members/zbw25/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!280.entry

本来对这个话题丧失了兴趣。先是不给定义，直接就含糊地批判起了所谓"OO"。
然后灌水味道就越来越浓。没有定义，也不给论据，结论倒是满天飞。


不过，看了庄的那个关于generics的例子，还是觉得有话要说。（至少此处有了一个具体抓的住的例子）

java5里面，代码可以写成

public void addListX(ArrayList<? extends X> listx);{
        for(int i=0;i<listx.size();;i++);{
                X x=listx.get(i);;
                x.add(1);;
        }
}

这样，就可以addListX(listy)了。

对c++，就更简单了，c++的泛型基本上是弱类型的，没有java, c#的类型约束，直接写成：

template<typename X>
void addListX(ArrayList<X>& listx);{
        for(int i=0;i<listx.size();;i++);{
                X x=listx.get(i);;
                x.add(1);;
        }
}

就ok了。


泛型是个非常深的话题，我相信，我，还有javaeye经常冒头的一些牛人，t1, gigix, robbin，potian等，都没有足够的功力深入地研究。大家熟悉的，不过是一些快餐文化式的"OO"和所谓"pattern"之类的雕虫小技。

不过老庄有一点没说错，oo的子类型多态和泛型确实不是那么容易合拍的。c++的模板不说，没有一点类型约束，就是个高级宏而已。

真要是追求绝对灵活的泛型，那么和OO的子类型多态就会有冲突。

要看真正漂亮的泛型，建议老庄不要看c++, c#，直接看haskell，或者nice。

要看泛型和OO结合的比较好的例子，看ocaml。


其实，泛型也好，子类多态也好，前提仍然是静态强类型的OO语言。可是不要忘了，还有ruby, python这些动态类型的OO的大家庭。南少林，北少林，落下哪个都不完整。

那么这段代码写得不好的原因（或者说，最重要的原因）是试图写它的程序员根本不知道解码程序应该怎么写，而不是它用了（或者没用）OO。不知道一个程序应该怎么写的话，OO或者PO或者别的什么O都不能帮助你把它写好。如果你要拿这样的一段代码来指责OO，那么你同样可以用它来指责别的任何什么O。实际的情况也正是如此，age0拿出的三个solution全部都是该挨刀的。如果这可以构成有效的批评，那么你就可以批评任何O。这就是我想说的。

关于泛型，不妨跟C++ View的虫虫讨论，他对这个玩意还是比较了解的。

我说的主要针对泛型的类型系统。c++的模板根本就没有像样的约束系统。一些meta-programming的trick只能说比较有趣，远谈不上漂亮。

c++那个只能叫模板，不配叫泛型。

yes. 所以，我在前面说，C++ Template类似于C++ Macro，可用于代码生成。
并把这种无类型约束的GP 称为编译期的脚本编程，或者相当于根据Reflection编程。



这些都是啥子阿? 先给出点经典的“漂亮的泛型”例子吧。还有“要看泛型和OO结合的比较好的例子，看ocaml。”的例子。
牛人们只是说几句，这个好，自己看去吧。对于我这样的没有基础知识的人，要花很多没有必要的入门时间。
谢谢了呵!!!

googled ocaml
http://caml.inria.fr/
http://merjis.com/developers/ocaml_tutorial/

那么我们就把整个应用环境补充完整。

这是一个普通人家，家里已经接入了有线电视网络，有一个标准的信号接口。有线电视公司可以根据用户的需求提供不同的视频服务，但是要求用户必须购买相应的解码器，作为显示设备的电视也会有标准的输入接口，所以解码器必须提供标准的输出接口，当然如果用户有其他的显示设备，我们也有相应的解码器支持，但是价格肯定会比普通的昂贵。

现在我们有了由信号源、解码器和显示终端组成的完成系统，下面有请gigix为大家示范正确的OO设计，大家鼓掌欢迎。

问题在于，如果你把ArrayList<Y1>作为ArrayList<? extends X>

传进来的list，还是有类型安全问题的呀！

((ArrayList<Y1>)listx).add(new Y1());
((ArrayList<Y2>)listx).add(new Y2());
都是可以顺利通过编译的呀！

这顺便也回复了JavaCup的一个类似的疑问，只是在C++中该怎么写我不是很清楚。

原则是些经验之谈，看一下传统的结构化的设计书，有关内聚和耦合的部分也有类似的现象，原则不是OO的独创，原则不是什么不可动摇的经过严密逻辑推理的定理，和模式相比，我认为模式有点象棋谱，具备一定的可重复性和严密性，而原则只是经验和感觉比模式严密性还要差。
这个坛子许多同志推崇SICP，在SICP课程录像的第一部分Harold讲到:
"it(computer science) is not a science, might be engineering or might be art". "Actually, it has a lot in common with magic." 如果把bob写的这些经验之谈都当成是OO的罪孽，有点过分了吧!

to:JavaCup

Bob大叔我很佩服，就在于他明确的告诉我们，OO设计原则，不能一味的去遵循，会死在里面的 :p

但是，谁能告诉我，如何去遵循这些原则呢？