Copy constructors

You may also like...

9 Responses

  1. Dennis, i disslike the copy ctor because a couple of reasons.
    First of all, when you add an new member to the class you should also add this to your copy ctor. This is something that you can forget when you have some release stress.
    When you classes are marked as serializable, you can serialize and deserialize them to create a copy. Advantage of this is that is is easy to implement and generic. A disadvantage is that everything must be serializable.
    Second, why don’t you use the MemberwiseClone method? Then a subclass should implement the ICloneable interface if a shallow copy is not appropriate.

  2. The copy constructor is less known in .NET, because the Framework has the Object.MemberwiseClone (for shallow copies) and the ICloneable interface for your own cloning operation (a deep copy if you feel like it). The latter is preferred if you do not wish to expose a public constructor.

  3. I’m not in favor for using a constructor to deep copy an instance. One of the principles for good object modeling is the Minimum Parameter Rule, only properties and collaborations necessary for an object to exist should be passed into the object’s construction method.

    Another thing is… the whole reason for using a copy constructor is the level of control you get by sitting on top of the implementation details of the Customer class and the fact that you do not want to use the derived property (FirstName). The developer implementing the copy constructor has to know both the implementation details of the object’s storage and derived properties, which is acceptable in the context of the deep clone task. A bigger problem is that every other task resulting in changes in the customer class (forces working on the derived properties) has to know about the deep clone responsibility too.

    So, should the customer class be responsible for the deep clone?

  4. Perhaps I should’ve mentioned MemberwiseClone. I don’t feel happy with the ICloneable interface, but that’s probably my problem. I know of no advantage of using that interface. And for some reason, I like the copy constructor over the Clone method.

    PJ is right about the serializable part, but for me still no reason to throw away the copy constructor. Deep copies aren’t possible.

    Paul and PJ both raise the concern about keeping up with the copying and adding new members/properties/whatever. Some words about it.

    1. When you agree on copy constructors, you just have to make sure it’s always up to date. Some goes for some Clone() method. Exact same behavior. With good code reviews, you can pay attention to this.
    2. Another rule is the single-responsibility principle. Although this probably isn’t truly part of that principle, I do believe it’s the responsibility of the class itself to be able top create either a shallow or deep copy of itself.
    3. And when the Customer class changes, I don’t like some helper class to be changed as well. It’s much harder to keep track of changes in two classes, than in one class.

    But of course I’m not all knowing 🙂

  5. Dennis, I totally agree with number three. The last thing that I want is to update my helper class when my Customer class changes.

    So I totally disagree with Paul Gielens, making a class smarter will raise the IQ of the total family and makes it much easier to maintain.

    And for the ICloneable interface, this will be used by the MemberwiseClone method if implemented! So that is a great advantage of it.

  6. “making a class smarter will raise the IQ of the total family and makes it much easier to maintain.”

    It depends 😉 I’ve seen lots of smart unmentionable classes in my short career 😀

    I’m not saying it shouldn’t be responsible… just questioning. I’m leaning towards “for the copy task responsibility” since the Customer class is the place where all the gory details live. But still I dislike the fact that if I change the internal storage I have to worry about the deep copy behavior, from a developers perspective.

  7. “still I dislike the fact that if I change the internal storage I have to worry about the deep copy behavior, from a developers perspective”

    Depends. If you want (perhaps need) deep-copy behavior I’d really want it in the specific class. Because if I need to change internals, I’ll check the class itself for 80% or 90% for sure. It’s much harder to say other classes that might do the deep-copy (is this at all possible?) will be checked and adjusted.

  8. Another advantage of putting the deep-copy behavior in the class, is that you can read the private member values without using reflection and i geus it is the first place where i and others will look for the logic.

  9. fernando says:

    sorry, but that’s not deep-copying either, if firstName was a referenceType (such as a StringBuilder) it would just copy a reference to the original.

    Sallow Copy – copies ValueType only (such as strings)
    Deep Copy – copies ValueType and ReferenceType

Click on a tab to select how you'd like to leave your comment

Leave a Reply

Your email address will not be published. Required fields are marked *