Tag Info

Hot answers tagged

32

If one object is enough, creating an object every time is a waste, and here your boss may be right. The problem is proper access to that object. A factory-like method with proper visibility which always returns that static object is the first solution that springs to mind. Others certainly exist.


27

Some problems with enum singletons: Committing to an implementation strategy Typically, "singleton" refers to an implementation strategy, not an API specification. It is very rare for Foo1.getInstance() to publicly declare that it'll always return the same instance. If needed, the implementation of Foo1.getInstance() can evolve, for example, to return one ...


26

It has the same problems as a global variable. It gives you global accesses to mutable state. Anything that uses the Singleton is now tightly coupled to it. Try and avoid tight coupling. It makes the code hard to update. Hard to test. If your choice is a Singleton or global variable. Than at least Singleton provides lazy initialization. But ...


23

I agree that it is an anti-pattern. Why? Because it allows your code to lie about its dependencies, and you can't trust other programmers to not introduce mutable state in your previously immutable singletons. A class might have a constructor that only takes a string, so you think it is instantiated in isolation and does not have side effects. However, ...


20

The Singleton pattern is basically just a lazily initialized global variable. Global variables are generally and rightly considered evil because they allow spooky action at a distance between seemingly unrelated parts of a program. However, IMHO there is nothing wrong with global variables that are set once, from one place, as part of a program's ...


19

Why are Singleton and static method your only options? From my point of view, both options are pretty bad. Read up on the Singleton AntiPattern. Most use cases of the Singleton Pattern is incorrect. In your case, I would use an instance object and use dependency injection (if you're using a DI framework) or a Service locator/Registry pattern


19

What you want sounds like a good case for the Factory pattern. You would write something like: class LoaderFactory { public Loader getLoader() { if (environment1) return ZipLoader.getInstance(); else if (environment2) return DiskLoader.getInstance(); else return SomeOtherLoader.getInstance(); } } Each type of Loader class is a singleton, ...


18

The two main criticisms of Singletons fall into two camps from what I've observed: Singletons are misused and abused by less capable programmers and so everything becomes a singleton and you see code littered with Class::get_instance() references. Generally speaking there are only one or two resources (like a database connection for example) that qualify ...


17

1. Singleton You restrict the number of instances because the constructor will be private meaning only static methods can create instances of that class (there are other dirty tricks actually to accomplish that but let's not get carried away). Creating a class that will have only 2 or 3 instances is perfectly feasible. You should be using singleton ...


13

The only time a singleton is useful, over a simple global variable, is when you require global access and it's an error to have more than one instance. Some people use singletons to represent log files, but it's not an error to have more than one instance of your log class (for example, you might want to log to a separate file for some particular purpose: if ...


13

The purpose of a singleton is to enforce that only one instance can ever exists within a certain realm. This means that a singleton is useful if you have strong reasons to enforce singleton behavior; in practice, this is seldom the case though, and multi-processing and multi-threading certainly blur the meaning of 'unique' - is it one instance per machine, ...


11

I think he meant that you should use dependency injection to inject a single instance of the service, instead of using the classical Singleton implementation with a static accessor MySingleton.Instance. public class MySingleton { public static MySingleton Instance{get{...}}; } With the classical singleton implementation all your code depends on that ...


10

I suggest you look into using a dependency injection framework to achieve inversion of control. Your "Manager" would not be a traditional Singleton, but you would only create one through the framework configuration. The "Manager" would also not be global, but every component that would need to use it would have it assigned.


9

With a singleton class, you have more control in terms of how you manage the object that is created. First, a singleton is an object. The static method returns an instance of the object and allows you to create only a single instance, or more if you so choose. Singletons are also lazy-loaded, meaning that they are not instantiated until the first time ...


9

It always depends on the usage. I think the revolution comes from the fact, that every programmer learns this pattern as the object oriented pattern. Most forget to think about where it makes sense and where it doesn't. This, of course, is true for every pattern. Just by using patterns you don't create good code or good software. If you have a stateless ...


8

As byte points out, singletons are often overused. However, they are often over-used because they are used where a static instance would be better. From your question you seem to be implying they are the same thing or are interchangeable. They are not the same, and although they can be interchangable in some cases there is usually agood reason to prefer one ...


8

I can't comment your specific case, but using global variables is sometimes a good solution. Java's System class is full of static, global variables. But in general, if you think you're right and your boss is wrong, then why don't you ask your boss to explain why he thinks a global variable is a better solution? A plain "I don't like it" is as vague as ...


8

Most people already explained what singletons/abstract classes are. Hopefully, I'll provide a little different perspective and give some practical examples. Singletons - When you want all calling code to use a single instance of variables, for whatever reasons, you have the following options: Global variables - obviously no encapsulation, most of the code ...


8

It's a Singleton combined with a Factory Method, such that the calling code has no idea that it is dealing with a singleton, or even the class it's dealing with. Even the class itself doesn't know it's a Singleton. The factory can be mocked out, making testing possible but, within the context of the application, it is always the same object returned. I have ...


8

Why would you separate your factory from the object-type it creates? public class Foo { // Private constructor private Foo(...) {...} public static Foo of(...) { return new Foo(...); } } This is what Joshua Bloch describes as his Item 1 on page 5 of his book, "Effective Java." Java is verbose enough without adding extra classes and ...


7

Your code will be more flexible if you use a singleton. The advantage is that the code that uses the singleton doesn't need to know if it is a singleton or a transient object. Using a static class means you have to call static methods explicitly. Think about dependency injection, for example. Moreover, singleton, as a non-static class, can still implement ...


7

If well implemented, with threading in mind, a singleton will be thread safe. There are many implementations in many languages that are not thread safe - see this article by Jon Skeet regarding Singleton in C#. Most of the implementations suffer. The best ways to "work around them" is to know your language, how it works with threads and ensure the code is ...


7

This question has already be answered here The big difference between a singleton and a bunch of static methods is that singletons can implement interfaces (or derive from useful base classes, although that's less common IME), so you can pass around the singleton as if it were "just another" implementation.


7

It is a simple circular dependency during initialization, independent of the Singleton. There are three classes that instantiate each other in a cycle: A instantiates B, which instantiates C, which in turn instantiates A again, and you have an endless instantiation cycle. Another thing that needs to be evaluated is why do the objects have a circular ...


6

It is not a Singleton. My is just a namespace containing static classes, methods and properties that point to other parts of the .NET framework, and provide some additional capabilities (e.g. CopyDirectory) Think of it as a set of shortcuts, a speed-dial of sorts. Visual Basic provides language/compiler support with the My keyword. You can use the My ...


5

You might find this helpful: http://stackoverflow.com/questions/2765060/stateless-singleton-vs-static-methods/2765251#2765251 To summarize: the advantage of an actual singleton over a static class is, a singleton can implement interfaces the point of a singleton is not to grant global access to a value, but to control instantiation of a type. greetz ...


5

As someone in your position, the most you can do is learn. If the object is essentially a constant (i.e. it can't change and it doesn't maintain state), then your boss may be right. There is no harm in having a static constant object. After all, how many definitions of PI are there? Some people defend the "no global objects" mindset to the point of ...


5

Asynchronous messaging is a good architectural principal for large systems that must scale The Java equivalent of this is JMS and generally considered to be a good thing. This is because it promotes decoupling of your client code from the code that actually services the message. Client code merely has to know where to post their message. Service code ...


5

I wouldn't go as far as saying it encourages bad programming. But it can easily be misused. Well what is the actual idea? The source of the notification only makes its notification. It doesn't make an assumption about the existence of potential observers or anything. An observer registers for notifications it is designed to handle. The observer doesn't make ...


5

I think it's about consistency as much as readability. Other developers may miss the fact that you implemented a "proxy property" and still refer to SomeNameSpace.SubNameSpace.Instance.PropertyName directly. Then you end up with code where sometimes ServerProxyAlias is used and sometimes isn't - even in the same method - and it's not obvious they're the ...



Only top voted, non community-wiki answers of a minimum length are eligible