看了一篇文章，就是參考中的那篇，大致總結(jié)一下用OO的問(wèn)題。

繼承的問(wèn)題

1. 父類(lèi)太多，需要依賴(lài)的類(lèi)就比較多了，特別是依賴(lài)的jar包比較多。
   不過(guò)我覺(jué)得現(xiàn)在的IDE以及Maven這些已經(jīng)處理的挺好了，會(huì)自動(dòng)給提示讓你去選擇依賴(lài)的Jar包。當(dāng)然Maven這些還是有些麻煩，但畢竟比起純手工打造要強(qiáng)多了。
   尤其要小心的就是不同Jar包有相同名字類(lèi)的情況，一不留神引用錯(cuò)了，造成后面行為的錯(cuò)誤，可就比較麻煩了。
2. 多繼承
   其實(shí)這個(gè)沒(méi)什么好說(shuō)的，既然大多數(shù)OO語(yǔ)言都不支持，而且都提供了用接口來(lái)便桶。我覺(jué)得也不是問(wèn)題。
   特別是經(jīng)常用Interface和Abstract類(lèi)，還是蠻清晰的。
3. 父類(lèi)行為的改變?cè)斐勺宇?lèi)的Bug。
   這個(gè)是個(gè)問(wèn)題，一般都比較默認(rèn)父類(lèi)行為是一致的。要是某次引用的Jar包升級(jí)造成行為變化，程序出錯(cuò)造成live issue，那真是心里一萬(wàn)個(gè)草泥馬飄過(guò)。。。
   參考文中給了個(gè)例子，拷貝過(guò)來(lái)：
   父類(lèi)

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
  }
}

子類(lèi)

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;
  }
}

修改的父類(lèi)

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

計(jì)算了兩次。。。What The Hell!!!

用什么層次結(jié)構(gòu)呢？

參考文提出用Containment Hierarchies，比如襪子裝在抽屜里，抽屜裝在臥室了。。。
有一定道理，可真實(shí)世界確實(shí)有繼承這種層次結(jié)構(gòu)啊。
只是不唯一而已。

封裝的問(wèn)題

文中說(shuō)的封裝的問(wèn)題，主要說(shuō)的就是引用的問(wèn)題。
比如一般OO語(yǔ)言都是引用傳遞的，當(dāng)一個(gè)對(duì)象的引用傳到另一個(gè)類(lèi)的構(gòu)造函數(shù)中，這個(gè)對(duì)象就不安全了！？因?yàn)閯e的代碼有了這個(gè)對(duì)象的引用。
而他提出的解決辦法是用值傳遞對(duì)象。我覺(jué)得他這個(gè)方法弊大于利。而且很多問(wèn)題其實(shí)是語(yǔ)言實(shí)現(xiàn)的問(wèn)題。

封裝還是不錯(cuò)的，噴點(diǎn)不多。

多態(tài)的問(wèn)題

看到這里的時(shí)候，我先想了半天多態(tài)的缺點(diǎn)。發(fā)現(xiàn)也沒(méi)有太多，主要是要小心別弄錯(cuò)了之類(lèi)。
果然，作者最后說(shuō)不要用OO的多態(tài)，要用基于接口的多態(tài)。

作者是Function Programming粉絲。

Reference

• Goodbye, Object Oriented Programming https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53#.uv6ruqb8l