Attach constants to an interface

[_DD]

I've encountered situations that call for an interface but also
require enums/constants that go hand-in-hand with the interface.
Abstract classes won't do, cause I may need to inherit more than one.
Any elegant solutions come to mind?

[kh]

Perhaps I've misunderstood your question, but is this not something that can
be achieved with a property defined on the interface with only a getter (i.e.
a read-only property)? Obviously you cannot define values within the
interface definition, but in this way you can require your implementors to
supply one...

interface IMyInterface
{
string Name { get; }
}

class MyClass : IMyInterface
{
public string Name
{
get { return "Foo"; }
}
}

[Jon Skeet [C# MVP]]

_DD <_D*@nospam.com > wrote:

I've encountered situations that call for an interface but also
require enums/constants that go hand-in-hand with the interface.
Abstract classes won't do, cause I may need to inherit more than one.
Any elegant solutions come to mind?

Just use a separate enum type. Just because two concepts are related
doesn't mean they have to be part of the same type.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[_DD]

On Mon, 15 May 2006 00:01:02 -0700, kh <kh@newsgroups. nospam> wrote:

Perhaps I've misunderstood your question, but is this not something that can
be achieved with a property defined on the interface with only a getter (i.e.
a read-only property)? Obviously you cannot define values within the
interface definition, but in this way you can require your implementors to
supply one...

I was thinking of simple constants. For instance, if an interface had
a function: PaintBackground Purple(), it would make sense to have a
defined Purple that could travel with the interface. In other words,
the implementation of how to paint the background would be variable,
but you don't want the particular shade of Purple to vary. Everyone
that implements the interface would use the same Purple.

In that sense, it would be nice to have tighter coupling between the
Interface and the defined colors that it is using.

This may not be the perfect example, but I do run into variants on the
scenario once in a while.

I understand that allowing constants within the Interface could result
in diamond inheritance, with multiple Purple defines converging when
multiple interfaces are inherited, but I was wondering if there is
another way to implement this.

[Jon Skeet [C# MVP]]

_DD <_D*@nospam.com > wrote:

On Mon, 15 May 2006 00:01:02 -0700, kh <kh@newsgroups. nospam> wrote:

Perhaps I've misunderstood your question, but is this not something that can
be achieved with a property defined on the interface with only a getter (i.e.
a read-only property)? Obviously you cannot define values within the
interface definition, but in this way you can require your implementors to
supply one...

I was thinking of simple constants. For instance, if an interface had
a function: PaintBackground Purple(), it would make sense to have a
defined Purple that could travel with the interface. In other words,
the implementation of how to paint the background would be variable,
but you don't want the particular shade of Purple to vary. Everyone
that implements the interface would use the same Purple.

In that sense, it would be nice to have tighter coupling between the
Interface and the defined colors that it is using.

It seems more sensible to have PaintBackground (PredefinedColo r) and
have a PredefinedColor enum to go alongside the interface.

I just don't see the advantage of having the constants *in* the
interface rather than as a separate type to go alongside it.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[steve]

Sorry I don't know a way of introducing simple constants within interfaces
You might be able to get an equivalent *look-and-feel* through nested
namespaces.

I think that being able to introduce constants into interfaces is very
important since some interfaces have a real-world analogy.

eg. // Contrived example

interface IRS232_Physical
{
const int MIN_LINE_VOLTAG E = -12;
const int MAX_LINE_VOLTAG E = 12;

void public ToggleRTS(bool TurnOn);
void public TransmitHolding Reg();

// ...
}

class USBToRS232Conve rter: IWin32SerialAPI , IUSBStack, IRS232_Physical
{
public void TransmitHolding Reg()
{
// Get TX Holding Reg

// Send Start Bits

// Send Data Bits

// Send Stop Bits
}
}

"_DD" wrote:

I've encountered situations that call for an interface but also
require enums/constants that go hand-in-hand with the interface.
Abstract classes won't do, cause I may need to inherit more than one.
Any elegant solutions come to mind?

[Barry Kelly]

steve <st***@discussi ons.microsoft.c omwrote:

I think that being able to introduce constants into interfaces is very
important since some interfaces have a real-world analogy.

eg. // Contrived example

interface IRS232_Physical
{
const int MIN_LINE_VOLTAG E = -12;
const int MAX_LINE_VOLTAG E = 12;

void public ToggleRTS(bool TurnOn);
void public TransmitHolding Reg();

// ...

This looks awfully like the Java Constant Interface Antipattern
(Effective Java (http://java.sun.com/docs/books/effective/) Item 17).

-- Barry

--
http://barrkel.blogspot.com/

[steve]

The Java cons... what??? Me not speaka da language ; )

Never heard of it sorry. I'll put it in the to have a look at basket.

Ciao,

Steve

"Barry Kelly" wrote:

steve <st***@discussi ons.microsoft.c omwrote:

I think that being able to introduce constants into interfaces is very
important since some interfaces have a real-world analogy.

eg. // Contrived example

interface IRS232_Physical
{
const int MIN_LINE_VOLTAG E = -12;
const int MAX_LINE_VOLTAG E = 12;

void public ToggleRTS(bool TurnOn);
void public TransmitHolding Reg();

// ...

This looks awfully like the Java Constant Interface Antipattern
(Effective Java (http://java.sun.com/docs/books/effective/) Item 17).

-- Barry

--
http://barrkel.blogspot.com/