还用不用OO了

看了一篇文章,就是参考中的那篇,大致总结一下用OO的问题。

继承的问题

  1. 父类太多,需要依赖的类就比较多了,特别是依赖的jar包比较多。
    不过我觉得现在的IDE以及Maven这些已经处理的挺好了,会自动给提示让你去选择依赖的Jar包。当然Maven这些还是有些麻烦,但毕竟比起纯手工打造要强多了。
    尤其要小心的就是不同Jar包有相同名字类的情况,一不留神引用错了,造成后面行为的错误,可就比较麻烦了。
  2. 多继承
    其实这个没什么好说的,既然大多数OO语言都不支持,而且都提供了用接口来便桶。我觉得也不是问题。
    特别是经常用Interface和Abstract类,还是蛮清晰的。
  3. 父类行为的改变造成子类的Bug。
    这个是个问题,一般都比较默认父类行为是一致的。要是某次引用的Jar包升级造成行为变化,程序出错造成live issue,那真是心里一万个草泥马飘过。。。
    参考文中给了个例子,拷贝过来:
    父类
import java.util.ArrayList;
 
public class Array
{
  private ArrayList<Object> a = new ArrayList<Object>();
  public void add(Object element)
  {
    a.add(element);
  }
  public void addAll(Object elements[])
  {
    for (int i = 0; i < elements.length; ++i)
      a.add(elements[i]); // this line is going to be changed
  }
}

子类

public class ArrayCount extends Array
{
  private int count = 0;
 
  @Override
  public void add(Object element)
  {
    super.add(element);
    ++count;
  }
 
  @Override
  public void addAll(Object elements[])
  {
    super.addAll(elements);
    count += elements.length;
  }
}

修改的父类

  public void addAll(Object elements[])
  {
    for (int i = 0; i < elements.length; ++i)
      add(elements[i]); // this line was changed
  }

计算了两次。。。What The Hell!!!

用什么层次结构呢?

参考文提出用Containment Hierarchies,比如袜子装在抽屉里,抽屉装在卧室了。。。
有一定道理,可真实世界确实有继承这种层次结构啊。
只是不唯一而已。

封装的问题

文中说的封装的问题,主要说的就是引用的问题。
比如一般OO语言都是引用传递的,当一个对象的引用传到另一个类的构造函数中,这个对象就不安全了!?因为别的代码有了这个对象的引用。
而他提出的解决办法是用值传递对象。我觉得他这个方法弊大于利。而且很多问题其实是语言实现的问题。

封装还是不错的,喷点不多。

多态的问题

看到这里的时候,我先想了半天多态的缺点。发现也没有太多,主要是要小心别弄错了之类。
果然,作者最后说不要用OO的多态,要用基于接口的多态。

作者是Function Programming粉丝。

Reference

推荐阅读更多精彩内容