Tony Johansson wrote:
Hello!
I have a class definition called MyClass see below.
I create an instance of this class MyClass
I also want this instance to be able to modify the test instance that exist
in this class.
I can make the instance of this class MyClass to be able to access the
instance test in two ways.
I can either pass an instance of this class MyClass in the c-tor and assign
the instance to the test field.
I can also use a set property by calling the property. Here I set an
instance to the test field.
public MyClass Test
{
set {myTest= value;}
}
Now to my question is it bad programming to use the second method which was
to use a property to set the instance test in the object.
A disadvantage to use a C-tor is if I want to add another argument to a
C-tor and this C-tor is called in many different forms I have to change in
many places.
If I instead use the property to set the test instance in the class it is
sufficient to add just a call to the setter property.
public class MyClass
{
private MyClass test;
public MyClass(...)
{
}
public MyClass Test
{
set {myTest= value;}
}
}
//Tony
For me, the question of what arguments should go on the constructor is
really a different question: what constitutes a "correctly formed
instance" of your object? By that I mean, what is the minimum amount of
information that must be set in your object in order that it be usable
by a client application? Then, within that set, which ones have
defaults? Any object property that is required in order that the object
be usable and that has no default must be passed on the constructor.
Either that or you implement hokey schemes like "Valid" properties that
your client has to test before they try to use an object instance.
If every MyClass object has to have a Test object, or the original
MyClass object is useless, and there is no such thing as a default Test
object, then put it on the constructor. This means, "If you don't pass
me one of these then I can't function properly." If the Test object is
optional, or if you can provide a default Test object if one isn't
supplied, then make it a settable property and leave it off the minimal
constructor.
You might have it on the constructor _and_ a property if it's required
for the proper functioning of every MyClass instance, but it's also
changeable by the client.
Oh, yeah. That's another consideration: can the client reasonably
change this Test object during the execution of a program? If not, even
if it's not required, then it should be on a constructor, even if it's
optional (there are other constructors that don't require it). If so,
then you should provide a settable property, and it may or may not be a
parameter to a constructor (for convenience).
(Of course, as another poster pointed out, if you have a circular class
reference like this, there must be a way to create an instance without
supplying a Test object, or you could never create the first one. This
way of creating a Test instance, though, does not need to be directly
accessible to client programs.)
