Your question shows some misconceptions, I guess: if the alternative to
passing an object as parameter
is to create a new instance directly in the constructor PassTheObjectHere
, then you are obviously not using any values/state of the previously created obj
within PassTheObjectHere
. If that is the case, it is pretty useless to pass obj
as a parameter to PassTheObjectHere
. In fact, in such a case I would typically check if TheObject
has any member variables, which might make it a candidate for a static class (but don't get me wrong, I am not telling the usage of a static class would improve the design here in any way).
On the other hand, if the constructor of PassTheObjectHere
needs the values / state of the previously created obj
to work properly, it would be plain wrong to have a constructor like this.
PassTheObjectHere()
{
var obj = new TheObject();
// ... do something which expects having obj
// ... some values provided by the caller
}
(I hope this is obvious).
can passing the object too many times cause some bad effects on the program?
This is not a question of "too many times". One can pass objects around 1000 times correctly, which is fine, and one time wrong, which is bad. For example, if one passes obj
to the constructor, and the constructor changes the state of obj
in a way the caller does not expect (called a "side effect")
PassTheObjectHere(TheObject obj)
{
// ... use methods/properties/values of obj
// ... for this constructor
// and finally
obj.MakeValuesInvalid();
}
and the caller does something like
public class ClassWithTheObject
{
TheObject obj = new TheObject();
obj.Initialize()
PassTheObjectHere anotherObj = new PassTheObjectHere(obj);
obj.MethodWhichExpectsObjToBeValid();
}
then the program now has a bug.
Fortunately, one can use one of the following alternatives to protect oneself from that:
- Avoid the side effect by not changing "obj" within the constructor
- If one needs to change "obj", they can make a copy beforehand within the constructor.
- Avoid adding methods to
TheObject
which allow the change of internal state of obj (which is called "immutability")
Number 3 leads to the same code as 1, but with additional protection against introducing unintentional side effects at a later point in time, when PassTheObjectHere
might be changed.
TheObject
is. If it's something service or policy like, pass it in.