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

[Peter Duniho]

On Mon, 21 Apr 2008 20:46:25 -0700, <pg********@gmail.comwrote:

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?

No, you don't. You have a static member in class A that refers to one of
potentially many instances of class X.

Ok, I cant change the actual pointer to the
instance of Class X;

What pointer? Do you mean reference? Why can't you change it? Is A.B
readonly? And if it is, why does that matter with respect to other
instances of 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 you modify the instance of X referenced by A.B, then yes...that
instance is affected. No other instance of X would be affected though.

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.

Absolutely not.

Per
the original design of class X, the class invariant is ok. However,
with "implied staticness" I have a potential issue in its use.

There's no "implied staticness".

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.

You cannot create an object "as static". By definition, an instance isn't
static. It might be referred to by something else that is static, but the
instance itself would not be static.

-Is "implied staticness" true?

No.

-Does this force a refactoring of class X to account for static usage/
thread safety/static based invariants?

Static and thread-safety are orthogonal. They have nothing to do with
each other, except inasmuch as a class that's not thread-safe can be used
safely by threads by having any given instance known and/or used by only
one thread at a time.

Regardless, since there's no "implied staticness", obviously there's no
forced "anything" as a consequence of "implied staticness".

*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?

Impossible to say, as we still know basically nothing about your class.

-Should I reconsider the design of class A for static usage/thread
safety/staticbased invariants?

Do you need your class to be thread-safe?

*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?

Why? I mean, I suppose a factory might be appropriate. But there's no
way to know for sure, since you didn't tell us anything about your classes.

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]]

<pg********@gmail.comwrote:

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:

<snip>

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,Yfor 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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Peter Duniho]

On Tue, 22 Apr 2008 06:05:51 -0700, <pg********@gmail.comwrote:

[...]
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.

Similar, but not identical. In particular, you haven't done anything here
that introduces "staticness" to class X. It's not even true that multiple
instances of class A "can only interact with that one single instance of
class X". It's true that if they use the B member, they will only ever
get that one instance. But any instance of A is free to create a new
instance of X and use that instead. And any other code, even outside
class A, can create new instances of class X.

I repeat: nothing about your example has introduced any sort of
"staticness" to class X.

Pete