When to be static??

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

C#

I am new to C#, and new to the whole OO concepts, and so I am sure this is a
very stupid question, but I'll ask anyway. When should my methods be static?
I have several "Business Objects" in my app, which basically hold key
functionality. For example I have an Asset class. In there I have some
methods for getting various attributes of an asset. For example I have this:

public class Asset
{
public string GetAssetName(SqlInt64 AssetObj)
{
// Connect to DB, Find the Asset Record and then
// return a string of the asset name
}
}

So to call this I need code like this:

Asset myAsset = new Asset();

String sName = myAsset.GetAssetName(this.AssetObj)

I'm thinking this should be a static method?? But I dont know why.

Thanks
 
Steve,

In my opinion if it is in its behaviour static and you want to share it over
your complete application.

Cor
 
I am new to C#, and new to the whole OO concepts, and so I am sure this is
a
very stupid question, but I'll ask anyway. When should my methods be
static?
Click to expand...

Your methods should be static any time it's an option.

Writing methods to be stateless is, in general, a very good practice.
Anytime your method actually is stateless, you should enforce this at the
contract level, by adding the "static" keyword on there. The more you can
restrict the method or class that your in via language contract syntax
(static, public, private, internal, sealed, etc) the quicker silly bug (and
sometimes not-so-silly bugs) will be caught by the compiler.

As I've written more and more N-Tier code, the general pattern that I follow
is:
1 - Data layer methods are almost always static
2 - Data Container classes (aka: "Employee", "Payment", etc) are NOT static,
as they're all about state.
3 - Operational and Factory methods (CreateEmployee, ProcessPayment) are
static, but take one of the data containers as a parameter.
I have several "Business Objects" in my app, which basically hold key
functionality. For example I have an Asset class. In there I have some
methods for getting various attributes of an asset. For example I have
this:

public class Asset
{
public string GetAssetName(SqlInt64 AssetObj)
{
// Connect to DB, Find the Asset Record and then
// return a string of the asset name
}
}

So to call this I need code like this:

Asset myAsset = new Asset();

String sName = myAsset.GetAssetName(this.AssetObj)

I'm thinking this should be a static method?? But I dont know why.
Click to expand...

I would say this example is likley to have some problems bigger than static
or non-static. I would change this to be 2 classes - Asset and AssetFactory.
The Asset class is full of state - Name, Id, Owner, Purchase Date, etc. The
AssetFactory is responsible for populating the Asset from the database.

This way your could would look like:

// Note the Static Method call on the factory
Asset myAsset = AssetFactory.FindAsset(12345);

// Note the stateful property accessor on the Asset class
String name = myAsset.Name;

As it sits, your old asset class is going to connect to the database alot.
This isn't good, as database calls are slow and expensive. Connect once,
populate your Asset, then go from there.
 
Back
Top