Questions tagged «singleton»

有人认为单例模式始终是反模式。你怎么看？

65 design-patterns  singleton 

我的同事们喜欢说“日志记录/缓存/等是一个跨领域的问题”，然后继续在各处使用相应的单例。但是他们喜欢IoC和DI。 违反SOLI D原则真的是一个合理的借口吗？

43 dependency-injection  solid  anti-patterns  singleton 

我对单例模式有不同的看法。一些人主张应不惜一切代价避免使用它，而另一些人则认为在某些情况下它可能是有用的。 我使用单例的一种情况是当我需要一个工厂（假设类型F的对象f）来创建某个类A的对象时。工厂使用一些配置参数创建一次，然后每次使用类型A被实例化。因此，要实例化A的代码的每个部分都获取单例f并创建新实例，例如 F& f = F::instance(); boost::shared_ptr<A> a = f.createA(); 所以我的一般情况是 出于优化原因（不需要多个工厂对象）或共享公共状态（例如，工厂知道仍可以创建A的实例），我只需要一个类的实例即可 我需要一种方法可以在代码的不同位置访问F的此实例f。 我对讨论此模式的好坏不感兴趣，但是假设我想避免使用单例，我还可以使用其他什么模式？ 我的想法是（1）从注册表获取工厂对象，或（2）在程序启动期间的某个时候创建​​工厂，然后将工厂作为参数传递。 在解决方案（1）中，注册表本身是一个单例，因此我刚刚将不使用单例的问题从工厂转移到了注册表。 在情况（2）中，我需要工厂对象来自的一些初始源（对象），因此恐怕我会再次落入另一个单例（提供我的工厂实例的对象）。通过跟踪此单身人士链，我可以将问题简化为一个单身人士（整个应用程序），通过它 可以直接或间接管理所有其他单身人士。 最后一种选择（使用一个初始单例创建所有其他唯一对象并将所有其他单例注入正确的位置）是否可以接受？当有人建议不要使用单例时，这是隐式建议的解决方案，还是其他解决方案，例如在上述示例中？ 编辑 由于我认为我的问题的重点已经被某些人误解了，因此这里提供了更多信息。如所解释的，例如这里，词语 单可指示（a）中的一类具有单个实例对象和（b）用于创建和访问这样的对象的设计模式。 为了使事情更清楚，让我们对（a）使用术语唯一对象， 对（b）使用术语单例模式。因此，我知道单例模式和依赖项注入是什么（顺便说一句，最近我一直在大量使用DI从我正在处理的某些代码中删除单例模式的实例）。 我的观点是，除非整个对象图都是从位于main方法堆栈上的单个对象实例化的，否则始终需要通过singleton模式访问一些唯一的对象。 我的问题是，完整的对象图创建和连接是否取决于主要方法（例如，通过一些不使用模式本身的强大DI框架）是唯一的无 单例模式解决方案。

27 design-patterns  programming-practices  anti-patterns  singleton 

在我的某些代码中，我有一个类似于以下内容的静态工厂： public class SomeFactory { // Static class private SomeFactory() {...} public static Foo createFoo() {...} public static Foo createFooerFoo() {...} } 在代码审查期间，建议将其作为一个单例并注入。因此，它应如下所示： public class SomeFactory { public SomeFactory() {} public Foo createFoo() {...} public Foo createFooerFoo() {...} } 需要强调的几件事： 两个工厂都是无状态的。 方法之间的唯一区别是它们的范围（实例与静态）。实现是相同的。 Foo是没有接口的bean。 我要静态化的参数是： 该类是无状态的，因此不需要实例化 能够调用静态方法比必须实例化工厂似乎更自然。 工厂作为单例的参数是： 注入一切都很好 尽管工厂是无状态的，但使用注入进行测试还是比较容易的（易于模拟） 测试消费者时应该嘲笑它 …

24 java  design-patterns  singleton  factory-method 

我一直在听说要为我的同事在Singleton上使用依赖项注入。我仍然无法确定它们是否是可以互相替换的两个正交图案？还是DI是使Singleton模式可测试的方法？ 请看下面的代码片段。 IMathFace obj = Singleton.Instance; SingletonConsumer singConsumer = new SingletonConsumer(obj); singConsumer.ConsumerAdd(10,20); 所述SingletonConsumer正在接受类型的参数IMathFace。而不是在内部访问singleton类，而是SingletonConsumer将获得调用者传递的singleton实例。这是通过依赖注入使用单例类的一个好例子吗？

17 c#  architecture  singleton 

传统上，单例通常实现为 public class Foo1 { private static final Foo1 INSTANCE = new Foo1(); public static Foo1 getInstance(){ return INSTANCE; } private Foo1(){} public void doo(){ ... } } 使用Java的枚举，我们可以实现单例为 public enum Foo2 { INSTANCE; public void doo(){ ... } } 与第二版一样出色，它有什么缺点吗？ （我考虑了一下，我会回答我自己的问题；希望您有更好的答案）

14 java  singleton  enum 

我正在开发RESTful API，我认为为我的资源使用DAO会很方便，因为尽管我计划仅使用内存来存储它们，但是我不想对使用库的任何人敞开大门，如果他们决定使用DAO的数据库实现。 我的问题是DAO是否应为单例。如果不是，则该服务将具有DAO的实例，并且看起来大致如下： @Path("eventscheduler") public class EventSchedulerService { private IEventSchedulerDao dao = new EventSchedulerDao(); // in case a different implementation is to be used public void setEventSchedulerDao(IEventSchedulerDao dao) { this.dao = dao; } @Path("{uniqueName}") @GET @Produces(MediaType.APPLICATION_JSON) public Tournament getTournament(@PathParam("name") String uniqueName) { return dao.get(uniqueName); } @Path("create") @POST @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public …

14 java  design  design-patterns  singleton  dao 

我正在学习C ++中的OOP，即使我知道这3个概念的定义，我也无法真正意识到何时或如何使用它。 让我们以此类为例： class Person{ private: string name; int age; public: Person(string p1, int p2){this->name=p1; this->age=p2;} ~Person(){} void set_name (string parameter){this->name=parameter;} void set_age (int parameter){this->age=parameter;} string get_name (){return this->name;} int get_age (){return this->age;} }; 1. 单身人士 类的限制如何只有一个对象起作用？ CAN你设计一个类，将有只有 2个实例？也许3？ 何时 /建议何时使用单例？这是好习惯吗？ 2. 抽象类 据我所知，如果只有一个纯虚函数，则该类将变为抽象。因此，添加 virtual void print ()=0; 会做到的，对吧？ 为什么需要一个不需要其对象的类？ …

13 c++  object-oriented  singleton  class  abstract-class 

我目前有4个月的实习期，在查看我的代码时，我的老板不喜欢我在一个程序集中几个单独的类中的多个方法中保留了一个特定的对象。他不喜欢每次都创建一个新对象，而是告诉我创建一个可以从任何地方访问的对象。因此，我不得不将其创建为静态类中的静态对象，并从此处引用它以使用它！ 我只从事4个月的专业编程，您将如何处理呢？

13 teamwork  coding-standards  singleton 

有时我遇到这些消息中心式的API，例如Cocoa NSNotificationCenter：http : //developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSNotificationCenter_Class/Reference/Reference.html 通常，这些API提供您在其上订阅或广播消息/事件的全局访问点。我认为这是一个问题，因为它鼓励使用扁平且非结构化的程序体系结构，其中的依赖关系在API中不是显式的，而在源代码中则是隐藏的。您不必考虑对象的所有权和层次结构，而可以使程序中的任何对象导致在任何地方调用任何代码。但这也许是一件好事吗？ 这种模式通常会鼓励程序设计的好坏，为什么呢？它会使代码更难或更容易测试吗？ 如果这个问题太模糊或太宽泛，请原谅我。我正在努力避免像这样大量使用API​​的潜在后果以及使用它的不同方式。 编辑：我猜想我最大的问题是这种API依赖于依赖关系和对象耦合，并且可以通过以下示例进行说明： myObj = new Foo(); myOtherObj = new Bar(); print myOtherObj.someValue; // prints 0 myObj.doSomething(); print myOtherObj.someValue; // prints 1, unexpectedly, because I never indicated that these objects had anything to do with each other

13 design  testing  architecture  singleton 

最近，有人针对单身人士进行了某种革命，但是如果他们是无国籍的，他们有什么问题吗？ 我知道过度使用的话题以及所有...这不仅适用于单例，还适用于所有情况。

12 design-patterns  object-oriented  singleton  immutability 

问题 我最近阅读了很多有关Singletons不好以及依赖注入（我理解为“使用接口”）如何更好的知识。当我使用callbacks / interfaces / DI并遵循接口隔离原则来实现其中的一部分时，我最终陷入了混乱。 UI父级的依赖关系基本上是其所有子级的依赖关系的组合，因此，UI元素的层次结构越深，其构造函数就越肿。 在UI层次结构之上一直是一个Application类，其中包含有关当前选择的信息以及对需要反映更改的3d模型的引用。该应用程序类实现了8个接口，而这仅仅是即将推出的产品（/接口）的五分之一！ 我目前正在处理持有当前选择的单例，并且UI元素具有自我更新的功能。该函数滴入UI树和UI元素，然后根据需要访问当前选择单例。这种代码对我来说似乎更干净。 问题 单身人士可能适合该项目吗？ 如果没有，那么我的DI思维和/或实施过程中是否存在根本的缺陷，从而使其变得如此繁琐？ 有关项目的其他信息 类型：带铃铛的公寓用购物篮 大小：代码和UI 维护2个工作月：没有正在运行的更新，但以后可能是“版本2.0” 环境：在Unity中使用C＃（使用实体）组件系统 在几乎所有情况下，用户交互都会触发多个操作。例如，当用户选择一个项目时 显示该项目及其说明的UI部分需要更新。为此，它还需要从3D模型中获取一些信息才能计算价格。 在使用者介面的上方，总价格需要更新 为了显示那里的变化，需要调用3d模型上的类中的相应函数

8 c#  dependency-injection  singleton