Interfaces used always with new classes, why?

[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

[Peter Rilling]

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" <so*****@somewhere.com> wrote in message
news:eI**************@TK2MSFTNGP12.phx.gbl...

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

[John Bailo]

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

[Kiran]

Peter Rilling wrote:

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" <so*****@somewhere.com> wrote in message
news:eI**************@TK2MSFTNGP12.phx.gbl...

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

Hi Peter,

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

Thanks
Kiran

[Kiran]

John Bailo wrote:

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

Hi John,

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

Thanks
Kiran

[Peter Rilling]

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.

"Kiran" <so*****@somewhere.com> wrote in message
news:%2***************@TK2MSFTNGP14.phx.gbl...

John Bailo wrote:

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

Hi John,

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

Thanks
Kiran

[Kiran]

Peter Rilling wrote:

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.

"Kiran" <so*****@somewhere.com> wrote in message
news:%2***************@TK2MSFTNGP14.phx.gbl...

John Bailo wrote:

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

Hi John,

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

Thanks
Kiran

Thanks John

[Kiran]

Peter Rilling wrote:

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.

"Kiran" <so*****@somewhere.com> wrote in message
news:%2***************@TK2MSFTNGP14.phx.gbl...

John Bailo wrote:

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

Hi John,

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

Thanks
Kiran

Thanks Peter

[SpotNet]

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

"John Bailo" <ja*****@texeme.com> wrote in message
news:43**************@texeme.com...
: 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

[Richard Grimes [MVP]]

Kiran wrote:

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.

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.
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)

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
--
Free .NET tutorials,
Fusion: http://www.grimes.demon.co.uk/workshops/fusionWS.htm
Security: http://www.grimes.demon.co.uk/workshops/securityWS.htm