Interface Inheritance Q?

Ware Work

I have created the following:

public interface ICalculatable
{
DateTime FirstPaymentDate { get; }
decimal MonthlyCompoundingRate { get; }
}

public interface IBaseObject : ICalculatable
{
string Identifier { get; }
// Input Value
DateTime FirstPaymentDate { get; set; }
// Input Value
decimal InterestRate { get; set; }
}

public class BaseObject : IBaseObject
{
...
}

I get a compiler error that need new to hide inherited member. I am trying to figure out if that is the correct thing or I need to use virtual/override/etc.. instead. I will be accessing the BaseObject as ICalculatable in other code and the FirstPaymentDate properties should be the same value/source. Thanks in advance.

WarePhreak Programmers are tools to convert caffiene to code.

mark_w_

in ICalculatable FirstPaymentDate just has a get in IBaseObject (which implements ICalculatable) it has a get and a set, so the compiler is saying its not being implemented with the same signature, therefore you need to add the new keyword to hide the base FirstPaymentDate in ICalculatable like so

public interface ICalculatable
{
    DateTime FirstPaymentDate { get; }  
    decimal MonthlyCompoundingRate { get; }
}

public interface IBaseObject : ICalculatable
{
    string Identifier { get; }
    new DateTime FirstPaymentDate { get; set; }
    decimal InterestRate { get; set; }
}

EDIT I have just reread your question and the above does not help does it :doh: Best way is to try it out in a demo project

led mike

Ware@Work wrote:

the FirstPaymentDate properties should be the same value/source.

IBaseObject has no value/source. Only the implementer does so this is not relevant to your scenario. It might be possible for the implementer to explicitly implement the two interfaces giving the implemented class different value/source. I have never tried it because, well it seems like a bad idea. Also it is possible that there is different design than the two interfaces you are using that might better suit your needs. Perhaps reading Allen Holub discuss why Getters and Setters are Evil[^] will help you.

led mike

Ware Work

led mike wrote:

Perhaps reading Allen Holub discuss why Getters and Setters are Evil[^] will help you.

Read the article but it is focused more on the class design. If I understand it correctly, I am doing fine because I am creating an interface to define the contract that will be passed around. I will have a calculator object that accepts the ICalculatable as a parameter to a RunCalc method. This will ensure I have access to the values I need to do the calculation. BaseObject is a business object. The calculator object will be business intelligence. I don't care about the actual implementation under the covers. How do I define IBaseObject to imply that the FirstPaymentDate property is the same in both the IBaseObject definition and the ICalculatable definition?

WarePhreak Programmers are tools to convert caffiene to code.

J4amieC

Ware@Work wrote:

How do I define IBaseObject to imply that the FirstPaymentDate property is the same in both the IBaseObject definition and the ICalculatable definition?

You leave it off of IBaseObject altogether, as IBaseObject inhertits from ICalculatable (and assuming you implicitly implement the interface) any instance of a class which implements IBaseObject will have access to the required method. Scratch all that, I see it is get/set in IBaseObject and get only in ICalculatable. In which case I would do it as follows:

public class BaseObject : IBaseObject
{

#region IBaseObject Members

public string Identifier
{
    get { throw new NotImplementedException(); }
}

public DateTime FirstPaymentDate
{
    get
    {
        throw new NotImplementedException();
    }
    set
    {
        throw new NotImplementedException();
    }
}

public decimal InterestRate
{
    get
    {
        throw new NotImplementedException();
    }
    set
    {
        throw new NotImplementedException();
    }
}

#endregion

#region ICalculatable Members


public decimal MonthlyCompoundingRate
{
    get { throw new NotImplementedException(); }
}

#endregion

}

Anything that has a reference to BaseObject (or IBaseObject) can get/set FirstPaymentdate. However anything with a reference to ICalculatable will only be able to get.

Ware Work

You got into the implementation. I want to define the contract so that any object that satifies IBaseObject will by nature satisfy ICalulatable and be usable as such. Is using new on FirstPaymentDate the correct way to do so? I tried using virtual/override and it wouldn't let me do that. So I am beginnining to believe it must be. Thanks all for the help.

WarePhreak Programmers are tools to convert caffiene to code.

J4amieC

The Interfaces seem absolutely fine to me. And I was just demonstrating how I would implement those interfaces in a base class.

mark_w_

does this help

class Program
{
static void Main(string[] args)
{
Three inst = new Three();

        inst.Name = "Hello"; // has get and set

        IOne foo = new Three();
        //foo.Name = "Hello" // Readonly only

        ITwo bar = new Three();
        bar.Name = "Hello"; //has get and set
    }
}


    public interface IOne
    {
        string Name { get; } 
    }
    public interface ITwo : IOne
    {   
        new string Name { get;set;  }   
    }
    
    public class Three : ITwo
    {
        private string \_name;
        #region ITwo Members

        public string Name
        {
            get
            {
                return \_name;
            }
            set
            {
                \_name = value;
            }
        }

        #endregion
    }

Ennis Ray Lynch Jr

I think it is a new error message in the 2005 and later version of the compiler. I think the 1.1 allows this. The best way, I have found, to get around this error is to create another common interface such as IHasFirstPaymentDate. Then IBaseObject and ICalculateable can both inherit without the warning.

Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.