Opinions needed on "shared" keyword

nlarson11

Hello, I saw this code of developer we have doing something at my company and he's using the word "shared" in front of routines everywhere. For example, he has a dll that he's referencing from a website and lots of routines in the dll are coded "shared". These routines aren't doing simple formatting or soemthing that, they are doing DB work, etc. Is there a concern in how many times a shared routine can be called currently? I personally do not like his design at all and i'm curious what everyone else's opinions are about the usage. Is using shared in this way a lazy thing or ? Any opinions are appreciated (within this topic - ha ha). Thanks Nathan

'Never argue with an idiot; they'll drag you down to their level and beat you with experience.' ~ anonymous

Luc Pattyn

For starters, Shared is over-used. You can (and should) use Shared on methods that perform a state-less operation, e.g. mathematical functions Math.Abs and Math.Sin You could have a Shared method that say increments a counter inside a database, provided the whole operation is contained in the method. And you can create a class that is entirely Shared (all its data members and methods are Shared) provided it represents a unique object, something you are sure you never will need more than one instance of. Not too many real-life objects would fill that description though, most things aren't unique (although they may start of as a unique instance, e.g. your app may currently have access to only one database, however that might change in the future). :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

nlarson11

Thanks Luc, So if he has a routine that accepts 1-n arguments that could be different per call and does a search and update from/to a database - not a good candidate for a shared routine - correct or? Is there a limit to how many current calls can be made to a shared routine?

'Never argue with an idiot; they'll drag you down to their level and beat you with experience.' ~ anonymous 'Life's real failure is when you do not realize how close you were to success when you gave up.' ~ anonymous

Dave Kreskowiak

There is no limit on the number of threads that can call a static method at the same time. Actually, any limit that does come up would be imposed by the design and coding of the code calling these methods and the data passed in. But, in general, there is no limit but the ones you impose yourself.

A guide to posting questions on CodeProject[^]
Dave Kreskowiak

Luc Pattyn

nlarson11 wrote:

not a good candidate

depends. Does the code need state? Or is it all self-contained, i.e. execute and forget?

nlarson11 wrote:

Is there a limit to how many current calls can be made to a shared routine?

No more than for a non-Shared method. Again, see Math.Sin() :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

nlarson11

Thanks Dave, Do you object to a design that seems to be flooded with "shared" use?

'Never argue with an idiot; they'll drag you down to their level and beat you with experience.' ~ anonymous 'Life's real failure is when you do not realize how close you were to success when you gave up.' ~ anonymous

nlarson11

self-contained. ok good to know.

'Never argue with an idiot; they'll drag you down to their level and beat you with experience.' ~ anonymous 'Life's real failure is when you do not realize how close you were to success when you gave up.' ~ anonymous

Dave Kreskowiak

Yeah, it sounds as though it's way over-used. Those methods sound like they should be moved to an instance of a data layer.

A guide to posting questions on CodeProject[^]
Dave Kreskowiak

Lost User

A Shared (static) method does not interact with the class it's defined in. Anything in your class that doesn't touch instance-members can be made shared. Sometimes a procedural programmer will have trouble thinking in OO, generating lots of static methods that take lot's of parameters. The OO-way makes it's handy to have all the parameters and other variables embedded in an object, and interact with those, each "group" of procedures becoming objects;

' If you got groups like these
shared Sub MySBSOpener(sbs as Object, HowMany as integer, ByRef TestCount as Integer)
shared Sub MySBSTester(sbs As Object, HowOften as integer, Verbose as Boolean)
shared Sub MySBSCloser(sbs as Object, Title as String, ByRef TestCount as Integer, Verbose as Boolean)

' consider these
Class SBS
private _howMany as int
private _howOften as int

Public Sub New(HowMany as Integer, HowOften as Integer)
_howMany = HowMany
_howOften = HowOften
End Sub

public Sub MyOpener() ' this sub now uses "Me" as the Object,
' _howMany as a field
' and puts the result in the TestCount property
public Sub MyTester() ' other example sub use their parameters in their body
public Sub MyCloser(Title As String) ' except title, which is still passed

public property Verbose as Boolean
public readonly property TestCount
get
return _testCount
end get
end property

End Class

This has the advantage that you can populate a list with these things, something that's a bit harder to do if all methods are static.

Bastard Programmer from Hell :suss:

nlarson11

thanks Eddy

'Never argue with an idiot; they'll drag you down to their level and beat you with experience.' ~ anonymous 'Life's real failure is when you do not realize how close you were to success when you gave up.' ~ anonymous

Lost User

You're welcome :)