一. 责任链模式

1. 背景

在现实生活中，常常会出现这样的事例：一个请求有多个对象可以处理，但每个对象的处理条件或权限不同。例如，公司员工请假，可批假的领导有部门负责人、副总经理、总经理等，但每个领导能批准的天数不同，员工必须根据自己要请假的天数去找不同的领导签名，也就是说员工必须记住每个领导的姓名、电话和地址等信息，这增加了难度。这样的例子还有很多，如找领导出差报销、生活中的“击鼓传花”游戏等。

2. 定义和特点

(1). 定义：为了避免请求发送者与多个请求处理者耦合在一起，将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。

PS：责任链模式也叫职责链模式。在责任链模式中，客户只需要将请求发送到责任链上即可，无须关心请求的处理细节和请求的传递过程，所以责任链将请求的发送者和请求的处理者解耦了。

(2). 优点：

　A. 降低了对象之间的耦合度。该模式使得一个对象无须知道到底是哪一个对象处理其请求以及链的结构，发送者和接收者也无须拥有对方的明确信息。

　B. 增强了系统的可扩展性。可以根据需要增加新的请求处理类，满足开闭原则。

　C. 增强了给对象指派职责的灵活性。当工作流程发生变化，可以动态地改变链内的成员或者调动它们的次序，也可动态地新增或者删除责任。

　D. 责任链简化了对象之间的连接。每个对象只需保持一个指向其后继者的引用，不需保持其他所有处理者的引用，这避免了使用众多的 if 或者 if···else 语句。

　E. 责任分担。每个类只需要处理自己该处理的工作，不该处理的传递给下一个对象完成，明确各类的责任范围，符合类的单一职责原则。

(3). 缺点：

　A. 不能保证每个请求一定被处理。由于一个请求没有明确的接收者，所以不能保证它一定会被处理，该请求可能一直传到链的末端都得不到处理。

　B. 对比较长的职责链，请求的处理可能涉及多个处理对象，系统性能将受到一定影响。

　C. 职责链建立的合理性要靠客户端来保证，增加了客户端的复杂性，可能会由于职责链的错误设置而导致系统出错，如可能会造成循环调用。

3. 具体实现

(1). 模式结构

　A. 抽象处理者：定义一个处理请求的接口，包含抽象处理方法和一个后继连接。

　B. 具体处理者：实现抽象处理者的处理方法，判断能否处理本次请求，如果可以处理请求则处理，否则将该请求转给它的后继者。

　C. 客户端调用：创建处理链，并向链头的具体处理者对象提交请求，它不关心处理细节和请求的传递过程。

结构图如下：

(2). 使用场景

　员工请假，不同的天数需要被不同级别的领导批准，这个时候可以采用责任链模式。每个领导都是一个具体的请假处理者，同时提炼出来一个抽象处理者，包括：请假处理方法和下一个节点，最后由客户端建立责任链，并将请求传递进去。

更多C++后台开发技术点知识内容包括C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，MongoDB，ZK，流媒体，音视频开发，Linux内核，TCP/IP，协程，DPDK多个高级知识点。

C/C++Linux服务器开发高级架构师/C++后台开发架构师免费学习地址

【文章福利】另外还整理一些C++后台开发架构师 相关学习资料，面试题，教学视频，以及学习路线图，免费分享有需要的可以点击领取

(3). 代码实操

请假请求类：

    /// <summary>
    /// 请假请求类
    /// </summary>
    public class LeaveRequest
    {
        /// <summary>
        /// 姓名
        /// </summary>
        public string name { get; set; }

        /// <summary>
        /// 请假天数
        /// </summary>
        public int leaveDays { get; set; }

    }

抽象处理者和具体处理者：

    /// <summary>
    /// 抽象处理者角色
    /// </summary>
    public abstract class AbstractHandler
    {
        /// <summary>
        /// 代表责任链中的下一个角色
        /// </summary>
        public AbstractHandler NextHandler { get; set; }

        /// <summary>
        /// 处理请假请求
        /// </summary>
        public abstract void HandleRequest(LeaveRequest request);
    }
 /// <summary>
    /// 直接领导(一级领导)
    /// </summary>
    public class LeaderHandler1 : AbstractHandler
    {
        /// <summary>
        /// 处理请假请求
        /// </summary>
        public override void HandleRequest(LeaveRequest request)
        {
            if (request.leaveDays<=3)
            {
                Console.WriteLine($"直接领导(一级领导)已经批准{request.name}的请假请求,请假天数：{request.leaveDays}");
            }
            else
            {
                if (this.NextHandler!=null)
                {
                    this.NextHandler.HandleRequest(request);
                }
                else
                {
                    Console.WriteLine($"{request.name}请假天数太多，没有人批准该假条！");
                }
            }
            
        }
    }
 /// <summary>
    /// 二级领导
    /// </summary>
    public class LeaderHandler2 : AbstractHandler
    {
        /// <summary>
        /// 处理请假请求
        /// </summary>
        public override void HandleRequest(LeaveRequest request)
        {
            if (request.leaveDays > 3 && request.leaveDays <= 7)
            {
                Console.WriteLine($"二级领导已经批准{request.name}的请假请求,请假天数：{request.leaveDays}");
            }
            else
            {
                if (this.NextHandler != null)
                {
                    this.NextHandler.HandleRequest(request);
                }
                else
                {
                    Console.WriteLine($"{request.name}请假天数太多，没有人批准该假条！");
                }
            }

        }
    }
 /// <summary>
    /// 最高领导(三级)
    /// </summary>
    public class LeaderHandler3 : AbstractHandler
    {
        /// <summary>
        /// 处理请假请求
        /// </summary>
        public override void HandleRequest(LeaveRequest request)
        {
            if (request.leaveDays > 7 && request.leaveDays <= 30)
            {
                Console.WriteLine($"最高领导(三级)已经批准{request.name}的请假请求,请假天数：{request.leaveDays}");
            }
            else
            {
                if (this.NextHandler != null)
                {
                    this.NextHandler.HandleRequest(request);
                }
                else
                {
                    Console.WriteLine($"{request.name}请假天数太多，没有人批准该假条！");
                }
            }

        }
    }

客户单创建责任链并调用：

                //1. 有人要请假
                LeaveRequest myRequest1 = new LeaveRequest() { 
                    name="小明",
                    leaveDays=6
                };
                LeaveRequest myRequest2 = new LeaveRequest()
                {
                    name = "小王",
                    leaveDays = 2
                };
                LeaveRequest myRequest3 = new LeaveRequest()
                {
                    name = "小放",
                    leaveDays = 15
                };
                LeaveRequest myRequest4 = new LeaveRequest()
                {
                    name = "张三",
                    leaveDays = 35
                };

                //2. 请假相关的责任链
                LeaderHandler1 handler1 = new LeaderHandler1();
                LeaderHandler2 handler2 = new LeaderHandler2();
                LeaderHandler3 handler3 = new LeaderHandler3();
                handler1.NextHandler = handler2;
                handler2.NextHandler = handler3;

                //3.进行请假处理
                handler1.HandleRequest(myRequest1);
                handler1.HandleRequest(myRequest2);
                handler1.HandleRequest(myRequest3);
                handler1.HandleRequest(myRequest4);

测试结果：

4. 适用场景分析

　(1). 有多个对象可以处理一个请求，哪个对象处理该请求由运行时刻自动确定。

　(2). 可动态指定一组对象处理请求，或添加新的处理者。

　(3). 在不明确指定请求处理者的情况下，向多个处理者中的一个提交请求。

二. 迭代器模式

1. 背景

　 在现实生活以及程序设计中，经常要访问一个聚合对象中的各个元素，如【数据结构】中的链表遍历，通常的做法是将链表的创建和遍历都放在同一个类中，但这种方式不利于程序的扩展，如果要更换遍历方法就必须修改程序源代码，这违背了 “开闭原则”。既然将遍历方法封装在聚合类中不可取，那么聚合类中不提供遍历方法，将遍历方法由用户自己实现是否可行呢？答案是同样不可取，因为这种方式会存在两个缺点：

　A. 暴露了聚合类的内部表示，使其数据不安全；

　B. 增加了客户的负担。

　“迭代器模式”能较好地克服以上缺点，它在客户访问类与聚合类之间插入一个迭代器，这分离了聚合对象与其遍历行为，对客户也隐藏了其内部细节，且满足“单一职责原则”和“开闭原则”。比如C#中的List就实现了迭代器模式。

2. 定义和特点

(1). 定义：提供一个对象来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

(2). 优点：

　A. 访问一个聚合对象的内容而无须暴露它的内部表示。

　B. 遍历任务交由迭代器完成，这简化了聚合类。

　C. 它支持以不同方式遍历一个聚合，甚至可以自定义迭代器的子类以支持新的遍历。

　D. 增加新的聚合类和迭代器类都很方便，无须修改原有代码。

　E. 封装性良好，为遍历不同的聚合结构提供一个统一的接口。

(3). 缺点：

　增加了类的个数，这在一定程度上增加了系统的复杂性

3. 具体实现

(1). 模式结构

　迭代器模式是通过将聚合对象的遍历行为分离出来，抽象成迭代器类来实现的，其目的是在不暴露聚合对象的内部结构的情况下，让外部代码透明地访问聚合的内部数据。

　A. 抽象聚合（Aggregate）角色：定义存储、添加、删除聚合对象以及创建迭代器对象的接口。

　B. 具体聚合（ConcreteAggregate）角色：实现抽象聚合类，返回一个具体迭代器的实例。

　C. 抽象迭代器（Iterator）角色：定义访问和遍历聚合元素的接口，通常包含 hasNext()、first()、next() 等方法。

　D. 具体迭代器（Concretelterator）角色：实现抽象迭代器接口中所定义的方法，完成对聚合对象的遍历，记录遍历的当前位置。

结构如下图：

(2). 使用场景

　 见下面代码模拟。

(3). 代码实操

聚合接口和具体的聚合类

    /// <summary>
    /// 抽象聚合接口
    /// </summary>
    public interface IAggregate<T>
    {
        public void Add(T obj);
        public void Remove(T obj);

        /// <summary>
        /// 获取聚合对象的迭代器
        /// </summary>
        /// <returns></returns>
        public Iterator<T> GetIterator();

    }
    /// <summary>
    /// 具体聚合
    /// </summary>
    public class ConcreteAggregate<T> : IAggregate<T>
    {
        private List<T> list = new List<T>();

        public void Add(T obj)
        {
            list.Add(obj);
        }
        public void Remove(T obj)
        {
            list.Remove(obj);
        }
        /// <summary>
        /// 获取迭代器
        /// </summary>
        /// <returns></returns>
        public Iterator<T> GetIterator()
        {
            return new ConcreteIterator<T>(list);
        }
   
    }

抽象迭代器和具体的迭代器

   /// <summary>
    /// 抽象迭代器
    /// </summary>
    public interface Iterator<T>
    {
        T First();
        T Next();
        bool HasNext();
    }
    /// <summary>
    /// 具体的迭代器
    /// </summary>
    /// <typeparam name="T"></typeparam>
    public class ConcreteIterator<T> : Iterator<T>
    {
        private List<T> list = null;
        private int index = 0;
        public ConcreteIterator(List<T> myList)
        {
            this.list = myList;
        }

        public T First()
        {
            return list[0];
        }

        public bool HasNext()
        {
            if (index<list.Count-1)
            {
                return true;
            }
            else
            {
                return false;
            }
        }

        public T Next()
        {
            T obj =default(T);
            if (this.HasNext())
            {
                obj = list[++index];
            }
            return obj;
        }
    }

测试

{
                //聚合对象添加数据
                IAggregate<string> ag = new ConcreteAggregate<string>();
                ag.Add("001");
                ag.Add("002");
                ag.Add("003");
                ag.Add("004");
                //获取对应的迭代器
                Iterator<string> it = ag.GetIterator();
                //输出数据
                Console.WriteLine($"第一个元素为:{it.First()}");
                Console.WriteLine("剩下的元素为：");
                while (it.HasNext())
                {
                    Console.WriteLine(it.Next());
                }
}

运行结果

4. 适用场景分析

　(1). 当需要为聚合对象提供多种遍历方式时。

　(2). 当需要为遍历不同的聚合结构提供一个统一的接口时。

　(3). 当访问一个聚合对象的内容而无须暴露其内部细节的表示时。

PS: 由于聚合与迭代器的关系非常密切，所以大多数语言在实现聚合类时都提供了迭代器类，因此大数情况下使用语言中已有的聚合类的迭代器就已经够了。

原文链接：https://www.cnblogs.com/yaopengfei/p/13489597.html