sharing an object application wide

Question

It's common to have an object used application wide. What are the different patterns / models / ways to share an object through an application?

Is defining a "main class", then setting a member variable and extending all other classes from this "main class" a good way? Is creating a static class probably the better and cleaner way? What's your prefered pattern?

score 4 · Accepted Answer · answered Mar 24 '12 at 21:48

It's common to have an object used application wide. What are the different patterns / models / ways to share an object through an application?

One common way is to use the singleton pattern. I would avoid that though.

Is defining a "main class", then setting a member variable and extending all other classes from this "main class" a good way

Absolutely not. Aside from anything else, if it's an instance variable then it wouldn't be "shared" with instances of your other classes anyway. It's also a complete abuse of inheritance which would certainly bite you hard in any application of significant size - your other classes wouldn't logically have an inheritance relationship with your "main" class, would they? As a general rule, inheritance should only be used when it's really appropriate - not to achieve a quick fix.

What's your prefered pattern?

Dependency injection. When your application starts up, create all the appropriate objects which need to know about each other, and tell them (usually in the constructor) about their dependencies. Several different objects can all depend on the same object if that's appropriate. You can use one of the many dependency injection frameworks available to achieve this easily.

Dependency injection generally works better than using singletons because:

The class itself doesn't know whether or not the dependency is actually shared; why should it care?
Global state makes unit testing harder
Each class makes its dependencies clearer when they're declared - it's then easier to navigate around the application and see how the classes relate to each other.

Singletons and global factories are more appropriate when they're for things like logging - but even then, it means it's relatively hard to test the logging aspects of a class. It's a lot simpler to create a dependency which does what you need it to, and pass that to the object under test, than it is to add ways of messing around with a singleton (which usually remains "fixed" after initialization).

I'm curious as to why the singleton pattern should be avoided — K Mehta, Mar 24 '12 at 21:49
@KshitijMehta: Was just adding this - mostly for testability. — Jon Skeet, Mar 24 '12 at 21:51
Is there a case where you would use the singleton pattern? How would you weigh the extra effort required to include a DI framework in your project? — K Mehta, Mar 24 '12 at 21:55
@KshitijMehta: I rarely work on projects where it *doesn't* make sense to use DI, to be honest. Even in cases where it's not worth using a *framework*, I still use DI - I just do it manually at start-up. That can be a simple way of getting going without learning anything new in terms of frameworks - just approaches. — Jon Skeet, Mar 24 '12 at 21:57
@JonSkeet thank you very much for your detailed answer. I've never heard of dependency injection but it seems to be very interesting. According to your skills it must be the way to go! — nexus, Mar 25 '12 at 21:14

score 1 · Answer 2 · answered Mar 24 '12 at 21:57

If you use a framework like Spring which has dependency injection, you can get all the benefits of "global" objects for free without needing to explicitly define them. You just create a reference to them in your application context and you can inject them into any object you'd like without worrying about issues with synchronizing.

score 0 · Answer 3 · answered Mar 24 '12 at 21:47

0

Singleton pattern, AFAIK the preferable way in software engineering.

answered Mar 24 '12 at 21:47

LeleDumbo

9,192
4
24
38

Preferable to what? Abusing inheritance? Yes. Preferable to DI? Very rarely, IMO. – Jon Skeet Mar 24 '12 at 21:58

score 0 · Answer 4 · edited May 23 '17 at 11:48

I believe what you are looking for is the Singleton Pattern. With this pattern you are ensured that only one instance of a class can be created in memory.

Example:

public class mySingletonClass {

    private static mySingletonClass singleObject;

    // Note that the constructor is private to prevent more than one 
    //instance of the class
    private SingletonObjectDemo() {
        // Optional Code
    }

    public static mySingletonClass getSingletonObject() {
        if (singleObject == null) {
            singleObject = new mySingletonClass();
        }
        return singleObject;
    }
}

That said, you should try to avoid using it; but there are some acceptable cases, one of which is here.

sharing an object application wide

4 Answers4