Singleton, Shared Members, etc.

[a]

Hello Gang,

I am in a bit of confusion regarding a half completed application I am
writing. It is an MDI app, so I have a main form (frmMain) that is always
open.

I am looking for a 'Best Practice' here. I have a class (config.vb) that
manages an XML file with the applications configuration settings. I need to
access it from many places in the app. I have other similar classes
(onlineOffline.vb, dataAccess.vb, etc.) I only need one instance of each of
these. I am getting in trouble with whether to implement the Singleton
approach in the class itself, or keep one copy in the MDIParent form, and
reference it from there, or just use some Shared properties and methods.

I started making a bunch of Shared Subs, Functions, and Properties, and the
further I go, the messier it feels.

Please point me in the right direction. Looking for some Solid OOP
praactices here.

Thanks!

Kevin

 

[David Williams , VB.NET MVP]

What I normally do in this type of case is to implement a Singleton
pattern using a Factory.

Public Config Class
Private _Instance as Config

Private Sub New()
End Sub

Shared Function GetInstance() as Config
If _Instance Is Nothing Then _Instance = New Config
Return _Instance
End Function

End Class


HTH

David

 

[a]

David, when do I call the GetInstance? Evertime I need to access a property
or method I assume, I need to have an instance of the class, and i set it
equal to the result of GetInstance.

Dim objConfig as Config = Config.GetInstance

Is this a better strategy than using Shared members of a class, where I
don't need an instance of the class?

I understand the 'How To' of the singleton concept, I am just not sure on
the best approach in am MDI app scenario.

Thanks!

Kevin

 

[David Williams , VB.NET MVP]

That is exactly the way that I do it. I think that it is a little
better than a Shared class in that it does not "pollute" (to use a VB6
term) the global namespace. The overall effect is the same however.
Also, I would tend to create the instance at a class level, not a
function level, but that is just my laziness.

By doing the class as a Singleton, you get all of the advantages of
encapsulation as well as isolation. If you do it at a shared Class (or
module) then you are not nearly as isolated. I find that shared classes
tend to also be a little slower if hit a lot. Not sure as to why, I
need to run a profiler on it to see.

I also like doing configuration classes in particular this way, as I
often find it necessary to play games like caching in them. Also, I
will often just have just one exposed method GetConfigOption(Key as
string) as String. That way, if I need to change the underlying
structure of the configuration file, there are no problems with the rest
of the application. However, of course, that will not help for things
like a data layer class.

HTH

David

 

[David]

That is exactly the way that I do it. I think that it is a little
better than a Shared class in that it does not "pollute" (to use a VB6
term) the global namespace.

Well, he seems to be talking about shared subs and functions in a normal
class, and of course that won't "pollute" the global namespace any more
than a singleton will. (By "shared class" I'm assuming you're thinking
a VB.Net module, since AFAIK vb.Net doesn't have shared classes like vb
did).

By doing the class as a Singleton, you get all of the advantages of
encapsulation as well as isolation. If you do it at a shared Class (or
module) then you are not nearly as isolated.

No, but that's a straw man, what was explicitly mentioned was using
shared members of a class.

Seriously, I tend to use singletons everywhere for configuration, and
lately I've been asking myself whether it gets me anything other than
another redirection step during access. One of the main advantages of
singletons was lazy construction, but that's not an issue with
configuration classes: I know I'm going to want one and I generally know
exactly when I want to construct/initialize it.

Which leaves the only advantage to singletons the fact that it's
marginally easier to add functionality later by turning the access
function into a real factory and subclassing the singleton class. But
that's something I've never needed to do, and it wouldn't be
particularly difficult to have shared member functions do the same
thing. And in a sense, isn't the fact that I'm using a singleton and a
factory access function an implementation detail that I should hide from
the caller?

I also like doing configuration classes in particular this way, as I
often find it necessary to play games like caching in them. Also, I
will often just have just one exposed method GetConfigOption(Key as
string) as String. That way, if I need to change the underlying
structure of the configuration file, there are no problems with the rest
of the application.

Again, where's the advantage over making GetConfigOption a shared
function? I can still do caching, and the config structure is still
hidden from the user.

This is something I've been thinking about lately, and I'm just kinda
hard-put to come up with any reasonable advantage to using a singleton
for a config class.

David