C# static, is this correct?

[Maya]

Hello guys, in C#, is using "static" would be the most proper way to
get around calling methods located in different classes? for instance,
a method caller in class A wouldn't see a method in class B unless that
method is declared as public static.

This works fine (i guess!) for me, and i have been doing this for a
long time, just came to my mind that there might be a better or more
professional way to call methods in other classes without sharing the
method for the whole namespace scope, and just came to my mind: what if
this practice slows down execution? as i do have intensive calculations
where a method has to return values in few milliseconds and the overall
performance is vital for my application.

Your opinions are greatly appreciated, Thank you!

Maya.

[Jon Skeet [C# MVP]]

Maya <kf****@gmail.com> wrote:

Hello guys, in C#, is using "static" would be the most proper way to
get around calling methods located in different classes? for instance,
a method caller in class A wouldn't see a method in class B unless that
method is declared as public static.
No, that's not true.

A member (whether it's a field, property, method, whatever) being
static means it's associated with the type rather than with a
particular instance.
This works fine (i guess!) for me, and i have been doing this for a
long time, just came to my mind that there might be a better or more
professional way to call methods in other classes without sharing the
method for the whole namespace scope, and just came to my mind: what if
this practice slows down execution? as i do have intensive calculations
where a method has to return values in few milliseconds and the overall
performance is vital for my application.

Performance isn't impacted by this. You should know that there's no way
of restricting a method to only be callable by other classes in the
same namespace though.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[John Bailo]

Maya wrote:

Hello guys, in C#, is using "static" would be the most proper way to
get around calling methods located in different classes? for instance,
a method caller in class A wouldn't see a method in class B unless that
method is declared as public static.
Or you could instantiate your class:

MyClass mc = new MyClass();

This works fine (i guess!) for me, and i have been doing this for a
long time, just came to my mind that there might be a better or more
professional way to call methods in other classes without sharing the
method for the whole namespace scope, and just came to my mind: what if
this practice slows down execution? as i do have intensive calculations
where a method has to return values in few milliseconds and the overall
performance is vital for my application.

I was under the impression that static, which loads before run, would be
faster because of that.

The problem with static is that it takes up memory and holds it.
Statics can gum things up if you don't use them right.

Statics are something you want to "keep around" for the run of your
application. Non-statics are things that you want to use and throw
away. Especially if you have to reuse things and reinitialize and
don't want to have to worry about left over values, then you don't want
to use statics.

[pvdg42]

"Maya" <kf****@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

Hello guys, in C#, is using "static" would be the most proper way to
get around calling methods located in different classes? for instance,
a method caller in class A wouldn't see a method in class B unless that
method is declared as public static.

This works fine (i guess!) for me, and i have been doing this for a
long time, just came to my mind that there might be a better or more
professional way to call methods in other classes without sharing the
method for the whole namespace scope, and just came to my mind: what if
this practice slows down execution? as i do have intensive calculations
where a method has to return values in few milliseconds and the overall
performance is vital for my application.

Your opinions are greatly appreciated, Thank you!

Maya.

I'll start this off and I'm sure you'll get many responses...
The external caller won't "see" the method in class B unless the method is
declared public (FWIW, this is an oversimplification, as it does not address
who "sees" what when other access specifiers are used).
Static does not control exposure, the access specifier does (public, in your
example).
The keyword static indicates that the method is not an instance method, and
thus does not require a caller to first instantiate class B, then qualify
the method call with the object name.
I'm not sure why you think static methods might be a factor in degrading
performance. Most, if not all, major class libraries include utility classes
featuring nothing but static methods. I believe, to make the methods readily
available to developers without an instantiation process.

[Adam Cooper]

Static methods are an acceptable way for classes to call methods in
other classes. But typically, as Jon mentioned, it associated with the
type rather than the particular instance.

If you have a class with only static methods and static variables, then
it should typically be Utility class or you might want to rethink your
design a bit.

Two other acceptable ways to solve your initial problem are passing the
instances of the classes to the objects requiring them. For instance,
if you want to call class A in class B, pass class A as a parameter to
class B's constructor.

The other method, is the Singleton pattern. This has a slightly
different intention: Ensure a class has only one instance and provide a
global point of access to it.

You can read more about it here:
http://www.yoda.arachsys.com/csharp/singleton.html

Cheers,
Adam
-------------------------------------------------------------------------------------------
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net

[riscy]

One alternative from static is to past the object reference as you
instantiate new object from several classes. I trhink this is part of
design pattern approach rather than OOP, but I still reading this book.
Here the example which work well on application I'm developing..

namespace Scope
{
ScopeMe Me = new ScopeMe();
ScopeSnooze Object2 = new ScopeSnooze(Me);
ScopeWake Object3 = new ScopeWake(Me);
ScopeEat Object4 = new ScopeEat(Me); ........and so on.
....
}
....
namespace Scope
{
class ScopeEat()
{
ScopeMe Me
public ScopeEat(_Me)
{
Me=_Me;
}
}
}
namespace Scope
{
class ScopeWake()
{
ScopeMe Me
public ScopeWake(_Me)
{
Me=_Me;
}
}
}

Adam Cooper wrote:

Static methods are an acceptable way for classes to call methods in
other classes. But typically, as Jon mentioned, it associated with the
type rather than the particular instance.

If you have a class with only static methods and static variables, then
it should typically be Utility class or you might want to rethink your
design a bit.

Two other acceptable ways to solve your initial problem are passing the
instances of the classes to the objects requiring them. For instance,
if you want to call class A in class B, pass class A as a parameter to
class B's constructor.

The other method, is the Singleton pattern. This has a slightly
different intention: Ensure a class has only one instance and provide a
global point of access to it.

You can read more about it here:
http://www.yoda.arachsys.com/csharp/singleton.html

Cheers,
Adam
-------------------------------------------------------------------------------------------
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net

[Cor Ligthert [MVP]]

Maya,

Your question is about C#.

However, doing this as you wrote in the VBNet world would be bad
programming.

It is in fact not OOP it is using the VB module in another way.

I hope this gives an idea, and spare me a discussion writting it in this
way.

Cor