EffectiveJava 第三弹——类和接口 (15-18 小节)

418次阅读  |  发布于1年以前

小伙伴们好呀， 这次分享的是 Effective Java 第三弹~ 类和接口 (15-18 小节)

前言

其实读到这一章的时候，我已经开始烦躁了……

可能是因为这是让我从头学 Java ，从最开始的 类和接口 去探索，心里怎么都有点不服

在废了好一番功夫后，才逐渐让自己这颗 急功近利 的心稍微安静下来

这篇文章也是和我的心情差不多，开始的随意，后面的渐渐有了思考扩展，收获还是很大的，但是书还得耐心看下去~

15. 使类和成员的可访问性最小化

make each class or member as inaccessible as possible.

这个就是能 private 的就弄成 private

包括属性，内部类。

访问性

private < default < protected < public

权限范围 private default protected public
同包同类 ✔ ✔ ✔ ✔
同包不同类 ✔ ✔ ✔
不同包子类 ✔ ✔
不同包非子类 ✔

16. 要在公有类而非公有域中使用访问方法

就是属性要 private，方法要 public

17. 使可变性最小化

这一节介绍了这个 不可变类 ，比如：String，基本数据类型的包装类，BigInteger，BIgDecimal

特点：

  1. 不提供任何会修改对象的方法，比如常见的 setXX
  2. 类不能被继承，比如：用 final 修饰类名，或者 私有化构造器
  3. 属性都是 private，final 的
  4. 确保对任何可变组件的互斥访问 ，这个挺拗口的：应该是说如果你的类里有 可变对象，那你要确保这个可变对象不会被外界改变，比如 接受可变对象时，直接创建新的对象，或者 深拷贝

最后一点比较难理解，这里看看 String 的例子。

揭秘

优点

  1. 不可变类比较简单，只有一种状态，就是刚创建时的状态
  2. 不可变类是线程安全的，不需要同步，可以自由共享，提供了原子性

缺点

  1. 不同的值创建不同的对象

所以要避免创建过多的不可变类对象，比如：String 有 StringBuilder（线程不安全版本） 相助一样，如果要拼接很长的字符串，要用它去创建，这样就不会每一步都创建出一个 string 对象而占用太多内存了，因为 StringBuilder 内部用 char 数组缓冲区来拼接字符串

这里创建了多少个对象？

StringBuilder b = new StringBuilder("hello");
b.append(" and good");

答案是：4 个， StringBuilder 一个，两个字符串常量，还有内部的 char 数组

小结

这里我感受最深的是这个 不可变类的深拷贝 ，以前还真没去留意 这些不可变类，以及他们怎么处理内部的可变类属性的！还有就是应对不可变类的缺点，需创建更多对象而带来的一些策略，如 StringBuilder 的 char 缓冲区 利于拼接，Integer 的 cache 缓存数组重复利用 -128 到 127 的数

技能get ✔

18. 复合优先于继承

看题先

例子1

这里输出的 addCount 是多少？

package com.jdk8.effective.chapter4;
import java.util.*;

// Broken - Inappropriate use of inheritance! (Page 87)
public class InstrumentedHashSet<E> extends HashSet<E> {
    // The number of attempted element insertions
    private int addCount = 0;

    public InstrumentedHashSet() {
    }

    public InstrumentedHashSet(int initCap, float loadFactor) {
        super(initCap, loadFactor);
    }

    @Override public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    @Override public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }

    public int getAddCount() {
        return addCount;
    }

    public static void main(String[] args) {
        InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
        s.addAll(Arrays.asList("Snap", "Crackle", "Pop"));
        System.out.println(s.getAddCount());
    }
}

思考后再往下滑动~

答案是 6

问题便出现在这个 addAll 方法中，他会遍历调用 add 方法，所以 count = 3+1+1+1

通过这个例子，我们也可以看出 继承的风险 ，比如

  1. 继承时，如果要重写父类的某个方法，可能会有不确定的风险。
  2. 如果不重写，只增加新的方法也有危险，因为父类可能在未来出现一个和你同名不同返回值的方法，这样你的方法就会编译不过了。

同时，作者举了 JDK 中两个写的不好的例子：Properties，Stack，表示他们应该用复合而不是继承。（继承要满足 is 关系）

接着，便引出这个 复合

例子2

package com.jdk8.effective.chapter4;
import java.util.*;

// Reusable forwarding class (Page 90)
public class ForwardingSet<E> implements Set<E> {
    private final Set<E> s;
    public ForwardingSet(Set<E> s) { this.s = s; }

    public void clear()               { s.clear();            }
    public boolean contains(Object o) { return s.contains(o); }
    public boolean isEmpty()          { return s.isEmpty();   }
    public int size()                 { return s.size();      }
    public Iterator<E> iterator()     { return s.iterator();  }
    public boolean add(E e)           { return s.add(e);      }
    public boolean remove(Object o)   { return s.remove(o);   }
    public boolean containsAll(Collection<?> c)
                                   { return s.containsAll(c); }
    public boolean addAll(Collection<? extends E> c)
                                   { return s.addAll(c);      }
    public boolean removeAll(Collection<?> c)
                                   { return s.removeAll(c);   }
    public boolean retainAll(Collection<?> c)
                                   { return s.retainAll(c);   }
    public Object[] toArray()          { return s.toArray();  }
    public <T> T[] toArray(T[] a)      { return s.toArray(a); }
    @Override public boolean equals(Object o)
                                       { return s.equals(o);  }
    @Override public int hashCode()    { return s.hashCode(); }
    @Override public String toString() { return s.toString(); }
}
package com.jdk8.effective.chapter4;
import java.util.*;

// Wrapper class - uses composition in place of inheritance  (Page 90)
public class InstrumentedSet<E> extends ForwardingSet<E> {
    private int addCount = 0;

    public InstrumentedSet(Set<E> s) {
        super(s);
    }

    @Override public boolean add(E e) {
        addCount++;
        return super.add(e);
    }
    @Override public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }
    public int getAddCount() {
        return addCount;
    }

    public static void main(String[] args) {
        InstrumentedSet<String> s = new InstrumentedSet<>(new HashSet<>());
        s.addAll(Arrays.asList("Snap", "Crackle", "Pop"));
        System.out.println(s.getAddCount());
    }
}

现在，输出结果便是 3 了。

解析：InstrumentedSet 中 +3 后，就调用 HashSet 的 addAll 方法了。我们没有重写 HashSet 中的 add 方法，自然不会出现重复计算了。

例子1 例子2 对比

图中忘记加上 field 了。

例子2 ForwardingSet 中多了 Set 字段，拿例子来说，实际功能便是 为 HashSet 增加一个 统计功能 addCount 。

这是不是哪个设计模式呢？

答案就是 装饰者模式

这里写个小例子感受下 

package com.jdk8.effective.chapter4;

import java.util.Collection;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Set;

/**
 * @author Java4ye
 * @微信公众号：Java4ye
 * @GitHub https://github.com/Java4ye
 * @CSDN https://blog.csdn.net/weixin_40251892
 * @掘金 https://juejin.cn/user/2304992131153981
 */
public class DecorateSet<E> implements Set<E> {

    private final Set<E> mySet;

    public DecorateSet(Set<E> mySet) {
        this.mySet = mySet;
    }

    @Override
    public boolean add(E e) {
        // 增加功能
        System.out.println("hello Java4ye");
        return mySet.add(e);
    }

    @Override
    public Iterator<E> iterator() {
        System.out.println("-------");
        return mySet.iterator();
    }


    public static void main(String[] args) {
        DecorateSet<String> decorateSet = new DecorateSet<>(new HashSet<>());
        decorateSet.add("我是装饰者");
        for (String s : decorateSet) {
            System.out.println(s);
        }
    }
 ...
}

小结

这一节看了之后，感受更多的是不要乱用继承关系 ，要遵循 is 关系，如果要扩展原来的功能，要更多的考虑 复合，如 装饰者模式

总结

15 小节，主要复习下这个 可访问性

16 小节，就是属性要 private，方法要 public

17 小节，主要是 不可变类 的特点以及优缺点，还有 深拷贝 的应用

18 小节，告诉了我们 不要随意使用 继承 ，而要优先考虑这个 复合，如 装饰者模式 去扩展功能，提供系统的灵活性

戒骄戒躁！这次要耐心读完！

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8