473,573 Members | 2,816 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Trying to understand interfaces

RSH
Hi,

I have been reading on interfaces working on samples I've run across on the
web. For the life of me I cannot seem to grasp them.

It appears to me that interfaces are simply blueprints to a class, that when
implemented, they require the implementing calss to make sure that each of
the properties, functions etc. are handled by the class. (????)

What I am really having a problem with is how they overcome the limitation
of multiple inheritance? It would appear that interfaces simply require that
a class handles a predetermined number of properties events etc. So if I
have a class that implements an interface and I need to add functionality to
that class...I still have to add it to the interface and handle it in the
initial class...this seems redundant to me. Not to mention modifying the
interface to include the new required functionality, now makes all other
classes that implement the interface "break" and now require that I modify
all classes that implement the interface to handle the newly added
functionality.

Now I openly admit I am no OOP guru, and I am simply trying to understand
interfaces...I am certainly not bashing them.

The code below illustrates my initial attempt at understanding
interfaces...pi eced together from a few tutorials on the web.

The classes and intefaces apper below. and the instantiation of the objects
appears at the top...and will probably shed light on my lack of
understanding of interfaces.

The first instantiation illustrates the use of the interfaces:
public partial class _Default : System.Web.UI.P age

{

protected void Page_Load(objec t sender, EventArgs e)

{

IPencil p = new Pencil();

p.Type = "Pencil";

IPencil mp = new MechanicalPenci l();

mp.Type = "MechanicalPenc il";

IPencil pen = new Pen();

pen.Type = "Pen";

PencilSharpener sharpener = new PencilSharpener ();

sharpener.Sharp en(p);

sharpener.Sharp en(mp);

sharpener.Sharp en(pen);

}

Now where I get confused is that I can quite simply get the same results by
bypassing the interfaces and never calling the PencilSharpener class:

protected void Page_Load(objec t sender, EventArgs e)

{

IPencil p = new Pencil();

p.Type = "Pencil";

p.OnSharpened() ;

IPencil mp = new MechanicalPenci l();

mp.Type = "MechanicalPenc il";

IPencil pen = new Pen();

pen.Type = "Pen";

//PencilSharpener sharpener = new PencilSharpener ();

//sharpener.Sharp en(p);

//sharpener.Sharp en(mp);

//sharpener.Sharp en(pen);

}

So this is where my paridigm needs some shifting :-)

Can you please help shed some light on this? Thank you very much!

Ron


// Interfaces +++++++++++++++ +++++++++++++++ +++

//Pencil Interface

public interface IPencil

{

string Type { get; set; }

int CurrentSharpnes s { get; set; }

bool IsSharp { get; }

void Write();

void OnSharpened();

}

//Pencil Sharpener Interface

public interface IPencilSharpene r

{

void Sharpen(IPencil pencil);

}



// Classes +++++++++++++++ +++++++++++++++ +++++++

// Pencil Class

public class Pencil : IPencil

{

private string m_message;

private string m_sharpenedMess age;

private string m_type;

private int m_currentSharpn ess;

private int m_charsUsed;

private Boolean m_Sharpened = false;

// Constructor

public Pencil()

{

m_type = string.Empty;

m_currentSharpn ess = 0;

m_message = string.Empty;

m_sharpenedMess age = string.Empty;

m_charsUsed = 0;

}

// Property

public string Message

{

get { return m_message; }

}

// Property

public string SharpenedMessag e

{

get { return m_sharpenedMess age; }

}

// Property

public string Type

{

get { return m_type; }

set {

m_type = value;

m_message = "This is my " + m_type + " writing away!";

m_sharpenedMess age = "This is one sharp " + m_type + "!";

}

}

// Property

public int CurrentSharpnes s

{

get { return m_currentSharpn ess; }

set { m_currentSharpn ess = value; }

}

// Property

public bool IsSharp

{

get { return m_charsUsed <= m_currentSharpn ess; }

}

// Function

public void Write()

{

foreach (char c in m_message)

{

if (m_Sharpened == false)

{

if (IsSharp)

{

HttpContext.Cur rent.Response.W rite(c);

}

else

{

HttpContext.Cur rent.Response.W rite("#");

}

}

else

{

HttpContext.Cur rent.Response.W rite(c);

}

m_charsUsed++;

}

HttpContext.Cur rent.Response.W rite("<BR>");

}

// Function

public void OnSharpened()

{

while(this.m_cu rrentSharpness < m_message.Lengt h)

{

m_charsUsed = 0;

m_currentSharpn ess++;

Write();

}

m_Sharpened = true;

m_message = m_sharpenedMess age;

Write();

}

public void Sharpen(IPencil pencil)

{

pencil.OnSharpe ned();

}

}

// Pencil Sharpener Class

public class PencilSharpener : IPencilSharpene r

{

public void Sharpen(IPencil pencil)

{

HttpContext.Cur rent.Response.W rite("<br>Begin sharpening " + pencil.Type +
"...<br>");

pencil.OnSharpe ned();

}

}

// Pen Class

class Pen : IPencil

{

private string m_message;

private string m_sharpenedMess age;

private string m_type;

private int m_currentSharpn ess;

private int m_charsUsed;

private Boolean m_Sharpened = false;

// Constructor

public Pen()

{

m_type = string.Empty;

m_currentSharpn ess = 0;

m_message = string.Empty;

m_sharpenedMess age = string.Empty;

m_charsUsed = 0;

}

// Property

public string Message

{

get { return m_message; }

}

// Property

public string SharpenedMessag e

{

get { return m_sharpenedMess age; }

}

// Property

public string Type

{

get { return m_type; }

set { m_type = value; }

}

// Property

public int CurrentSharpnes s

{

get { return m_currentSharpn ess; }

set { m_currentSharpn ess = 0; }

}

// Property

public bool IsSharp

{

get { return m_charsUsed <= m_currentSharpn ess; }

}

public void Write()

{

HttpContext.Cur rent.Response.W rite(m_message + "<BR>");

}

// Function

public void OnSharpened()

{

m_Sharpened = true;

m_message = "A Pen cannot be sharpened!.";

Write();

}

}

// Mechanical Pencil Class

class MechanicalPenci l : IPencil, IPencilSharpene r

{

private string m_message;

private string m_sharpenedMess age;

private string m_type;

private int m_currentSharpn ess;

private int m_charsUsed;

private Boolean m_Sharpened = false;

// Constructor

public MechanicalPenci l()

{

m_type = string.Empty;

m_currentSharpn ess = 0;

m_message = string.Empty;

m_sharpenedMess age = string.Empty;

m_charsUsed = 0;

}

// Property

public string Message

{

get { return m_message; }

}

// Property

public string SharpenedMessag e

{

get { return m_sharpenedMess age; }

}

// Property

public string Type

{

get { return m_type; }

set { m_type = value; }

}

// Property

public int CurrentSharpnes s

{

get { return m_currentSharpn ess; }

set { m_currentSharpn ess = value; }

}

// Property

public bool IsSharp

{

get { return m_charsUsed <= m_currentSharpn ess; }

}

// Function

public void Write()

{

foreach (char c in m_message)

{

if (m_Sharpened == false)

{

if (IsSharp)

{

HttpContext.Cur rent.Response.W rite(c);

}

else

{

HttpContext.Cur rent.Response.W rite("#");

}

}

else

{

HttpContext.Cur rent.Response.W rite(c);

}

m_charsUsed++;

}

HttpContext.Cur rent.Response.W rite("<BR>");

}

// Function

public void OnSharpened()

{

m_Sharpened = true;

m_message = "The Mechanical Pencil is self sharpening.";

Write();

}

public void Sharpen(IPencil pencil)

{

}

}

}


Oct 20 '06 #1
22 2083
Interfaces are meant for classes that have the same behavior, but different
implementation for that behavior.

For example, a Person object might implement a Move method one way - by
walking.

A Car object might implement a Move method another way - by driving.

However, a Person and a Car, have nothing else in common. They can't share a
common ancestor.

But they can both implement the same interface. And someone with a
collection of objects implementing this interface, can call the Move method
on each of them, without regard as to whether the object is a Car, a Person,
or something else. Because they all implement the same interface, they can
all be moved.

An interface is not a blueprint for a class. If you have only one class
implementing the interface, then you shouldn't have an interface. And if
you have multiple classes implement the interface, but they all have the
same implementation, then you should be using inheritence.

"RSH" <wa************ *@yahoo.comwrot e in message
news:OX******** ********@TK2MSF TNGP02.phx.gbl. ..
Hi,

I have been reading on interfaces working on samples I've run across on
the web. For the life of me I cannot seem to grasp them.

It appears to me that interfaces are simply blueprints to a class, that
when implemented, they require the implementing calss to make sure that
each of the properties, functions etc. are handled by the class. (????)

What I am really having a problem with is how they overcome the limitation
of multiple inheritance? It would appear that interfaces simply require
that a class handles a predetermined number of properties events etc. So
if I have a class that implements an interface and I need to add
functionality to that class...I still have to add it to the interface and
handle it in the initial class...this seems redundant to me. Not to
mention modifying the interface to include the new required functionality,
now makes all other classes that implement the interface "break" and now
require that I modify all classes that implement the interface to handle
the newly added functionality.

Now I openly admit I am no OOP guru, and I am simply trying to understand
interfaces...I am certainly not bashing them.

The code below illustrates my initial attempt at understanding
interfaces...pi eced together from a few tutorials on the web.

The classes and intefaces apper below. and the instantiation of the
objects appears at the top...and will probably shed light on my lack of
understanding of interfaces.

The first instantiation illustrates the use of the interfaces:
public partial class _Default : System.Web.UI.P age

{

protected void Page_Load(objec t sender, EventArgs e)

{

IPencil p = new Pencil();

p.Type = "Pencil";

IPencil mp = new MechanicalPenci l();

mp.Type = "MechanicalPenc il";

IPencil pen = new Pen();

pen.Type = "Pen";

PencilSharpener sharpener = new PencilSharpener ();

sharpener.Sharp en(p);

sharpener.Sharp en(mp);

sharpener.Sharp en(pen);

}

Now where I get confused is that I can quite simply get the same results
by bypassing the interfaces and never calling the PencilSharpener class:

protected void Page_Load(objec t sender, EventArgs e)

{

IPencil p = new Pencil();

p.Type = "Pencil";

p.OnSharpened() ;

IPencil mp = new MechanicalPenci l();

mp.Type = "MechanicalPenc il";

IPencil pen = new Pen();

pen.Type = "Pen";

//PencilSharpener sharpener = new PencilSharpener ();

//sharpener.Sharp en(p);

//sharpener.Sharp en(mp);

//sharpener.Sharp en(pen);

}

So this is where my paridigm needs some shifting :-)

Can you please help shed some light on this? Thank you very much!

Ron


// Interfaces +++++++++++++++ +++++++++++++++ +++

//Pencil Interface

public interface IPencil

{

string Type { get; set; }

int CurrentSharpnes s { get; set; }

bool IsSharp { get; }

void Write();

void OnSharpened();

}

//Pencil Sharpener Interface

public interface IPencilSharpene r

{

void Sharpen(IPencil pencil);

}



// Classes +++++++++++++++ +++++++++++++++ +++++++

// Pencil Class

public class Pencil : IPencil

{

private string m_message;

private string m_sharpenedMess age;

private string m_type;

private int m_currentSharpn ess;

private int m_charsUsed;

private Boolean m_Sharpened = false;

// Constructor

public Pencil()

{

m_type = string.Empty;

m_currentSharpn ess = 0;

m_message = string.Empty;

m_sharpenedMess age = string.Empty;

m_charsUsed = 0;

}

// Property

public string Message

{

get { return m_message; }

}

// Property

public string SharpenedMessag e

{

get { return m_sharpenedMess age; }

}

// Property

public string Type

{

get { return m_type; }

set {

m_type = value;

m_message = "This is my " + m_type + " writing away!";

m_sharpenedMess age = "This is one sharp " + m_type + "!";

}

}

// Property

public int CurrentSharpnes s

{

get { return m_currentSharpn ess; }

set { m_currentSharpn ess = value; }

}

// Property

public bool IsSharp

{

get { return m_charsUsed <= m_currentSharpn ess; }

}

// Function

public void Write()

{

foreach (char c in m_message)

{

if (m_Sharpened == false)

{

if (IsSharp)

{

HttpContext.Cur rent.Response.W rite(c);

}

else

{

HttpContext.Cur rent.Response.W rite("#");

}

}

else

{

HttpContext.Cur rent.Response.W rite(c);

}

m_charsUsed++;

}

HttpContext.Cur rent.Response.W rite("<BR>");

}

// Function

public void OnSharpened()

{

while(this.m_cu rrentSharpness < m_message.Lengt h)

{

m_charsUsed = 0;

m_currentSharpn ess++;

Write();

}

m_Sharpened = true;

m_message = m_sharpenedMess age;

Write();

}

public void Sharpen(IPencil pencil)

{

pencil.OnSharpe ned();

}

}

// Pencil Sharpener Class

public class PencilSharpener : IPencilSharpene r

{

public void Sharpen(IPencil pencil)

{

HttpContext.Cur rent.Response.W rite("<br>Begin sharpening " + pencil.Type +
"...<br>");

pencil.OnSharpe ned();

}

}

// Pen Class

class Pen : IPencil

{

private string m_message;

private string m_sharpenedMess age;

private string m_type;

private int m_currentSharpn ess;

private int m_charsUsed;

private Boolean m_Sharpened = false;

// Constructor

public Pen()

{

m_type = string.Empty;

m_currentSharpn ess = 0;

m_message = string.Empty;

m_sharpenedMess age = string.Empty;

m_charsUsed = 0;

}

// Property

public string Message

{

get { return m_message; }

}

// Property

public string SharpenedMessag e

{

get { return m_sharpenedMess age; }

}

// Property

public string Type

{

get { return m_type; }

set { m_type = value; }

}

// Property

public int CurrentSharpnes s

{

get { return m_currentSharpn ess; }

set { m_currentSharpn ess = 0; }

}

// Property

public bool IsSharp

{

get { return m_charsUsed <= m_currentSharpn ess; }

}

public void Write()

{

HttpContext.Cur rent.Response.W rite(m_message + "<BR>");

}

// Function

public void OnSharpened()

{

m_Sharpened = true;

m_message = "A Pen cannot be sharpened!.";

Write();

}

}

// Mechanical Pencil Class

class MechanicalPenci l : IPencil, IPencilSharpene r

{

private string m_message;

private string m_sharpenedMess age;

private string m_type;

private int m_currentSharpn ess;

private int m_charsUsed;

private Boolean m_Sharpened = false;

// Constructor

public MechanicalPenci l()

{

m_type = string.Empty;

m_currentSharpn ess = 0;

m_message = string.Empty;

m_sharpenedMess age = string.Empty;

m_charsUsed = 0;

}

// Property

public string Message

{

get { return m_message; }

}

// Property

public string SharpenedMessag e

{

get { return m_sharpenedMess age; }

}

// Property

public string Type

{

get { return m_type; }

set { m_type = value; }

}

// Property

public int CurrentSharpnes s

{

get { return m_currentSharpn ess; }

set { m_currentSharpn ess = value; }

}

// Property

public bool IsSharp

{

get { return m_charsUsed <= m_currentSharpn ess; }

}

// Function

public void Write()

{

foreach (char c in m_message)

{

if (m_Sharpened == false)

{

if (IsSharp)

{

HttpContext.Cur rent.Response.W rite(c);

}

else

{

HttpContext.Cur rent.Response.W rite("#");

}

}

else

{

HttpContext.Cur rent.Response.W rite(c);

}

m_charsUsed++;

}

HttpContext.Cur rent.Response.W rite("<BR>");

}

// Function

public void OnSharpened()

{

m_Sharpened = true;

m_message = "The Mechanical Pencil is self sharpening.";

Write();

}

public void Sharpen(IPencil pencil)

{

}

}

}


Oct 20 '06 #2
Interfaces also allow you to group areas of functionality which makes
developing simpler.
For example imagine a wheel object representing a wheel with a tyre on
it. You might expect to see methods and properties like , width,
height, tread pattern, spoke style, valve, inflate, polish, deflate,
tyremake, hubmake, tyremanufacture r, hubmanufacturer .

Now when you're programming against that wheel you're going to see a
huge list of properties and it might not be immediately clear what they
do.
Now have a wheel object that implements IHub and ITyre things become
clearer. you know IHub.polish will polish the hub, previously you might
have inadvertantly polished the tyre. You can also now remove
tyremanufacture r and hubmanufacturer and simply have manufacturer on
each of the interfaces.

Oct 20 '06 #3
RSH
Am I correct in that they provide no real direct functionality themselves?
Instead they simply provide a way to ensure that instantiating objects
comply a predetermined set of rules. ...And provide a mechanism for future
development against the class that enlightens the developers on the class's
mandatory properties, and functions?
"DeveloperX " <nn*****@operam ail.comwrote in message
news:11******** *************@i 42g2000cwa.goog legroups.com...
Interfaces also allow you to group areas of functionality which makes
developing simpler.
For example imagine a wheel object representing a wheel with a tyre on
it. You might expect to see methods and properties like , width,
height, tread pattern, spoke style, valve, inflate, polish, deflate,
tyremake, hubmake, tyremanufacture r, hubmanufacturer .

Now when you're programming against that wheel you're going to see a
huge list of properties and it might not be immediately clear what they
do.
Now have a wheel object that implements IHub and ITyre things become
clearer. you know IHub.polish will polish the hub, previously you might
have inadvertantly polished the tyre. You can also now remove
tyremanufacture r and hubmanufacturer and simply have manufacturer on
each of the interfaces.

Oct 20 '06 #4

RSH wrote:
Am I correct in that they provide no real direct functionality themselves?
Instead they simply provide a way to ensure that instantiating objects
comply a predetermined set of rules. ...And provide a mechanism for future
development against the class that enlightens the developers on the class's
mandatory properties, and functions?
"DeveloperX " <nn*****@operam ail.comwrote in message
news:11******** *************@i 42g2000cwa.goog legroups.com...
Interfaces also allow you to group areas of functionality which makes
developing simpler.
For example imagine a wheel object representing a wheel with a tyre on
it. You might expect to see methods and properties like , width,
height, tread pattern, spoke style, valve, inflate, polish, deflate,
tyremake, hubmake, tyremanufacture r, hubmanufacturer .

Now when you're programming against that wheel you're going to see a
huge list of properties and it might not be immediately clear what they
do.
Now have a wheel object that implements IHub and ITyre things become
clearer. you know IHub.polish will polish the hub, previously you might
have inadvertantly polished the tyre. You can also now remove
tyremanufacture r and hubmanufacturer and simply have manufacturer on
each of the interfaces.
Yeah, you hear alot of people describe them as contracts. You know if
it implements an interface it supports what ever functionality is
provided by the interface.

Oct 20 '06 #5
Yup.
They're a real boon in things like distributed applications where the server
knows of the interface but has no way of knowing the concrete type
definitions.
They're ESPECIALLY useful for testing, so to test your classes you send them
a "mock" object that implements the interface being used, but rather then
doing anything useful it just records how the interface is being used so you
can make sure it's being used correctly.

The problem with the example you provided is that your interface was
IPencil, then you ended up trying to force a Pen into being a pencil and a
mechanised pencil into being a pencil.
It should have been IWritingImpleme nt or something like that. OnSharpen
should not have existed, you should have tried mebbe a different interface
like IBreakable with
bool IsBroken and
void Fix(IServicePro vider services);

You could then "fix" the pencil by sharpening it, the pen by... buying a new
pen and the mechanical one by getting an engineer from the services and
making him fix it.
That would probably given you better abstraction and have made more sense.
Also the type property is not necessary. All objects have GetType().Name on
them already.

HTH

Simon Tamman

"RSH" <wa************ *@yahoo.comwrot e in message
news:uL******** ******@TK2MSFTN GP02.phx.gbl...
Am I correct in that they provide no real direct functionality themselves?
Instead they simply provide a way to ensure that instantiating objects
comply a predetermined set of rules. ...And provide a mechanism for
future
development against the class that enlightens the developers on the
class's
mandatory properties, and functions?
"DeveloperX " <nn*****@operam ail.comwrote in message
news:11******** *************@i 42g2000cwa.goog legroups.com...
Interfaces also allow you to group areas of functionality which makes
developing simpler.
For example imagine a wheel object representing a wheel with a tyre on
it. You might expect to see methods and properties like , width,
height, tread pattern, spoke style, valve, inflate, polish, deflate,
tyremake, hubmake, tyremanufacture r, hubmanufacturer .

Now when you're programming against that wheel you're going to see a
huge list of properties and it might not be immediately clear what they
do.
Now have a wheel object that implements IHub and ITyre things become
clearer. you know IHub.polish will polish the hub, previously you might
have inadvertantly polished the tyre. You can also now remove
tyremanufacture r and hubmanufacturer and simply have manufacturer on
each of the interfaces.


Oct 20 '06 #6
PS

"RSH" <wa************ *@yahoo.comwrot e in message
news:OX******** ********@TK2MSF TNGP02.phx.gbl. ..
Hi,

I have been reading on interfaces working on samples I've run across on
the web. For the life of me I cannot seem to grasp them.

It appears to me that interfaces are simply blueprints to a class, that
when implemented, they require the implementing calss to make sure that
each of the properties, functions etc. are handled by the class. (????)

What I am really having a problem with is how they overcome the limitation
of multiple inheritance? It would appear that interfaces simply require
that a class handles a predetermined number of properties events etc. So
if I have a class that implements an interface and I need to add
functionality to that class...I still have to add it to the interface and
handle it in the initial class...this seems redundant to me. Not to
mention modifying the interface to include the new required functionality,
now makes all other classes that implement the interface "break" and now
require that I modify all classes that implement the interface to handle
the newly added functionality.

Now I openly admit I am no OOP guru, and I am simply trying to understand
interfaces...I am certainly not bashing them.

The code below illustrates my initial attempt at understanding
interfaces...pi eced together from a few tutorials on the web.
First I would not think a Pen is a Pencil so your interface might be better
as IWritingInstrum ent.

IWritingInstrum ent pencil = new Pencil();
IWritingInstrum ent mp = new MechanicalPenci l();
IWritingInstrum ent pen = new Pen();

sharpenWritingI nstrument(penci l);
sharpenWritingI nstrument(mp);
sharpenWritingI nstrument(pen);

private void sharpenWritingI nstrument(IWrit ingInstrument wi)
{
if(wi.IsBlunt)
wi.Sharpen();
}

PS

Oct 20 '06 #7
"DeveloperX " <nn*****@operam ail.comwrote in message
news:11******** *************@i 42g2000cwa.goog legroups.com...
Now have a wheel object that implements IHub and ITyre things become
clearer.
I think this would not be a good idea, because a wheel is not a hub nor is
it a tire. A wheel is composed of these things, so a wheel has a hub and a
tire.

///ark
Oct 20 '06 #8
Hi Ron,

<snip>
It appears to me that interfaces are simply blueprints to a class, that when
implemented, they require the implementing calss to make sure that each of
the properties, functions etc. are handled by the class. (????)
You can implement an interface and leave all of the members empty, or throw
NotSupportExcep tions, or whatever you want. They can't enforce that the
members are handled in any certain way. Instead interfaces define a public
contract that an implementing class must provide to its consumers; enforced by
compilers [and the CLR?].

You can do whatever you want in the interface so long as it doesn't break the
public contract, though certain interfaces do imply constraints on how the
interface should be implemented. i.e., An interface's public behavior. One
such example is the following:

interface IDoThings
{
bool CanDoSomethingF oo { get; }
bool CanDoSomethingB ar { get; }

void DoSomethingFoo( );
void DoSomethingBar( )
}

It will be obvious to callers that CanDoSomethingF oo could be verified as true
before attempting to call DoSomethingFoo. Therefore, implementations must
make sure that CanDoSomethingF oo returns whether DoSomethingFoo can be called.
In this respect interfaces aren't "simply blueprints", but instead also imply
behavioral aspects of all their implementations .

(In .NET, you can define explicit interface implementations so that the
contract exists on the implementing class but it can only be used if the
consumer explicitly casts an instance of the class to the Type of the
explicitly-implemented interface. In other words, you can hide an
implementation of an interface, although consumers can still cast the class to
the interface if desired.)
What I am really having a problem with is how they overcome the limitation
of multiple inheritance?
(I think whether multiple inheritance is a "limitation " is up for debate.)

Regardless, interfaces can't overcome this "limitation " because they don't
provide implementation. Interfaces only provide a public contract. As a
developer you can use the public contracts provided by multiple interfaces on
your class, but you'll still have to code each implementation. In other
words, your class is not actually inheriting the functionality from another
class by implementing an interface. However, you can define multiple
interfaces and implement them on multiple classes so that all of the classes
share the same interface Types, which can't be done using inheritance, but
you'll still have to code each implementation yourself so all that you'd
really gain is shared public contracts spanning multiple concrete
implementations that you had to code anyway.
It would appear that interfaces simply require that a class handles a
predetermined number of properties events etc.
..NET doesn't require that interface members are handled, just that the public
members exist, even if only explicitly.
So if I have a class that implements an interface and I need to add
functionality to that class...I still have to add it to the interface and
handle it in the initial class...this seems redundant to me.
You don't have to do anything ;)

If you are using an interface for any of the reasons found in this thread, or
the many other reasons that haven't been mentioned, then you'll know whether
you have to add new members to the declaration of your interfaces or just the
classes that implement them. As Marina pointed out, you really don't need the
interface if you are only implementing it on one class (and you have no
intention of it being used externally), therefore it will be clear if you are
using an interface and implementing it on multiple classes, whether each class
requires the new member or only one of the particular implementations requires
the new member.

If each implementing class requires the new member, and the interface should
logically contain that member, then add the member to the interface, otherwise
define a new interface or just add the member to the requiring classes. This
is a simplistic rule that doesn't make sense in every circumstance, but is a
good starting point. Other things to consider are versioning requirements,
whether modifying the interface is worth breaking the contract, and whether an
interface is even useful for the new members at all.
Not to mention modifying the interface to include the new required
functionality, now makes all other classes that implement the interface
"break" and now require that I modify all classes that implement the
interface to handle the newly added functionality.
That's why you shouldn't add the new member unless it can be used by all of
the implementing classes. (Or more commonly, unless it can be used by most of
the implementing classes). Remember that you can always define another
interface instead for new members if only a subset of the classes implementing
the current interface can use the new members. Each class in the subset can
implement both interfaces, which is one great advantage of interfaces over
inheritance.

<snip>

--
Dave Sexton
Oct 20 '06 #9
RSH
Thanks all!

This is some really goosd stuff...and thank you Dave for that incredibly
clear explanation!!!!

Dare I post my updated code. I modified it based on my new interpretation
of interfaces.
Any comments or feedback would be greatly appreciated. I'm pretty new at
this stuff :-)

THANKS!

Ron

public partial class _Default : System.Web.UI.P age

{

protected void Page_Load(objec t sender, EventArgs e)

{

IWritingInstrum ent pencil = new Pencil();

pencil.Write();

pencil.IsWritin gPoorly = true;

pencil.IsBroken = true;

IWritingInstrum ent mpencil = new MechanicalPenci l();

mpencil.Write() ;

mpencil.IsWriti ngPoorly = true;

mpencil.IsBroke n = true;

IWritingInstrum ent pen = new Pen();

pen.Write();

pen.IsWritingPo orly = true;

pen.IsBroken = true;

}

// Interfaces +++++++++++++++ +++++++++++++++ +++

//Writing Implement Interface

public interface IRepair

{

bool IsWritingPoorly { get; set; }

void Write();

void Fix();

}

//Is Breakable Interface

public interface IReplace

{

bool IsBroken { get; set; }

void Replace();

}

//Combine Interfaces

public interface IWritingInstrum ent : IRepair, IReplace

{

}

// Classes +++++++++++++++ +++++++++++++++ +++++++

// Pencil Class

public class Pencil : IWritingInstrum ent

{

private string m_message;

private Boolean m_isWritingPoor ly;

private Boolean m_isBroken;

// Constructor

public Pencil()

{

m_isWritingPoor ly = false;

m_isBroken = false;

m_message = "";

}

// Property

public Boolean IsBroken

{

get { return m_isBroken; }

set

{

m_message = "The " + this.GetType(). Name + " appears to be Broken...we will
replace it for you...";

Write();

Replace();

m_isBroken = false;

}

}

// Property

public bool IsWritingPoorly

{

get { return m_isWritingPoor ly; }

set

{

m_message = "The " + this.GetType(). Name + " appears to be Dull...we will
sharpen it for you...";

Write();

Fix();

m_isWritingPoor ly = false;

}

}

// Function

public void Write()

{

HttpContext.Cur rent.Response.W rite(m_message + "<BR>");

}

// Function

public void Fix()

{

m_message = "The " + this.GetType(). Name + " was sharpened and is now
working great!<br>";

Write();

}

public void Replace()

{

m_message = "The " + this.GetType(). Name + " was replaced.<br>";

Write();

}

}

// Pen Class

public class Pen : IWritingInstrum ent

{

private string m_message;

private Boolean m_isWritingPoor ly;

private Boolean m_isBroken;

// Constructor

public Pen()

{

m_isWritingPoor ly = false;

m_isBroken = false;

m_message = "";

}

// Property

public Boolean IsBroken

{

get { return m_isBroken; }

set

{

m_message = "The " + this.GetType(). Name + " appears to be Broken...we will
replace it for you...";

Write();

Replace();

m_isBroken = false;

}

}

// Property

public bool IsWritingPoorly

{

get { return m_isWritingPoor ly; }

set

{

m_message = "The " + this.GetType(). Name + " appears to be out of ink...we
will refill it for you...";

Write();

Fix();

m_isWritingPoor ly = false;

}

}

// Function

public void Write()

{

HttpContext.Cur rent.Response.W rite(m_message + "<BR>");

}

// Function

public void Fix()

{

m_message = "The " + this.GetType(). Name + " was refilled and is now working
great!<br>";

Write();

}

public void Replace()

{

m_message = "The " + this.GetType(). Name + " was replaced.<br>";

Write();

}

}

// MechanicalPenci l Class

public class MechanicalPenci l : IWritingInstrum ent

{

private string m_message;

private Boolean m_isWritingPoor ly;

private Boolean m_isBroken;

// Constructor

public MechanicalPenci l()

{

m_isWritingPoor ly = false;

m_isBroken = false;

m_message = "";

}

// Property

public Boolean IsBroken

{

get { return m_isBroken; }

set

{

m_message = "The " + this.GetType(). Name + " appears to be Broken...we will
replace it for you...";

Write();

Replace();

m_isBroken = false;

}

}

// Property

public bool IsWritingPoorly

{

get { return m_isWritingPoor ly; }

set

{

m_message = "The " + this.GetType(). Name + " appears to be out of lead...we
will replace the lead for you...";

Write();

Fix();

m_isWritingPoor ly = false;

}

}

// Function

public void Write()

{

HttpContext.Cur rent.Response.W rite(m_message + "<BR>");

}

// Function

public void Fix()

{

m_message = "The " + this.GetType(). Name + "'s lead was replaced and is now
working great!<br>";

Write();

}

public void Replace()

{

m_message = "The " + this.GetType(). Name + " was replaced.<br>";

Write();

}

}

}


Oct 20 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
1503
by: Tom | last post by:
Hello, I've recently started trying to learn C (for the fun of it!). I have been using Perl and other languages for many years, but they were always very high level, this is giving me quite a ride. Here is my situation: I have the following code: ////////////////////////////////////////////////////////////
6
1906
by: dotNeter | last post by:
The services, talked here, are things used in IServiceContainer, IServiceProvider, etc. In my opinion, everything can be a service, and a service is generally used for providing specific features for service consumers, at design time. But, I think the cnsumers must completely know all aspects of that service. This sounds not good, and breaks...
27
3833
by: jm | last post by:
I am having trouble understanding the purposes of an interface, even though the concept of interfaces is around me all the time (user interface, for example). I'm just not understanding software interfaces. Like anything else, it appears Interfaces are by design something that requires documentation. I know this may be obvious, but if I...
0
8037
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
1
7799
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
8080
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
6430
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5604
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
3737
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3742
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2226
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
0
1048
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.