Common function?

  • Thread starter Thread starter Jon Davis
  • Start date Start date
If you are using VB.NET, then declare your methods/properties as Shared. If
you are using C#, then declare them as Static
 
William Ryan said:
If you are using VB.NET, then declare your methods/properties as Shared. If
you are using C#, then declare them as Static
Click to expand...
Thanks William.

Can I declare the Static function on the page level?
 
In my opinion, static functions and especially variables are to be kept for
very occasional use.

Why not have your pages inherit from YourSpecialisedPage that then inherits
from Page?

This is simple and easy to do.

Regards

Ron
 
Techincally, Yes, but that's only because each page is itself a class. A
class has Method and Functions so if I had a Static Function Bar in my class
foo...
I'd access it like this foo.Bar(whateverParams)

If it wasn't static, I'd have to make my method public and addess it like
this

foo myFoo = new foo();
myFoo.Bar(whateverParams);

HTH,

Bill
 
Ron, just out of curiosity, why is that? I use them pretty frequently,
particularly in components that perform generic functions. They allow lazy
initialization and save me from declaring objects over and over again when I
only need one method of them. In VB, there is a special class known as a
Module that's a convenient mechanism for holding information that doesn't
change from instance to instance, or that can be accessed from everywhere.
ConnectionStrings for instance often serve as a great property in a module.
In C#, you can get to the same place by declaring a class that is sealed and
only has static members (or properties in the example I just used).

Most of my component libraries take advantage of this in the same way many
parts of the Math library does, or MessageBox ro String etc.

From an efficiency point of view, I was under the impression that this is
the way to go b/c you can use method without instantiating a class, so if
your utilitly class is large, and you only need one method in the context
you are using it in, you save a lot of resources.

I'm not sure if these are the occassional situations you are referring to,
but if not, please let me know why. Not trying to be argumentative, but if
I'm missing something, I do this all the time and would like to know what to
change.

TIA,

Bill
 
ll said:
Hi,

How to make a common function so other pages can call directly?

Thanks.
Click to expand...
Well, maybe you mean this: in codebehind class add the following:
public static string SayIt( string str ) {
return "Hello, my dear. It's " + str;
}

If not - look at detailing the situation :)
 
Ron McNulty said:
In my opinion, static functions and especially variables are to be kept for
very occasional use.
Click to expand...

With regard to static functions, I respectfully disagree. I understand that
VB antagonists are prone to believe heavily in objects, but let's not become
obnoxious in that effort. Static methods are very useful for generic logic.
There are many instances where mere namespaces rather than object instances
make for much cleaner, more organized, more sensible, easier to read, easier
to write, and easier to manage function references. I use static methods in
the framework and in my own works all the time. Classic example:

if (System.IO.File.Exists("...")) {
...
}

Regards,
Jon
 
Hi Bill

Blimey, many more posts along those lines and you may get banned from the
newsgroup :)

Seriously though, my experience with static variables in particular has been
that they can become a right pain in the nether regions. As an example, we
had a Java system that was full of such variables. It worked great until we
realised that we needed to run multiple instances of the application on one
machine. Under Java (and probably .NET) this is a very resource-heavy unless
the instances run inside the same virtual machine. So we tried to do this,
but static variables prevented it - there was now only one copy of the
variable over n applications, rather than one copy per application instance.

I'm not so down on static functions, as they certainly have their place. But
they are often overused, and the method can often just be a member of the
class.

e.g A static method Widget.MungeWidget(Widget w, int count) could be
replaced with a member method Munge(int count) with an increase in clarity.

Re connection strings etc, these go in the App.config file in C#, and are
available globally via calls on the Application class (if my memory is
correct).

Regards

Ron
 
Ron said:
Hi Bill




Blimey, many more posts along those lines and you may get banned from the
newsgroup :)

Seriously though, my experience with static variables in particular has been
that they can become a right pain in the nether regions. As an example, we
had a Java system that was full of such variables. It worked great until we
realised that we needed to run multiple instances of the application on one
machine. Under Java (and probably .NET) this is a very resource-heavy unless
the instances run inside the same virtual machine. So we tried to do this,
but static variables prevented it - there was now only one copy of the
variable over n applications, rather than one copy per application instance.

I'm not so down on static functions, as they certainly have their place. But
they are often overused, and the method can often just be a member of the
class.

e.g A static method Widget.MungeWidget(Widget w, int count) could be
replaced with a member method Munge(int count) with an increase in clarity.

Re connection strings etc, these go in the App.config file in C#, and are
available globally via calls on the Application class (if my memory is
correct).

Regards

Ron
Click to expand...

Absolutely agree.
Excuse me if I intrude your dialog, but my thoughts are as follows:
1) STATIC METODS may be used only for utility functions associated with
the entity(class) or pseudo-entity (artificial class). Like them static
parametrised properties were found very useful to reduce code doubling
in ASP.NET applications.
2) STATIC VARIABLES shuld be used as rarely as possible. They limit
scalability of the system. Constants such as connection strings and
stored procedure names should be either real constants if they should
not be changed during operation of system (sp names), resources if they
are localizable or parameters of app.config in all the other cases.

By the way, is it really so that several JVM's share static members? I
think it could be this way.

Dmitry.
 
How do they limit scalability? I can declare in instance of DirectoryInfo
for instance and check if something exists with its instance method.
Similarly, I can use Directory.Exists("blah");

How does that limit scalability?

I have an app that has a singleton class which has a property 'isConnected'.
This determines if I have a database connection. It may or may not change
a bunch during the app. If isConnected is false, then I persist my data to
XML. Otherwise, I fire an update to the db when changes are made. A
shared property works excellently in this capacity. Similarly, I grab a lot
of data from App.Config, but why is it bad to make it a shared property as
soon as the app starts up? Instead of making a call to
Reflection....GetExecutingAssembly..?
 
Ron McNulty said:
Blimey, many more posts along those lines and you may get banned from the
newsgroup :)

Seriously though, my experience with static variables in particular has been
that they can become a right pain in the nether regions. As an example, we
had a Java system that was full of such variables. It worked great until we
realised that we needed to run multiple instances of the application on one
machine. Under Java (and probably .NET) this is a very resource-heavy unless
the instances run inside the same virtual machine. So we tried to do this,
but static variables prevented it - there was now only one copy of the
variable over n applications, rather than one copy per application instance.
Click to expand...

Quick point: this can be overcome in both Java (using multiple
ClassLoader instances) and .NET (using multiple AppDomains).
 
Dmitry Baibakov said:
By the way, is it really so that several JVM's share static members? I
think it could be this way.
Click to expand...

No. In fact, the static members are associated with the Class object,
and thus with the ClassLoader which loaded it. You can have the same
class loaded by two separate ClassLoader instances, and you'll see two
separate variables.
 
Hi,

Ideally we create utility classes, which can be shared by all the
application/classes.

Keyur Shah
Verizon Communications
732-423-0745
 
Thanks Michael.

Is it some utilities can synchronize with local computer time with specify
server?
 
Back
Top