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?

Answer 1

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).