【2012-02-13】

@tertio：在程序设计中，抽象原则和最少耦合原则实际上是矛盾的，细究下去，还有更多的原则也是相互矛盾的。

@whigzhou: 嗯，是的。缓解的办法是，抽象的思考，松耦合的实现，这类似于交谈中，各自保留自说自话的自由，同时尽可能捕捉共同的意义

@whigzhou: 告别柏拉图，先具体，后抽象，不要把抽象的结果视为“更基本的东西”甚至“是前提”...可是，洁癖们往往做不到

@tertio：回复@whigzhou:主要是没条件。

@whigzhou: 我多年前说过，像OO这种自上而下、先抽象后具体的模式，其实就是柏拉图主义，但人类认识和创造世界的过程，与柏拉图图景大相径庭

@茶博未：教科书，包括数学的，都该这么写。手册则不然

@tertio：所以新的体系是按照科学方法论的过程来设计的，实际上，就是科学方法论的代码版。

@whigzhou: 嗯，在过程性语言中，假如先实现了“电视机类”和“电饭锅类”，然后抽象出“电器类”，就要把前两个的共同部分挖出来，而在你的逻辑语言里，可能只是增加了一条更易通达的逻辑路径，前面的代码无须修改，我理解的对吧？

@tertio：具体就复杂了。需要可以自动提取共性，之后可以保持映射关系或者做一个硬拷贝脱离映射关系，脱离映射关系之后还可以反过来约束具体实现。花样还可以更多，均取决于语言的表达力。（甚至完全脱离OO的语境）比如可以说：电视机X和电饭锅Y共同使用的金属。

@whigzhou: 比如可以这样，先具体：IsClass(电视机),HasProp(电视机,功率),IsClass(电饭锅),HasProp(电饭锅,功率).然后抽象：IsClass(电器),Is(电视机,电器),Is(电饭锅,电器),As(电视机.功率,电器.功率),As(电饭锅.功率,电器.功率).这样，抽象和松耦合便同时做到了，对吧？

@tertio：对，两个As可以默认，除非名字不一样。此刻IDE应提供电视机和电饭锅的两个版本的定义，原来的定义和有抽象之后的定义。之后的问题在于，谁约束谁？是抽象约束具体实现还是具体实现约束抽象？

@tertio: 之后的问题在于，谁约束谁？是抽象约束具体实现还是具体实现约束抽象？

@whigzhou: 回复@tertio:这个我觉得应该按照对象被声明为什么类，假如X最初被声明为Isa(X,电视机)就受两个类的双重约束，假如被声明为Isa(X,电器)，便只受一个类约束

@tertio：回复@whigzhou:事实上，不会做任何约定。这句话（按照对象...，假如...假如...便...）的含义本身是用代码表达出来的。其基础机制，是逻辑上的，有的论断是推理出来的，随着前提变化而变，而有的论断，推理出来之后会成为独立的事实，不随前提改变。