>> public class MyImpl : AbstractExample
>> {
>> public MyImpl(string s) : base(s) { }
>> public MyImpl(IExampleInterface iei) : base(iei) { }
>>}
The MyImpl class works perfectly fine in the .NET framework because at
compile time 's' is a string and 'iei' is an IExampleInterface
regardless of what data they hold (or don't hold). Thus the following
overly simple code compiles and runs.
MyImpl first = new MyImpl("TEST");
MyImpl second = new MyImpl(first);
Correct,
var instance = MyImpl(null);
is a compile time error. This is a completely acceptable result for
so many reasons I won't even count them.
// The birth of a string some where in code
string externalString = GetStringFromExternalSource();
// Do Stuff
var instance = MyImpl(externalString);
The developer of AbstractExample has no control of
GetStringFromExternalSource or what happens to externalString before
it enters AbstractExample. If externalString is null, there is no
compile time error because the compiler knows which constructor to
call. Neither the compile time nor run time knows that having
externalString as null is bad. Only the implementer of
AbstractExample knows that receiving null is bad. Thus it is the
obligation of the AbstractExample developer to inform the user of
AbstractExample that null is bad, which is frequently done through the
use of an exception.
>> My advice would be to think more carefully about what it is that yor
>> object is suppoed to be doing.
This is what the objects are supposed to be doing.
A.) Have a common interface to support polymorphic features. (using
interface)
B.) Have a base class to support shared functionality that interact
with immutable fields. (using abstract class)
C.) Have different class types that have different data types. (this
part is working)
D.) Set immutable data in the base class at the time of
construction. (The data happens to be a reference object that accepts
null.)
E.) Copy immutable data in the base class from another similar object
at the time of construction. (That object also happens to be a
reference object that accepts null.)
That code has been written. Everthing works and is tested except we
haven't found a good way to test D. and E. receiving null.
On Apr 14, 11:38 am, bill richards <[email protected]>
wrote:
> My answer to this is that you have a flawed design in AbstractExample.
>
> Firstly, if you had developed this in a TDD fashion, you would not end
> up with an object that takes two types as alternate constructors.
>
> My advice would be to think more carefully about what it is that yor
> object is suppoed to be doing. Quite frankly, even the .net framework
> would be confused
>
> public class MyImpl : AbstractExample
> {
> public MyImpl(string s) : base(s) { }
> public MyImpl(IExampleInterface iei) : base(iei) { }
>
> }
>
> var instance = MyImpl(null); ... what constructor should be invoked?
>
> On Apr 14, 3:34 pm, BaRuSa <[email protected]> wrote:
>
>
>
> > Simplified example of a class:
>
> > abstract class AbstractExample : IExampleInterface
> > {
> > protected AbstractExample(string name) { /* Do Stuff */ }
> > protected AbstractExample(IExampleInterface deepCopy) { /* Do Stuff
> > */ }
> > // abstract methods
>
> > }
>
> > Simpiflied test for constructor:
>
> > [ExpectedException(typeof(ArgumentNullException))]
> > void Test()
> > {
> > AbstractExample example;
> > string name;
>
> > name = null;
> > example = MockRepository.GenerateStrictMock<AbstractExample>(name);
>
> > }
>
> > The test creates an exception
> > "System.Reflection.AmbiguousMatchException: Ambiguous match found." I
> > am assuming the problem is there are two constructors that could
> > accept null, but Rhino Mocks doesn't know which type to use. I know
> > there are constraints that be placed on methods; are there constraints
> > for calling constructors? Is there a different solution I am not
> > thinking about?- Hide quoted text -
>
> - Show quoted text -
--
You received this message because you are subscribed to the Google Groups
"Rhino.Mocks" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rhinomocks?hl=en.
