Interfaces used always with new classes, why?

  • Thread starter Thread starter Kiran
  • Start date Start date
K

Kiran

Hi,

As a convention we always create interfaces before creating classes for
class libraries.

we then implement this interface in a class.

Can someone point out the reasons\advantages for doing this in a simple way.

Thanks
Kiran
 
Not sure I understand your question. Who is "we" because I have not heard
of that being a convention? Some people may not know they need an interface
until they created some classes and observed the similar methods being
created. Other do just what you do because they recognize the need for a
interface and just want to define it so that class is forced to implement it
immediately.
 
Kiran said:
Hi,

As a convention we always create interfaces before creating classes for
class libraries.

we then implement this interface in a class.

Can someone point out the reasons\advantages for doing this in a simple
way.
Click to expand...


Say you want to input a Day and get back the temperature for that Day.

But you want it to be global, so some use Fahrenheit, some Celsius.


The inteface is the same,

int temp(DateTime day)


But the calculations behind the method are different and it returns
different values.
 
Peter said:
Not sure I understand your question. Who is "we" because I have not heard
of that being a convention? Some people may not know they need an interface
until they created some classes and observed the similar methods being
created. Other do just what you do because they recognize the need for a
interface and just want to define it so that class is forced to implement it
immediately.
Click to expand...
Hi Peter,

we do it that way in our project, are there any performance\security
issue in this

Thanks
Kiran
 
John said:
Say you want to input a Day and get back the temperature for that Day.

But you want it to be global, so some use Fahrenheit, some Celsius.


The inteface is the same,

int temp(DateTime day)


But the calculations behind the method are different and it returns
different values.
Click to expand...
Hi John,

so it's a reusability thing, is performance\security related to this

Thanks
Kiran
 
There are no security or performance issues related to just defining
interfaces before the class.

Security and performance come from the design of the overall code base, not
on the order that things get implemented.
 
Peter said:
There are no security or performance issues related to just defining
interfaces before the class.

Security and performance come from the design of the overall code base, not
on the order that things get implemented.
Click to expand...
Thanks John
 
Peter said:
There are no security or performance issues related to just defining
interfaces before the class.

Security and performance come from the design of the overall code base, not
on the order that things get implemented.
Click to expand...
Thanks Peter
 
Or you may want one collection class to be able to operate on particular
members across similar classes that require a certain operation.
Implementing the same interface to those classes will make this very
possible, as the collection members are defined relative to that interface.

Maybe you have a method that does a desired operation on data members (sorry
for redefining a method ), again across classes (maybe similar or can even
be different), such a method that takes an interface as an parameter will
make this very possible as that interface will be implemented to those
classes. Containing the relevant members to be implemented

Not really convention, as for reason, could be the above, I worked for one
place where the architects bestowed interfaces to the coders that had to
implement before coding the class bodies, why? I guess as well as extreme
programming we also have totalitarian programming. But everyone was happy in
the end, documentation was also allot easier.

- SpotNet

: Kiran wrote:
: > Hi,
: >
: > As a convention we always create interfaces before creating classes for
: > class libraries.
: >
: > we then implement this interface in a class.
: >
: > Can someone point out the reasons\advantages for doing this in a simple
: > way.
:
:
: Say you want to input a Day and get back the temperature for that Day.
:
: But you want it to be global, so some use Fahrenheit, some Celsius.
:
:
: The inteface is the same,
:
: int temp(DateTime day)
:
:
: But the calculations behind the method are different and it returns
: different values.
:
:
:
:
:
: >
: > Thanks
: > Kiran
 
Well, you should not do this for *every* class, it is unneccessary. If
yoiur coding guidelines are to do that then it indicates that the person
who wrote the guidelines either did not understand OO principles or was
too lazy to do a proper OO design. Interface programming is extremely
powerful when used correctly.

Well, I don't think that this is a good example, the 'interface' is the
same, but the behaviour is not. The problem is that the return value
from the method must be interpretted in different ways depending on
whether it returns C or F. Interface programming is all about
*behaviours*, that is, you don't care how the code performs the action,
all you care about is what it does.

A better example is an interface that tells a shape to render itself (ie
draw itself).

in code:

interface IRender
{
void RenderMe(Graphics g);
}

Any object with a visual interface can render itself. The object knows
how toi draw itself. The caller does not care how this is performed, or
what the shape is like, all it cares aout is the behaviour that the
shape will draw itself in the Graphics context.

class Square : IRender
{
// other code
public void RenderMe(Graphics g){/*code here*/}
}

class Circle : IRender
{
// other code
public void RenderMe(Graphics g){/*code here*/}
}

class Window : Form
{
List<IRender> shapes;
public Init()
{
// fill the shapes collection with Circles and Squares
}
public override void Paint(PaintEventArgs e)
{
foreach(IRender render in shapes)
{
// This code does not care if the shape is a Circle or a
Square
// all it cares is that it can draw itself
render->RenderMe(e.Graphics);
}
base.Paint(e);
}
}

Richard
 
Back
Top