不一樣的模板模式(設計模式十一)

前言

這個補一章，因爲當時覺得很簡單所以就跳過了，所以補齊十一。

什麼是模板模式呢？這是一個晚綁定非常好的體現。把定義抄一下哈：一個抽象類公開定義了執行它的方法的方式/模板。它的子類可以按需要重寫方法實現，但調用將以抽象類中定義的方式進行。這種類型的設計模式屬於行爲型模式。

這節主要介紹一下晚綁定是啥，增強理解，這個模式很簡單的。

正文

就是有這樣一個場景:

public abstract class Library{
   abstract void part1();
   bool part2()
   {
       return xx;//xx 表示true 或者false
   }
   void part3()
   {
   }
}

public class Appliaction:Library{
   override void part1(){
      //具體實現
   }
}

然後呢,main中這樣調用的。

Appliaction appliaction=new Appliaction();
appliaction.part1();
//一些操作
if(appliaction.part2())
{
   appliaction.part3();
}

如果:

appliaction.part1();
//一些操作
if(appliaction.part2())
{
   appliaction.part3();
}

是穩定的，那麼可以提取到Appliaction中，那麼可以這樣:

public abstract class Application{
   override void part1()
  {
  }
   void run()
   {
      part1();
     //一些操作
     if(part2())
     {
        part3();
     }
   }
}

這樣做就好了點，但是最好能放在Library中。

因爲application 調用的是library 中的函數，因爲application 比library 晚實現，那麼調用早實現的，就是晚綁定,反過來就是早綁定了。

如果這樣的話，會跟好一點:

public abstract class Library{
   abstract void part1();
   bool part2()
   {
       return xx;//xx 表示true 或者false
   }
   void part3()
   {
   }
   void run()
   {
      part1();
     //一些操作
     if(part2())
     {
        part3();
     }
   }
}

那麼問題來了，爲什麼晚綁定比早綁定好？

因爲如果把具體實現放在子類中，可以不改變某種算法即可定義該算法的某種步驟，也就是說run 方法放在了一個穩定的類中封裝起來了。

可能這樣在library 和application中不好理解，那麼在main 和application 那個變化中就很好理解了，如果把步驟放在main中，做同樣的操作，是不是又要寫一遍。

然後放在application中，如果run是穩定的，那麼是不是library 的繼承類是不是又要寫一遍？這樣複用性，可讀性，還有維護性都降低了很多。