Re: [閒聊] OOP小評

[iceonly (只有冰)]

※ 引述《csfgsj (Lazy bone)》之銘言：
: ※ 引述《oaz ()》之銘言：
: : 那我再舉例，假設鞋子（資料）有一個動作（程序）叫綁鞋帶
: : 你會預期
: :         I. 鞋子.綁鞋帶() 會只作用在這雙鞋？
: :         II. 鞋子.綁鞋帶() 不但會作用在我腳上的鞋子，還會作用在隔壁鄰居的鞋子上
: :         III. 所有人的鞋子的綁鞋帶動作，都統一在某間放裡
: 開放體系就是在我得到這雙鞋子時
: Struct Shoes {…..}
: 我不必去預先設定我會對它作什麼動作
: 對鞋子的動作可能當時有一些
: A( shoes *);
: 以後有可能再去想到另外一些
: B( shoes *)
: 我不用一開始就把所有東西都設死

前面隱晦不明的定性定量不提了，現在換題OOP了嗎?

綜合你上一篇和這一篇的說法可以摸索出你幻想中的OOP了，
你幻想中的OOP就是business logic全部都綁在domain身上，
需要這個class做甚麼的時候就是呼叫class本身的method。

若之後需要增加新功能，就是要修改domain本身，為他多寫一個method，
然後再修改主程式，把foo.methodA()修改成foo.methodB()這樣?

不會有人這樣寫的，所以大家批評你不懂OO就是這樣。
會這樣寫的人只有還沒進業界的大學生吧?

--


OO的目的如同前面的人的說法一樣，盡可能的抽象化已將維護成本降到最小。
最理想的情況就是要增加新功能只需要新寫個class或新的method，
然後做點小設定就能無痛更換，主程式啥的完全不用動。

以這個鞋子為例，一般的做法是這樣
interface ShoesProcessor{
  public void processShoes(Shoes shoes);
}

class DefaultShoesProcessor implements ShoesProcessor{
  public void processShoes(Shoes shoes){
    print("我只會吃鞋");
  }
}

之後你要新增功能時只需要implement同樣的interface

class ShoesThrower implements ShoesProcessor{
  public void processShoes(Shoes shoes){
    print("丟掉");
  }
}

就能無痛替換他
ShoesProcessor processor=ShoesProcessorFactory.getProcessor("foo")
processor.processor(shoes);

--


另外一種情況就是對shoes抽象化

abstract class Equipment{

   public Bonus getBonus();

}

class shoes extends Equipment{

   public Bonus getBonus(){
     return new Bonus().addAgi(1);
   }
}


你要使用這個class時只需要呼叫他特定的method就好了，不需要管他是不是鞋子

class Player {

  List<Equipment> equips;

  public Status getStatus(){
    Status status=new Status()
    for(Equipment equip:equips){
      status.addBonus(equip.getBonus);
    }
    return status;
  }



}

像這樣抽象化以降低維護成本才是OO的目的，
絕對不是你幻想中的方式


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 210.202.62.118
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1425564547.A.749.html
→ typiacalcat: 他超努力發文要把定性定量洗掉 你又提出來...
→ dreamnook: 結果這篇到底在回誰來著XDD
沒特別回他，只是這篇自認可以討論，看有沒有更好的實作方法
推 art1: 說不定他真的就是那樣寫 XD
→ dreamnook: 原來是還沒打完XDDDDDDDD
※ 編輯: iceonly (210.202.62.118), 03/05/2015 22:37:45