Hi, Amadelle
Standard recommendation - check some books on OO programming and design,
like Booch, Grady and many others. However, it's a lot of reading, which is
not very thrilling :-)
Main difference is - static objects usually do not change / evolve during
application lifetime. Instantiated objects are dynamic by nature. Depending
on object domain they are created and destroyed as result of changes in
environment - user actions, external events etc.
Static is really static and instantiated is dynamic.
So, rule of thumb is
- if object behavior and data does not depend on application environment and
should provide always same results - object is most likely static. If it
should be visible and accessible during whole application life time - it has
to be static. Like page in book. Whenever you look at it you see same
letters. Global values are good example. And static classes in .Net like
Environment or SystemInformation are good examples.
- when your objects are changing and multiply / die during application life
time, when objects behave in different way if another object changes state,
they are most likely instances. Code word here is stateful - at any given
moment object has state, which might be changed and change its behavior.
Usually loggers are static because they must be visible and accessible
whatever other objects exist in application. You create queues, threads,
forms, but you must be able to log events using same log object from any of
these and at arbitrary moments. Because you write book and do not wipe out
logged information.
With database issue is usually more complex - databases reflect dynamics of
data. Today customer lives here, tomorrow there, so you never know which
results you will get with same query. Another issue is scalability and
resource usage - you can't hold locks on data forever, you can't open and
hold connections for every connected user for 9-10 hours and so on. So,
usually these things are very dynamic and implemented as instantiated
classes. At the same time, instantiated classes might implement methods,
which are always doing same jobs, like for example running query and
returning result set. Such method is static by nature and could be
implemented as static. However if same method has to provide different
functionality for different instances (say, for Peter it has to return his
date of birth and for Maria her date of death) it might be better
implemented as instance method. Like notepad - you add pages, remove them,
scribble some, then overwrite etc.
This is very simplistic intro static vs. instance issues. In most cases best
solution is to model object domain and analyze where you have static parts
and behaviors and where you have dynamics. That's why I mention OO design
theory - it takes some experience in addition to theoretical ground to be
able to make sound decisions in this area.
HTH
Alex
"Amadelle" <am******@yahoo.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...
Hi All and thanks in advance,
I wanted to know when is a good idea to use a static class (with static
constructor) and when to use instance classes? I have read couple of
articles on line and the general example is when you want to write a log
file use static class ...but they don't say why?
My specific question is that I have a validation class with some data
validation methods which will be called through out the program and I am
debating whether this validation class should I set it up as a static
class or an instance class?
What about my data access class with methods for accessing database,
opening up connections and running queries? Should I set that up as an instance
class or static class?
Thanks I appreciate your help in this matter,
Amadelle