Static Vs. Instance

  • Thread starter Thread starter Dinsdale
  • Start date Start date
D

Dinsdale

I was discussing class architecture with one of the senior developers
at my new job and him and I have a similar idea on how to work with
data access and class libraries. That said, our implementations vary
slightly and I wanted to post the question to the .Net community to get
some feedback. So here is the issue:

When designing classes both the senior developer and I agree that data
access should be abstracted out from a business object class by way of
a "factory layer" that communicates between the data access layer and
the business class itself. The factory layer returns an instance of the
object requested based on an ID field used to retrieve the instance
info in the DB. I like to create static methods on the Class being
created that wrap a static factory class and return the object; where
as he believes in creating an instance of the factory that returns the
new object.

My Method (static):

MyWidget mwInstance = MyWidget.GetWidget(555);
//MyClass.GetWidget Wraps static method MyWidgetFactory.GetWidget(int
intWidgetID);

His Method(instance):

MyWidgetFactory mwfFactory = new MyWidgetFactory();
MyWidget mwInstance = mwfFactory.GetWidget(555);

I devised my method while working in a windows environment so I knew
that a limited number of users or processes is accessing the DB. I am
now working in a Web environment, which means "unlimited" users or
processes accessing this code. So, my questions are thus:

1) Is either method perferrable (Static vs. Instance)?
2) Will environment affect performance when creating new instances?
3) If so, which methodology will perform better in a web environment?

Cheers
Dinsdale
 
1) Is either method perferrable (Static vs. Instance)?
2) Will environment affect performance when creating new instances?
3) If so, which methodology will perform better in a web environment?
Click to expand...

The performance won't make much difference. There isn't very much to
choose between the two, but you might want to consider whether all
these factories could implement some interface which you might want to
use in a general way. At that point, creating instances (or obtaining
those instances in another way, eg from a map of type->factory) could
give you a benefit.
 
Dinsdale said:
I was discussing class architecture with one of the senior developers
at my new job and him and I have a similar idea on how to work with
data access and class libraries. That said, our implementations vary
slightly and I wanted to post the question to the .Net community to get
some feedback. So here is the issue:

When designing classes both the senior developer and I agree that data
access should be abstracted out from a business object class by way of
a "factory layer" that communicates between the data access layer and
the business class itself. The factory layer returns an instance of the
object requested based on an ID field used to retrieve the instance
info in the DB. I like to create static methods on the Class being
created that wrap a static factory class and return the object; where
as he believes in creating an instance of the factory that returns the
new object.
Click to expand...

I agree with the senior developer. I'll tell you why: static methods
that rely on state (such as your factory class in the background) are
basically just hiding global variables. If you ever have a situation
where you need to work with two factories side by side, all your code
will be tied to the static methods and will only work with one of them.
That'll lead to swapping the global state in and out as you toggle
between the two.
My Method (static):

MyWidget mwInstance = MyWidget.GetWidget(555);
//MyClass.GetWidget Wraps static method MyWidgetFactory.GetWidget(int
intWidgetID);

His Method(instance):

MyWidgetFactory mwfFactory = new MyWidgetFactory();
MyWidget mwInstance = mwfFactory.GetWidget(555);

I devised my method while working in a windows environment so I knew
that a limited number of users or processes is accessing the DB. I am
now working in a Web environment, which means "unlimited" users or
processes accessing this code.
Click to expand...

That's not necessarily a showstopper, depending on what your factory is
serving. If the factory is tied to a client and you're using
asynchronous code, then you'll find it difficult to use static methods
like you are. The factory isn't tied to a client, or if you're not using
asynchronous I/O, it's possible - in the first instance, there's no
conflict to manage other than locking where necessary, and in the second
instance, you can use a static field marked [ThreadStatic] to hold the
factory that the static methods wrap.
So, my questions are thus:

1) Is either method perferrable (Static vs. Instance)?
Click to expand...

When possible and easy, I prefer Instance, and I dislike the 'Singleton'
pattern. In fact, I've never understood why it appeals to people - it
always seemed like a bad idea to me, except in extremely limited
scenarios.

On the other hand, if it's important to deal with a 'context' of some
kind everywhere in your code, it can be worth it to make that context
available everywhere, rather than try to thread it through every call
path and data structure.
2) Will environment affect performance when creating new instances?
3) If so, which methodology will perform better in a web environment?
Click to expand...

It depends on if you're using asynchronous code (in which case you'll
find it somewhat difficult to get the desired behaviour if it's tied to
a client, since you can come back in on a completely different thread)
and whether the state is per-client or shared across the server.

Hope that made sense.

-- Barry
 
Thanks guys, lots of great info. Since there is no overriding need to
use a singleton approach and the code may need to support multiple
factories in the future, using an instance of the factory does seem to
be the logical answer.

Cheers
Dinsdale

Barry said:
Dinsdale said:
I was discussing class architecture with one of the senior developers
at my new job and him and I have a similar idea on how to work with
data access and class libraries. That said, our implementations vary
slightly and I wanted to post the question to the .Net community to get
some feedback. So here is the issue:

When designing classes both the senior developer and I agree that data
access should be abstracted out from a business object class by way of
a "factory layer" that communicates between the data access layer and
the business class itself. The factory layer returns an instance of the
object requested based on an ID field used to retrieve the instance
info in the DB. I like to create static methods on the Class being
created that wrap a static factory class and return the object; where
as he believes in creating an instance of the factory that returns the
new object.
Click to expand...

I agree with the senior developer. I'll tell you why: static methods
that rely on state (such as your factory class in the background) are
basically just hiding global variables. If you ever have a situation
where you need to work with two factories side by side, all your code
will be tied to the static methods and will only work with one of them.
That'll lead to swapping the global state in and out as you toggle
between the two.
My Method (static):

MyWidget mwInstance = MyWidget.GetWidget(555);
//MyClass.GetWidget Wraps static method MyWidgetFactory.GetWidget(int
intWidgetID);

His Method(instance):

MyWidgetFactory mwfFactory = new MyWidgetFactory();
MyWidget mwInstance = mwfFactory.GetWidget(555);

I devised my method while working in a windows environment so I knew
that a limited number of users or processes is accessing the DB. I am
now working in a Web environment, which means "unlimited" users or
processes accessing this code.
Click to expand...

That's not necessarily a showstopper, depending on what your factory is
serving. If the factory is tied to a client and you're using
asynchronous code, then you'll find it difficult to use static methods
like you are. The factory isn't tied to a client, or if you're not using
asynchronous I/O, it's possible - in the first instance, there's no
conflict to manage other than locking where necessary, and in the second
instance, you can use a static field marked [ThreadStatic] to hold the
factory that the static methods wrap.
So, my questions are thus:

1) Is either method perferrable (Static vs. Instance)?
Click to expand...

When possible and easy, I prefer Instance, and I dislike the 'Singleton'
pattern. In fact, I've never understood why it appeals to people - it
always seemed like a bad idea to me, except in extremely limited
scenarios.

On the other hand, if it's important to deal with a 'context' of some
kind everywhere in your code, it can be worth it to make that context
available everywhere, rather than try to thread it through every call
path and data structure.
2) Will environment affect performance when creating new instances?
3) If so, which methodology will perform better in a web environment?
Click to expand...

It depends on if you're using asynchronous code (in which case you'll
find it somewhat difficult to get the desired behaviour if it's tied to
a client, since you can come back in on a completely different thread)
and whether the state is per-client or shared across the server.

Hope that made sense.

-- Barry
Click to expand...
 
Dinsdale,

A static class is in my opinion not a part of OOP programming.

To explain this in another way than probably mostly is done.

In VBNet a Static class, which has in that the more describtive name Shared
class is nothing more than a module. You can use only Shared Classes or
Modules (they behave exactly the same) in your application.

The result is than a nice modulair written program (Here not meant in the
context of an end user modulair program).

Cor
 
INLINE

Dinsdale said:
<SNIP>
So, my questions are thus:

1) Is either method perferrable (Static vs. Instance)?
Click to expand...

Static is great for helper methods, like adding values together, returning a
value or set of values based on a particular input. Anything that does not
require instantiation.

In general, factories are not helpers (actually can't think of an instance
where you would not instantiate a factory, but I am sure there is at least
one).
2) Will environment affect performance when creating new instances?
Click to expand...

Instance creation is more a scalability issue, but scalability issues are
not always solved by pushing to static and there are good reasons not to go
static for scalability (lengthy subject, little time).
3) If so, which methodology will perform better in a web environment?
Click to expand...

Until the environment is taxed, neither is going to show a superior enough
performance to make a decision. Instead, you should make the decision on
whether there is a reason to short circuit a well-documented pattern. I am
not saying there is no reason to do this, as you may have come up with a
completely new pattern that is superior, but I cannot see the benefit of the
static method and keeping a factory alive forever. There might be an
instance where you stoke up the factory and it is so overused that it makes
sense to keep it up as a single instance.

Now, the bad news. If you code the factory method incorrectly, you can end
up pulling information from one instance into the incorrect instance, esp.
if you ever need to multi-thread for performance. Long story over.

Short story: Without knowing the specifics of your project, I would agree
with the senior developer, although I must admit I highly respect you for
asking before falling in line. A junior programmer willing to learn and
think for himself is a great asset. Rock on!

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside the box!
*************************************************
 
Back
Top