Property, interface, inheritance and cast

  • Thread starter Thread starter fred
  • Start date Start date
F

fred

Hi,
Why should I do a cast (IOfferSetter) in the constructor of the Test
class?
Thanks.
Fred

public interface IOfferSetter { object Offer { set;} }

public class OfferCtx
{
protected object offer;
public object Offer { get { return offer; } }
}

public class OfferCtx2 : OfferCtx, IOfferSetter
{
object IOfferSetter.Offer
{
set { offer = value; }
}
}

public class Test
{
public Test()
{
OfferCtx2 ctx = new OfferCtx2();
((IOfferSetter)ctx).Offer = 10;
object off = ctx.Offer;
}
}
 
<[email protected]> a écrit dans le message de (e-mail address removed)...

| Why should I do a cast (IOfferSetter) in the constructor of the Test
| class?

Because you have used "explicit interface implementation" to implement the
Offer property of IOfferSetter.

This means that the Offer property is private when viewed from an OfferCtx2
instance, only becoming visible when viewed through an IOfferSetter
interface reference.

If you want to access the property from an OfferCtx2 reference, then you
need to declare the property using "implicit interface implementation"

public interface IOfferSetter { object Offer { set;} }

public class OfferCtx
{
private object offer;

protected void SetOffer(object value)
{
offer = value;
}

public object Offer
{
get { return offer; }
}
}

Don't use protected fields always use at least a protected method.

public class OfferCtx2 : OfferCtx, IOfferSetter
{
public new object Offer
{
get { return base.Offer; }
set { offer = value; }
}
}

This re-declaration of the Offer property will cause a compiler warning that
the base property will be hidden, thus the need for "new" in the
declaration.

.... then you can do this :

public class Test
{
public Test()
{
OfferCtx2 ctx = new OfferCtx2();
ctx.Offer = 10;
object off = ctx.Offer;
}
}

Finally, if you intend to store numbers in the Offer property, don't declare
the field/property as object; this will incur a boxing/unboxing speed
penalty. Use a type appropriate to the value being stored.

Joanna
 
Thanks for your advise.
The problem is that I didn't want to use the "new" keyword because you
must always write code for the getter implementation (even if it's just
a base call), which is error prone (In our case, we will have many many
classes that will use the getter and very few that will use the
setter). What I would have liked to write is the following

public interface IOfferSetter { object Offer { set; } }

public class OfferCtx
{
public object Offer { get { /* code */ } }
}
public class OfferCtx2 : OfferCtx, IOfferSetter
{
public object Offer
{
set { /* code */ }
}
}

It does not compile and that's why I cannot use the implicit interface
implementation.
I was just wondering why the compiler complains about the
OfferCtx2.Offer property hiding the inherited one. In this case, there
is no ambiguity. It would hide something if a getter was defined in
OfferCtx2.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top