5

First of all, I would like to know if passing an object as parameter is much better than creating another object again in a class that will use it again and second what are the pros and cons of each one?

Here's an example:

public class ClassWithTheObject
{

TheObject obj = new TheObject();

// Somewhere around the code
PassTheObjectHere anotherObj = new PassTheObjectHere(obj);

}

Or just go straight declaring the class TheObject inside the PassTheObjectHere class? The case would be that both ClassWithTheObject and PassTheObjectHere classes will use the TheObject class.

Last question, is passing the object too many times causes some bad effects on the program?

Please enlighten me.

  • 3
    I feel like you've been reading up on Dependency Injection and are now unsure how to put it into practice. Creating object instances within a class makes code practically untestable. Good code is testable code. Those are my two cents. – Alternatex Dec 4 '14 at 9:03
  • Depends a lot on what kind of class TheObject is. If it's something service or policy like, pass it in. – CodesInChaos Dec 4 '14 at 11:59
3

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 you 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". You can pass objects around 1000 times correctly, which is fine, and one time wrong, which is bad. For example, if you pass 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 you caller does something like

public class ClassWithTheObject
{

   TheObject obj = new TheObject();
   obj.Initialize()
   PassTheObjectHere anotherObj = new PassTheObjectHere(obj);
   obj.MethodWhichExpectsObjToBeValid();
}

then your program now has a bug. There are mainly the following alternatives to protect you from that:

  1. Avoid the side effect by not changing "obj" within the constructor
  2. If you need to change "obj", make a copy beforehand within the constructor.
  3. do not add any methods to TheObject which allow the change of any internal state of obj (which is called "immutability")

Number 3 leads to the same code as 1, but with the additional protection against introducing unintentional side effects at a later point in time, when PassTheObjectHere might be changed.

4

It's a bit more complicated than that.

Firstly, understand the tradeoffs. If you are going to pass a copy of the object (essentially "pass by value" semantics) rather than a reference to the original object, you are going to take a performance hit. Whether that hit is justified or not depends on your software's functional requirements.

Secondly, it might make more sense semantically to write methods that accept the object by reference but return a new object, rather than modifying the passed object in-place or making a copy of it before passing it to the method.

var modified object = ReturnANewObjectFrom(theOriginalObject);

When you create and return new objects in this fashion, you are taking advantage of immutability. Wherever immutability makes sense, this makes sense to do. Programs which utilize immutable objects and data structures are easier to reason about, especially when writing concurrent applications (applications that do more than one thing at a time, usually in separate threads or on separate cores).

  • quite an answer... but im looking for a more straight forward answer as I am not that familiar with using immutable objects as of now. thanks anyway... – arvicxyz Dec 4 '14 at 7:17
  • I'm not sure I agree with the premise: ... is essentially a Copy Constructor. Objects are passed by reference* in C# (which this seems to be, although I guess it could be something else). This code could be as simple example of DI, where does the copy constructor come in, am I missing something? * To be clear, the reference itself is passed by value, but the object referred to is not copied. – Daniel B Dec 4 '14 at 7:19
  • I guess you misunderstood the question, OP is not thinking about a copy constructor. – Doc Brown Dec 4 '14 at 8:37
1

I think it really depends on the context you are working with. In your example, you are sending the TheObject instance to the PassTheObjectHere constructor, this way of working tells me that, inside your PassTheObjectHere instance, you are working with some previous initializated data. So if the ClassWithTheObject is going to share the conversational state of the TheObject instance, you are doing right. Thats what i think

  • thanks for sharing your thought. if that would be the case then thank you... – arvicxyz Dec 4 '14 at 7:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.