为什么我需要Singleton设计模式？

我尝试学习设计模式,但真的很难理解OOD的主要思想.我用经典方法创建了我的软件.另一方面,我想学习OOD.为什么我需要单身人士和其他人？我编写了一些简单的程序:其中一个是clasical(我的风格),另一个是singleton模式.请教我为什么需要单身.我的方法比它更好更清晰:)

我的风格:(C#)

  public partial class Singletonsuz : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        Loadbalancer balancer = new Loadbalancer();

        for (int i = 0 ; i < 15 ; i++)
        {
            string server = balancer.Server;
            Response.Write("Dispatch Request to: " + server);
        }
    }
}
class Loadbalancer
{
    private List _servers = new List();
    private Random _random = new Random();
    public Loadbalancer()
        {
            _servers.Add("ServerI");
            _servers.Add("ServerII");
            _servers.Add("ServerIII");
            _servers.Add("ServerIV");
            _servers.Add("ServerV");
        }
    public string Server
    {
        get
        {
            int r = _random.Next(_servers.Count);
            return _servers[r].ToString();
        }
    }
}

辛格尔顿:

    public partial class SingletonDP2 : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            LoadBalancer balancer = LoadBalancer.GetLoadBalancer();
            for (int i = 0; i < 15; i++)
            {
                string server = balancer.Server;
                Response.Write("Dispatch Request to: " + server );
            }
        }

        class LoadBalancer
        {
            private static LoadBalancer _instance;
            private List _servers = new List();
            private Random _random = new Random();

            private static object syncLock = new object();
            protected LoadBalancer()
            {
                _servers.Add("ServerI");
                _servers.Add("ServerII");
                _servers.Add("ServerIII");
                _servers.Add("ServerIV");
                _servers.Add("ServerV");
            }

            public static LoadBalancer GetLoadBalancer()
            {
                if (_instance == null)
                {
                    lock (syncLock)
                    {
                        if (_instance == null)
                        {
                            _instance = new LoadBalancer();
                        }
                    }
                }
                return _instance;
            }

            public string Server
            {
                get
                {
                    int r = _random.Next(_servers.Count);
                    return _servers[r].ToString();
                }
            }
        }
    }

fbonnet.. 28

设计模式不是设计或开发方法.它们是一个词汇表:它们有助于将名称放在软件架构中出现的重复模式上.根据我的经验,设计软件FROM模式最终会出现在多毛的软件中,并且有很多单一用途的类,这增加了程序员必须考虑的事情数量(并且软件开发很复杂,足以避免让你的大脑充满噪音).

然而,设计模式在后期非常方便.始终从您的特定问题和域开始,尝试找到解决方案,并识别流程中的模式.不要从模式开始,尝试将问题强制适应它们.了解最常见的模式是必须的,因为它可以简化程序员(无论是开发人员还是图书馆用户)之间的沟通,并促进良好实践.

例如,假设您的问题涉及数据集.在某些时候,您已经构建了数据结构和算法.现在,您(或其他人)需要以更高级别的方式访问您的数据.这是Iterator或Visitor模式可以应用的典型情况.这就是在C++ STL中完成的方式,其中所有集合类都理解迭代器.但是,您不需要事先考虑可能会或可能不适用于此处或那里的模式,一旦确定了模式或需求,总会有时间重构事物.

设计模式最初来自建筑和架构,它们在很多方面与软件开发非常相似.根据我的经验,理解DP的最佳方式是通过类比建筑:软件是建筑,模式是建筑元素的组织方式:窗户,门,走廊,楼梯,灯......建筑师不考虑他们的元素想要使用,但想想他们想要得到的效果.例如,建筑师可能会想:这个楼梯需要光线.为了达到这个目的,他可以根据建筑限制,建筑规范,客户的品味等使用窗户,天窗,玻璃砖,人造灯等.在考虑他试图解决的问题之前,他不会随意选择元素.解决,除非他试图达到效果或风格.此外,如果市场上有另一种解决方案(例如反光阳光隧道),那么他可以将其整合到他未来项目的可用设计模式中.如果OTOH在考虑问题之前养成了思考解决方案的习惯,他就会冒险错过替代解决方案,使问题复杂化,或根本不解决问题.

在这里,您使用Singleton模式来看似需要动态初始化的全局对象.在这种情况下,Singleton是一个可接受的解决方案.但是,由于外部约束(例如,您需要按特定顺序初始化对象),有时您需要更复杂的解决方案,而Singleton将不再适用.或者对象只需要静态初始化,而普通的全局变量就可以满足您的需求.

过度使用设计模式与在需要它们的地方不使用它们一样糟糕.选择是否使用某种模式需要具备软件设计和开发的知识和经验,特别是您的领域.

1> fbonnet..：

---

设计模式不是设计或开发方法.它们是一个词汇表:它们有助于将名称放在软件架构中出现的重复模式上.根据我的经验,设计软件FROM模式最终会出现在多毛的软件中,并且有很多单一用途的类,这增加了程序员必须考虑的事情数量(并且软件开发很复杂,足以避免让你的大脑充满噪音).

然而,设计模式在后期非常方便.始终从您的特定问题和域开始,尝试找到解决方案,并识别流程中的模式.不要从模式开始,尝试将问题强制适应它们.了解最常见的模式是必须的,因为它可以简化程序员(无论是开发人员还是图书馆用户)之间的沟通,并促进良好实践.

例如,假设您的问题涉及数据集.在某些时候,您已经构建了数据结构和算法.现在,您(或其他人)需要以更高级别的方式访问您的数据.这是Iterator或Visitor模式可以应用的典型情况.这就是在C++ STL中完成的方式,其中所有集合类都理解迭代器.但是,您不需要事先考虑可能会或可能不适用于此处或那里的模式,一旦确定了模式或需求,总会有时间重构事物.

设计模式最初来自建筑和架构,它们在很多方面与软件开发非常相似.根据我的经验,理解DP的最佳方式是通过类比建筑:软件是建筑,模式是建筑元素的组织方式:窗户,门,走廊,楼梯,灯......建筑师不考虑他们的元素想要使用,但想想他们想要得到的效果.例如,建筑师可能会想:这个楼梯需要光线.为了达到这个目的,他可以根据建筑限制,建筑规范,客户的品味等使用窗户,天窗,玻璃砖,人造灯等.在考虑他试图解决的问题之前,他不会随意选择元素.解决,除非他试图达到效果或风格.此外,如果市场上有另一种解决方案(例如反光阳光隧道),那么他可以将其整合到他未来项目的可用设计模式中.如果OTOH在考虑问题之前养成了思考解决方案的习惯,他就会冒险错过替代解决方案,使问题复杂化,或根本不解决问题.

在这里,您使用Singleton模式来看似需要动态初始化的全局对象.在这种情况下,Singleton是一个可接受的解决方案.但是,由于外部约束(例如,您需要按特定顺序初始化对象),有时您需要更复杂的解决方案,而Singleton将不再适用.或者对象只需要静态初始化,而普通的全局变量就可以满足您的需求.

过度使用设计模式与在需要它们的地方不使用它们一样糟糕.选择是否使用某种模式需要具备软件设计和开发的知识和经验,特别是您的领域.

2> Ricardo Amor..：

---

你真的不需要模式.您需要的是解决具体问题的方法.模式只是众所周知的问题的通用解决方案,因此被认为是良好的工作解决方案.

模式的问题在于您可以轻松地找到自己在解决方案中寻找问题.即你开始搜索适合问题的模式,当你应该反思时:想想问题,然后尝试你的解决方案是否符合模式.

当你有锤子时,一切看起来像钉子......

3> Greg Hewgill..：

---

Singleton模式被广泛认为并非真正的模式.它更像是一个人如何呈现模式的例子.

您可能会发现更常用的模式(如访问者)更有用.

---

广泛认为不是一种模式？不会这么说,这不是博客文章所说的.潜在有害吗？这更像是它,但那么一切都在错误的时间或错误的数量,包括水.

4> ShuggyCoUk..：

---

单身人士通常只是用来证明一些全球国家的存在.

如果你有全局状态接受它并且不觉得需要将它包装在像singleton这样的模式中,除非在以下有限的情况下:

您正在从图书馆展示这个全球状态.

如果您将其公开为普通的公共静态字段,那么改变您依赖全局状态(可能发生的事情)的决定可能变得非常困难.

在那些情况下,将外部世界的价值呈现为不是单身人士,而是作为默认情况,恰好是静态定义将允许设计的变化(并且不鼓励API的用户将其视为仅仅是唯一的实例).

这实际上只是您目前正在实施的工厂

因此,构造的"隐藏"是重要的部分,而不是返回值的全局性质.

如果类的使用者是同一构建过程的一部分(即如果以某种方式更改类,受影响的代码将在下一个构建中直接受到影响)那么需要执行此包装以允许更改是没有意义的因为你可以根据需要直接改变它.这是"你不需要它"指南的应用.