分类存档：读书笔记

看《Effective Java》看到的，主要讲对Java equals的override。C++对==的重载也是一样的。下文就用Java举例子了，因为是OOP的通用问题，所以很容易类比到C++。

问题描述：

class A {
    int x;

    public A(int x) {
        this.x = x;
    }

    @Override
    boolean equals(Object o) {
        if (o instanceof A) {
            return x == (A)(o).x;
        } else {
            return false;
        }
    }
}

class B extends A {
    int y;

    public B(int x, int y) {
        super(x);
        this.y = y;
    }
}

以上代码中B如果想Override equals使得y也能加入判断，应该怎么做？

也许最直接的答案是

    @Override
    boolean equals(Object o) {
        if (o instanceof B) {
            return x == (B)(o).x && y == (B)(o).y;
        } else {
            return false;
        }
    }

然而equals需要的是一种等价关系，需要满足三个条件：

自反性。即x.equals(x)为真。
对称性。即x.equals(y) == y.equals(x)
传递性。即x.equals(y) && y.equals(z)，则x.equals(z)

上面这个做法明显对称性会崩盘。
A a = new A(0);
A b = new B(0, 0);
a.equals(b); //true
b.equals(a); //false

那如果加入对父类的特判呢？对称性是没问题的，但是传递性会崩。
A a = new B(0, 0);
A b = new A(0);
A c = new B(0, 1);
a.equals(b); //true
b.equals(c); //true
a.equals(c); //false

实际结论是B根本没有办法重载一个合理的equals。

证明：因为不能更改A类的equals，因此A的实例equals B的实例的时候一定会只判x然后返回true。那么根据对称性，B类的实例equals对应A类的实例的时候，也一定要返回true。所以如果想要在B的equals中判断y，上面传递性的问题一定会出现。至此对称性和传递性不可能同时满足，所以不可能存在科学的重载方法。
这个从本质来讲，父类和子类的相等是一种偏序关系，然而equals要的是等价关系，所以被父类强行equals为true以后，就怎么也救不回来了。
那么我们放松一下条件，允许修改父类呢？

从上面的教训可以知道如果子类和父类之间可以相等的话，一定会GG。那只能做成不相等了。

于是直接getClass判吧，直接看new的时候是什么的类，不同就直接判不等。那么假如A多了一个方法。
    private static final Set <a> luckyA = new HashSet<>()
    static {
        luckyA.add(new A(5));
        luckyA.add(new A(10));
    }

    public boolean isLucky(A a) {
        return luckyA.contains(a);
    }

这个isLucky写得再正常不过了，然而如果我们那么做，那这个isLucky对于所有子类就失效了。这违背了OOP的Liskov substitution principle。

Wiki上的定义：Subtype Requirement: Let  be a property provable about objects x of type T. Then  should be true for objects y of type S where S is a subtype of T.
你也许会想，不加这个isLucky不就没有违反了吗？是的，但是只要A中有依赖A的equals的方法，就会违反这个规则。
然而你觉得因为子类的一个equals问题，给父类定下不能依赖自己的equals实现任何功能的规矩，合理吗？
综上所述，父类与子类equals可以为true是不行的；然而一律为false又会break OOP的原则。于是我们可以推导出即使允许同时修改父类和子类的equals，也没有任何合理的写法。这也是《Effective Java》给出的结论。
形式化描述一下这个结论：
如果父类是可实例化的(非abstract，非interface)，子类如果添加了新的域想override equals把这个域放进去，没有任何一种override的方法是合理的。
那么该怎么做呢？答案：不要用继承，用组合。然后加一个fallback的方法。
class B {
    A a;
    int y;

    public asA() {
        return a;
    }
}

	

Dreyfus模型将学习的过程分为五个不同的阶段或水平：

1.新手（Novice）需要详细的指导——要手把手地教。新手不知道这些指导是否有效，或者哪些指导更加重要；因为没有上下文知识可供他们使用进行评估。因此，新手需要频繁迅速的成就感和有规律的反馈。一本好的入门指导书籍要提供有足够多的图画和充足的可靠信息。

2.高级初学者（Advanced Beginner）对基本步骤——单独的任务——已经熟悉了，而且可以把它们进行有机的组合。高级初学者仍然在很大程度上是面向任务而不是面向目标的，不过他们已经开始有些概念了。这也是一个学习者最危险的阶段——他们知道自己学到的已经不少了，但是这还不足以让他们远离麻烦！刚学走路的孩子在很多方面都是高级初学者。有了足够的经验，高级初学者就能拥有足够的能力以胜任某些工作。

3.在胜任（competent）水平上，他们就走到面向目标阶段了。他们可以组合一系列任务以达成某个目标。也许任务的组合顺序不是最佳的，但是通常都可以发挥作用。有能力的人希望给定一个目标，然后能够得到别人的信任来达成这个目标。相反，如果要是试图详细告诉他们应该怎么做，这些有能力的人就会觉得很烦躁，就像是汽车里被坐在后面座位的乘客指手画脚的司机一样。大部分人在大部分技能上很难超越“胜任（competent）”水平，即使他们在每天的日常工作中使用这些技能。这是人类的基本特性——一旦有所收获，我们就不想再投入精力了，而且对于大部分活动来说，所谓的收获只不过是把工作做完而已。

注：已经能够分解目标和组合一系列任务来完成目标，这是胜任的关键。

4.在精通（Proficient）水平上，解决方案开始在人的心目中“慢慢浮现”——而且通常已经完全成型。他们已经具备了在直觉中形成解决方案主要部分细节的能力，之后就可以根据自己先前的经验积累来对解决方案进行映射。一个精通的人需要对其行动的上下文有更广阔的了解，并且开始享受隐喻和格言（以及相反的类似内容）带来的乐趣。他们仍然会回头根据接受的基于规则的训练，来验证自己行为的正确性；但在这个阶段他们已经学着相信自己的判断了。从“新手”发展到“胜任”阶段基本上是线性的过程，而到“精通”阶段代表了一个台阶的提升。一个人必须积极选择才能促成这个转变的开始。通过对某件事情重复足够的次数是可以达到“胜任”的，但要变想得“精通”，必须要有明确的心理诉求才行。

注：在精通阶段，从规则(Rule)到直觉(Intuition)的质的变化，已经能够将显性的知识转化为自己的宝贵经验和方法论。在这里是需要明确的心理述求和自我领悟。

5.专家(Expert)水平：正如从“胜任”到“精通”的转变一样，转变为“专家”也是非线性的过程。要想成为某个领域的专家，可能要花费数年的努力才能达成。这些人工作时几乎完全是从直觉自发的状态，而且很少犯错误。专家生活在模糊的世界之中。她以自己的能力为傲，而且喜欢通过与其他专家交流来校正和提高自己的技能。有趣的是，处于初级阶段的人们倾向于过高估计自己的能力，而在较高阶段的人则更加谦逊。

注：完全的融会贯通，自觉自发，形成了自我的解决问题的方法论和模式，往往已经是无招胜有招。

以上内容转自：新浪博客

翻了翻dd学长的twitter看到这个东西，很有感触。

实际上很多时候我们解决问题的方法都是将一些已有知识进行组合。而这个组合的能力，则决定了自己到底处于哪个层次。

在以前，我是很享受那种想出新颖的方法解决某个问题的感觉的。随着后来的成长，我渐渐发现我所谓的新颖方法肯定是借鉴了某些类似的经验或者思想的。有时候所借鉴的思想甚至可以和这个领域看似毫无关系。

这也就是所谓的知识结构。完全逃离自身知识结构的创新我觉得是不太现实的。我感觉即使是很牛的人，能做的往往也是从自己的知识结构体系中取出内容进行组合。

所以结论是我所该做的内容有两个：一是提升知识量的大小；二是提高对知识组合的能力。

个人看法，欢迎讨论。