Confused - Static member object whose class design assumes multipleinstances.

[pgrazaitis]

I cant seem to get my head wrapped around this issue, I have myself so
twisted now there maybe no issue!

Ok so I designed a class X that has a few members, and for arguments
sake one of the members Y is the location of a file to be read. The
original design assumes that this class will be instantiated and each
instance will happily mange its own members. (ie One file location
per instance...no thread-safety).

Now another class A comes along and makes an instance of this class as
a static readonly member B. Do I now have "implied staticness" on the
original class design? Ok, I cant change the actual pointer to the
instance of Class X; however, through class methods I can change the
make-up of this object. In my case I can use methods in class X to
change the file to be read.

If all of this is true so far, I can now change the file to be read so
that all instances of A must read the same configuration file. Per
the original design of class X, the class invariant is ok. However,
with "implied staticness" I have a potential issue in its use.

So this is the Pandora's box I have been forced to use. I am forced
to create this object as static due to a static method
signature...still dont fully understand that architecture yet.

-Is "implied staticness" true?
-Does this force a refactoring of class X to account for static usage/
thread safety/static based invariants?
*Im implied to say no and these questions are directed towards my
design of class A
-Are there better patterns or best practices I should use to vet my
class design?
-Should I reconsider the design of class A for static usage/thread
safety/staticbased invariants?
*In this case I guess I would have to include additional overhead to
check certain settings before resetting.
*Could create a factory...hmmm thats probably really what should be
done anyways..huh?

Thanks in advance for reading my rumblings,

-Pete

 

[pgrazaitis]

Right, I understand. Thats exactly why I made A.B readonly, for
arguments sake, so that the static reference will only refer to one
and only one instance of class X. All instances of class A will use B
(single instance of X). To make it easier lets throw some code out
here for examination:

public class X
{
private string _fileName = null;
public string FileName
{
get { return _fileName; }
set { if(String.IsNullOrEmpty(value) { throw new
Exception("FileName cannot be null or empty"); }
else { _fileName = value; }
}
}

public string ReadFile() { ...read content and return some piece
of content }
}

public class A
{
private readonly static X B = new X();

public void SetFile(string fileName) {
A.B.FileName = fileName;
}

public void ManageFile()
{
string temp = A.B.ReadFile();
//Perform some actions
}

}

class RunMe
{
static void Main(string[] args)
{
A instance1 = new A();
A instance2 = new A();

instance1.SetFile("C:\\temp1.txt");
instance2.SetFile("C:\\temp2.txt");


instance1.ManageFile(); //Being performed on C:
\temp2.txt not C:\temp1.txt
instance2.ManageFile(); //Being performed on C:
\temp2.txt as expected.
}
}

In this scenario there is a single instance of class X tied to static
member B in class A. Multiple instances of class A can only interact
with that one single instance of class X. In this scenario I could
make class X a static class and the behavior would be similiar.

 

[n!]

Multiple instances of class A can only interact

with that one single instance of class X. In this scenario I could
make class X a static class and the behavior would be similiar.

Well, if you made class X a static class then it would be accessible from
everywhere not just from class A. Meaning the security of X's state is not
secure and nor is the operation of class A.

It also means no other class could use X's interface without interfering
with class A (or vice-versa)

I would personally recommend that, 99% of the time, static classes not
contain any state, simply constants/readonly and functions.

ave

 

[Jon Skeet [C# MVP]]

Right, I understand. Thats exactly why I made A.B readonly, for
arguments sake, so that the static reference will only refer to one
and only one instance of class X. All instances of class A will use B
(single instance of X). To make it easier lets throw some code out
here for examination:

In this scenario there is a single instance of class X tied to static
member B in class A. Multiple instances of class A can only interact
with that one single instance of class X. In this scenario I could
make class X a static class and the behavior would be similiar.

Only if A is the only consumer of X. In real life you'll often find
that you only need one instance of something for one particular case,
but other things need multiple instances.

As an example, I sometimes have a static variable of type
Dictionary<X,Y> for some useful types X and Y. Just because I have a
static variable doesn't mean that Dictionary should be a static class -
elsewhere in the code I'm likely to use Dictionary in completely
different ways.