www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Interfaces and Unit testing

reply Erik Meer <e m.com> writes:
Does using interfaces extensively have a performance drawback like using
inheritance has?

Why do I ask? I was thinking about adopting a coding practice where I define
explicit interfaces for all public aspects of my classes, and then couples the
interfaces closely to unit tests. Then, whenever I would create a new class
using some of these interfaces the unit tests would tag along, which means the
unit tests would be reusable.

Now, if the compiler has do align stuff in some arduous way to accommodate
these interfaces then this whole idea might not be worth it? Or are interfaces
a no-cost constraint on the implementation?

Erik Meer
Feb 18 2011
next sibling parent Kagamin <spam here.lot> writes:
Erik Meer Wrote:


 Does using interfaces extensively have a performance drawback like using
inheritance has?
 
 Why do I ask? I was thinking about adopting a coding practice where I define
explicit interfaces for all public aspects of my classes, and then couples the
interfaces closely to unit tests. Then, whenever I would create a new class
using some of these interfaces the unit tests would tag along, which means the
unit tests would be reusable.
 
 Now, if the compiler has do align stuff in some arduous way to accommodate
these interfaces then this whole idea might not be worth it? Or are interfaces
a no-cost constraint on the implementation?
 
 Erik Meer


So you want interfaces only for unittests and won't use them in your code?
Feb 18 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 18 Feb 2011 09:43:19 -0500, Erik Meer <e m.com> wrote:


 Does using interfaces extensively have a performance drawback like using  
 inheritance has?

 Why do I ask? I was thinking about adopting a coding practice where I  
 define explicit interfaces for all public aspects of my classes, and  
 then couples the interfaces closely to unit tests. Then, whenever I  
 would create a new class using some of these interfaces the unit tests  
 would tag along, which means the unit tests would be reusable.

 Now, if the compiler has do align stuff in some arduous way to  
 accommodate these interfaces then this whole idea might not be worth it?  
 Or are interfaces a no-cost constraint on the implementation?


There is a real cost associated with interfaces.  Each additional  
interface on a class requires another pointer-sized word space.  I would  
recommend not adding interfaces if the sole purpose is to use them for  
unit tests.

You can reuse unit tests by creating a template function.

example:

// all classes that define foo conform to the foo definition.

class X
{
    int foo() {...}
}

class Y
{
    int foo() {...}
}

unittest
{
    void testFoo(T)(T t) { assert(t.foo() == 0); }
    testFoo(new X);
    testFoo(new Y);
}

-Steve
Feb 18 2011
parent Erik Meer <e m.com> writes:
Steven Schveighoffer Wrote:


 On Fri, 18 Feb 2011 09:43:19 -0500, Erik Meer <e m.com> wrote:
 

 Does using interfaces extensively have a performance drawback like using  
 inheritance has?

 Why do I ask? I was thinking about adopting a coding practice where I  
 define explicit interfaces for all public aspects of my classes, and  
 then couples the interfaces closely to unit tests. Then, whenever I  
 would create a new class using some of these interfaces the unit tests  
 would tag along, which means the unit tests would be reusable.

 Now, if the compiler has do align stuff in some arduous way to  
 accommodate these interfaces then this whole idea might not be worth it?  
 Or are interfaces a no-cost constraint on the implementation?


 
 There is a real cost associated with interfaces.  Each additional  
 interface on a class requires another pointer-sized word space.  I would  
 recommend not adding interfaces if the sole purpose is to use them for  
 unit tests.
 
 You can reuse unit tests by creating a template function.
 
 example:
 
 // all classes that define foo conform to the foo definition.
 
 class X
 {
     int foo() {...}
 }
 
 class Y
 {
     int foo() {...}
 }
 
 unittest
 {
     void testFoo(T)(T t) { assert(t.foo() == 0); }
     testFoo(new X);
     testFoo(new Y);
 }
 
 -Steve



Excellent! In addition to not introducing overhead, this is better because the
"interface" is entirely verified by the unit test, i.e. you don't have to name
it when defining the class.
Thanks, guys!
Feb 18 2011
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
As mentioned by Steven there are other ways to this without Interfaces.
Templates are one very nice way and you may also find:

AutoImplements
BlackHole
WhiteHole

http://digitalmars.com/d/2.0/phobos/std_typecons.html#AutoImplement

Useful. I thought there was also going to be something that would take a given
class and derive it from a base class to assume the type. But I guess that
isn't in Phobos.
Feb 18 2011