通俗易懂設計模式解析——觀察者模式

前言

　　今天咱們一塊兒看看這個觀察者模式，這個模式簡單來講就是一個發佈訂閱相似的模式。按照名字來理解也就是存在一個觀察者和一個被觀察者。說幾個例子給你們聽，你們應該就明白了。例如在咱們如今經過銀行卡支付以後，會收到銀行發過來的提示信息。例如當咱們話費餘額或者流量不足之時也會收到提示信息。這其中的邏輯幫咱們理解觀察者模式。當咱們觀察的一個對象發送變化之時就會觸發某一機制。而後作出一系列的措施。

觀察者模式介紹

1、來由

　　在軟件系統中咱們常常會遇到對象之間存在一對多的關係，當一個對象被修改時，將會自動通知其依賴的對象。固然若是這些依賴關係過於緊密對於系統來講又很差抵禦其變化。因此咱們又須要實現其結構的鬆耦合。

2、意圖

　　定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，全部依賴於它的對象都獲得通知並被自動更新。

3、案例圖

 

4、觀察者代碼示例

看上面的案例圖、咱們來細細說下這其中的四種角色：

抽象主題角色：將全部的觀察者引用保存在一個列表，同時包含增長刪除觀察者的操做，包含調用抽象觀察者的操做方法。

具體主題角色：實現其抽象主題的抽象方法。

抽象觀察者：爲全部的具體觀察者定義一個接口，在獲得主題通知時更新本身。

具體觀察者：實現抽象觀察者定義的接口，是自身的狀態與主題的狀態相對應。

到這裏咱們簡單的介紹了下觀察這模式的原理。咱們接下來使用手機話費不足時短信提醒這一個案例來說述觀察者模式的代碼示例吧，當咱們手機話費低於或小於10元的時候，將會觸發變化更新提示：

 

namespace Observer_Pattern
{
    class ObserverPattern
    {
    }

    /// <summary>
    /// 抽象主題角色（將全部觀察者對象的引用保存在一個列表中、含有增長和刪除觀察者對象操做、包含調用抽象觀察者的變動操做）
    /// </summary>
    public abstract class Subject
    {
        internal List<Observer> observers ;
        internal int Balance;
        /// <summary>
        /// 保存全部觀察者對象
        /// </summary>
        public Subject(int balance)
        {
            observers = new List<Observer>();
            Balance = balance;
        }

        /// <summary>
        /// 增長觀察者對象
        /// </summary>
        public abstract void Adds(Observer observer);

        /// <summary>
        /// 刪除觀察者對象
        /// </summary>
        public abstract void Removes(Observer observer);

        /// <summary>
        /// 通知觀察者變化
        /// </summary>
        public void Notice() 
        {
            foreach (var item in observers)
            {
                if (item!=null)
                {
                    item.Change(this);
                }
            }
        }
    }

    /// <summary>
    /// 抽象觀察者（爲全部具體觀察者提供了一個當主題通知是變動本身的操做）
    /// </summary>
    public abstract class Observer
    {
        
       
        public abstract void Change(Subject Item);
    }

    /// <summary>
    /// 具體主題角色，實現抽象角色抽象方法
    /// </summary>
    public class CallChargeSubject : Subject
    {
        public CallChargeSubject( int balance) : base( balance )
        {

        }
       
        public override void Adds(Observer observer)
        {
            observers.Add(observer);
        }

       

        public override void Removes(Observer observer)
        {
            observers.Remove(observer);
        }
    }

    /// <summary>
    /// 具體觀察者
    /// </summary>
    public class CallChargeObserver : Observer
    {
        internal string Name;
        public CallChargeObserver(string name)  
        {
            Name = name;
        }
        public override void Change(Subject Item)
        {
            Console.WriteLine($"{Name}您好，您當前話費餘額爲：{Item.Balance},爲了不後續爲您帶來不便請及時充值!");
        }
    }
}

 

namespace Observer_Pattern
{
    class Program
    {
        static void Main(string[] args)
        {
            Subject subject = new CallChargeSubject(10);
            subject.Adds(new CallChargeObserver("張三"));
            subject.Adds(new CallChargeObserver("李四"));
            subject.Notice();
        }
    }
}

 

使用場景及優缺點

1、使用場景

一、一個抽象模型有兩個方面，其中一個方面依賴於另外一個方面。將這些方面封裝在獨立的對象中使它們能夠各自獨立地改變和複用

二、當對一個對象的改變須要同時作出改變的時候，而又不知道具體有多少對象須要待改變的狀況下。

三、一個對象必須通知其餘對象，可是並不知道這些對象是誰。

2、優勢

一、觀察者和被觀察者直接鬆耦合，依賴於抽象而不是具體實現

二、創建了一套觸發的訂閱發佈機制。

3、缺點

一、若是一個被觀察者有不少觀察者的話，變化通知全部觀察者須要花費不少的時間

二、觀察者和被觀察者之間有循環依賴的話，變化觸發以後會形成循環調用。會致使系統崩潰。

三、觀察者只知道被觀察者發生了變化，可是並不知道被觀察者是如何發生變化的。

總結

　　到這裏咱們就介紹完了觀察者模式，這個模式是一種一對多的關係依賴。若是不使用抽象主題角色和抽象觀察者也是能夠實現監控話費的任務的，可是這樣會形成主題角色和觀察者角色緊耦合。觀察者模式主要實現的就是解耦代碼，實現依賴倒置原則。依賴於抽象而不是具體實現。再說觀察者模式、在我前面的文章又寫過委託與事件，其中提到了事件基於委託，爲委託提供了一種發佈/訂閱機制。咱們仔細研究能夠發現觀察者模式和委託仍是較爲類似的。

 

---

 這個社會是存在不公平的，不要抱怨，由於沒有用！人老是在檢討中進步的！

 　　  C#設計模式系列目錄

　　   歡迎你們掃描下方二維碼，和我一塊兒踏上設計模式的闖關之路吧!