Jesse,
Six of one, half dozen of the other. One benefit that I
could see is that it would enable you to have a private
constructor with some kind of factory method to generate
the instances from which you could then clone.
The issue that it gets around is that it allows you to
use that particular constructor:
public MyClass(MyClass x) { ... }
As a chaining mechanism, perhaps in a validation pipeline
that you might construct in your business logic. Others
may have better reasons.
----------------------------------------
- Mitch Denny
- [EMAIL PROTECTED]
- http://www.monash.net
- +61 (414) 610-141
-
-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED]] On Behalf Of Jesse Liberty
Sent: Wednesday, 14 August 2002 9:02 PM
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] Copy constructor vs. ICloneable
Is there a good design reason to favor implementing ICloneable rather
than implementing a copy constructor?
-j
-------------------------------
Jesse Liberty, President
Liberty Associates, Inc.
.NET Programming and Training
http://www.LibertyAssociates.com
You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or subscribe to other DevelopMentor lists at
http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
