I would say that just because code has been written and tested does
not make it a good design.
In C++ I can do the following ...
public class Triangle { }
public class Square { }
public class Shape : Triangle, Square { }
it will compile, I will be able to test it, but it really is not good
design
In C# I can do this ....
// in assembly A
namespace A {
public class ClassA {
private ClassB _classB;
public ClassA(ClassB b) { _classB = b; }
}
// in assembly B
namespace B {
public class ClassB {
private ClassC _classC;
public ClassA(ClassC c) { _classC = c; }
}
// in assembly C
namespace C {
public class ClassC {
private ClassA _classA;
public ClassA(ClassA a) { _classA = a; }
}
This does not necessarilymake a good design.
On Apr 14, 8:52 pm, BaRuSa <[email protected]> wrote:
> >> 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 -- 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.
