OO design question

[Amadelle]

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

 

[Nicholas Paldino [.NET/C# MVP]]

Amadelle,

Quite simply, it is all about scope. Anything static is in the context
of the current app domain. At that point, what you need to ask is, "within
this context, is what I am writing instance specific or type specific?".

Take the Math class, for example. It has static functions for computing
the sine, cosine, tangent, etc, etc on angles. Now if there was a concrete
representation of an angle in the system, then I would have Sin, Cosine,
etc, etc, be properties on it, but since angles are represented easily
enough with numbers (eliminating the need for a class), it makes sense to
just have a function that doesn't need an instantiation of an object to make
the call on for this information.

However, take a class that represents people. You have specific
information that is unique to each individual person that the class can
represent. Accounting for all of these differences would require multiple
instances of the class, each configured to represent people in a different
way. Having this be static would make it difficult to deal with a specific
person in your code.

Hope this helps.

 

[AlexS]

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

 

[Niki Estner]

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?

I'm not 100% sure, but I think when you talk about "static classes", you
really mean singletons?

(Actually, I only know the term "static inner/nested class" from java, where
inner classes usually can access the outer classes members, but static inner
classes can't. From that point of view C# (to my knowledge) like C++ inner
classes are always static.)

Now, it's quite common to implement a log file class as a singleton because:
a) it's used in many unrelated classes
b) all places should write to the same logfile
So you could either pass a log-file-pointer all around through your class
hirarchy (which is ugly), or you could simply implement it as a singleton.

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?

It depends on your application:
- does "called through out the program" really mean called from completely
unrelated classes?
- do those different classes actually need to use the same instance of your
validation class, or couldn't each of those simply create its own instance?
- do you have any "client-dependent" information in your validation class,
that could be lost if two clients use the same object without knowing?

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?

This is similar to the above problem, however a database access class does
"cost" more: you wouldn't want more than one database connection at a time;
So in this case a singleton would probably make more sense.

Niki