implications of Shared methods

  • Thread starter Thread starter Mark Kamoski
  • Start date Start date
M

Mark Kamoski

Hi Everyone--

Please help.

What are the implications, (in terms of memory, application footprint,
resource use, threading, and so forth), of using Shared methods?

These Shared classes raise some interesting questions. For example...

(1). If I have a custom utility class where I keep all of my Shared methods
and then I use that class frequently within my ASP.NET application, what
does this do to the memory usage in my application?

(2). In an ASP.NET application, when does the Shared class get "built",
since there is no "New" called? It seems to be always available, so is it
always in memory?

(3). In an ASP.NET application, when does the Shared class get destroyed?
Again, it seems to always be available (based on the fact that one never
needs to call "New"), so how is it destroyed?

And so on.

Any clarification on this matter is greatly appreciated.

Thank you very much.

--Mark
 
To the best of my knowledge:

1) Shared methods will be more efficient then instance methods, since there
will not be a need to create an instance of an object to call it. If
anything, this should keep memory usage in check.

2) In any application, the class will get 'built' the first time an instance
of it is created, or a shared member is accessed.

3) It will probably get destroyed when the application_end event fires.
 
Mark Kamoski said:
Hi Everyone--

Please help.

What are the implications, (in terms of memory, application footprint,
resource use, threading, and so forth), of using Shared methods?

These Shared classes raise some interesting questions. For example...

(1). If I have a custom utility class where I keep all of my Shared methods
and then I use that class frequently within my ASP.NET application, what
does this do to the memory usage in my application?
Click to expand...

Why would it do anything to memory usage? I would assume the answer is "no
impact".
(2). In an ASP.NET application, when does the Shared class get "built",
since there is no "New" called? It seems to be always available, so is it
always in memory?
Click to expand...

There is no "instance" of a shared class. I expect that the IL code of the
class is in the .dll file like any other code, and that it is paged in and
JIT compiled as required.
(3). In an ASP.NET application, when does the Shared class get destroyed?
Again, it seems to always be available (based on the fact that one never
needs to call "New"), so how is it destroyed?
Click to expand...

"Classes" do not get destroyed or created.

Also, what exactly do you mean when you say a "shared class"? Is it the
following:

Public Class SomeClass
Public Shared Sub SomeSub
End Sub

Public Shared Function SomeSub as SomeType
End Sub

Public Shared Property SomeProp as SomeType
Get ...
Set ...
End Property

Public Shared ReadOnly SharedConstant As Integer = 1000
End Class
 
Mark Kamoski said:
John--

Thank you for your reply.

Regarding this...

"Classes" do not get destroyed or created.

....yes, well I guess what I should have said is "when the memory gets
reclaimed after the class is no longer in use", or something like that.
Click to expand...

Memory for shared fields in the would be deallocated when the AppDomain is
destroyed. Similarly, that memory will not be reallocated when the AppDomain
starts again.
 
Mark,

Creating a single class in your program in which you stash all your
miscellaneous methods undermines
the encapsulation of an object-oriented design.
 
MS--

I appreciate your comments and your OOP check.

Furthermore, I agree with you, essentially.

That is-- Shared could violate OOP rules if it is over overused or
incorrectly used.

However, it seems that there must be a value to Shared methods supported by
the fact that they were added to the language and are not some kind of
legacy holdover, like Goto.

For example, one has CType, Convert, IsNumeric, IsNothing, and a few others
for which one does not have to and Import statement or New at all. Simply
add a class to a project and type IsNumeric and it is there for the taking.

This seems valid, efficient, and useful to me, but maybe it isn't as pure
as it should be-- is that what you are saying, that methods like these

(Now, I don't know what the implementation details of just how a method
like IsNumeric works, but that's just the point, isn't it-- I don't care. I
don't want to know which library to create an instance of-- I simply want
to type IsNumeric whenever I want. Therefore, I'd call that a static, AKA
shared, method. I don't care to argue the finer points of exactly whether
or not it is TRULY a static class. All that I care about is that I don't
have to instantiate a class to use it. In this case, I don't even need to
know which class it is in.)

After all, a Shared method is a static method-- and we have those in the
Framework and they have been a part of the C++ world for a long time.

For example, Math has some (or all?) Static/Shared methods, it seems.

No?

Am I missing something here?

Anyway, that's what I was talking about in my message below.

I'd love to hear your thoughts.

--Mark





Mark,

Creating a single class in your program in which you stash all your
miscellaneous methods undermines
the encapsulation of an object-oriented design.
 
You are correct, Mark. In fact, methods like "IsNumeric" are indeed static
(shared) methods of a class ("Microsoft.VisualBasic.Information" in the case
of IsNumeric). You don't need to use the namespace or class name because
they are already referenced.

Basic rule of thumb: If a method doesn't require instantiation of a class,
and if that method is useful in a large variety of classes and applications,
it is a good idea to make it shared.

How you organize your static methods is entirely up to you. It is useful to
group static methods that are similar in some way in the same class, just
for the purpose of being able to find them quickly.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Big Things are made up of
Lots of Little Things.
 
All I am saying is: don't over do it. You already know what I mean and
said it.
Life is not Back and White or OOP and Not-OOP
A good, intelliegent mix is good and it depends.

Yes it is nice to just use CType, Convert etc...

as long as your static methods belong to the right class there is no problem
however if one creates one class and stashes all kind of static methods in
one place then that is questionable
Imagin that one class has STATIC Math, IO, Web and etc.. methods in one
class?

Remember that your program will still work, provided that the logic is good,
no matter what mehod of programming you use.
Down at the 0's and 1's things look the same.

But due to the limitations of human beings we needed these tools to help us
out.

Why do we need a GC when C++ programmers are so perfect?
 
I think you should understand the concept of Shared (or
Class side) variables. The original OO concept was that
if I wanted to define some attribute that applied to all
instances of a class, then I would define a class side
(shared) variable. So if I had a Human class and wanted to
define a maxLifetime for all humans, I could declare
Public Shared maxLifetime. Then I could create class side
accessors (setters and getters) to assign a value to my
class variable. This would be in contrast to the instance
side method Age, which keeps track of an individuals
current age.
Beyond that, you must be careful not to fall into the trap
of using a class variable as a degenerate global (that's
what it really is, just a global that is scoped to a
class). Instance variables and methods are the "standard"
OO way of implementing an object. Even when it comes to
Singletons, it is better, IMHO, to use a single instance
of a class as opposed to using a class with only class
variables and methods.
For me, it is an "informational" concept not
a "performance" consideration. I like Kent Beck's order
of development, "Make it work, Make it right, Make it
Fast". Making it fast should be your last consideration,
not your first. Readability, Maintainability, and
Extensiblity are much more important than pure speed.
Gary
 
Back
Top