We Keep Coding

What's wrong in this interface use?

Suppose to have an interface like this:
interface MyInterface
{
public string AProperty { get; set;}
public void AMethod ()
}
This interface is used inside another interface:
interface AnotherInterface
{
public MyInterface member1 { get; set; }
public int YetAnotherProperty {get; set;}
}
Now suppose to have two classes, one that implements each of the interfaces.
class MyInterfaceImpl : MyInterface
{
private string aproperty
public string AProperty
{
//... get and set inside
}
public void AMethod ()
{
//... do something
}
}
And at last:
class AnotherInterfaceImpl : AnotherInterface
{
private MyInterfaceImpl _member1;
public MyIntefaceImpl member1
{
//... get and set inside
}
...Other implementation
}
Why does the compiler complain that AnotherInterfaceImpl does not implement MyInterface?
I understand it is a very basic question... but I need to serialize to xml AnotherInterfaceImpl and I cannot do that if member1 is of type MyInterface.

Your class AnotherInterfaceImpl is not actually implementing all members of AnotherInterface. The public property AnotherInterfaceImpl.member1 must have type MyInterface, not MyInterfaceImpl.
Note that this restriction only applies to the public property. The private field AnotherInterfaceImpl._member1 can still be of type MyInterfaceImpl, because MyInterfaceImpl implements MyInterface.

Why the compiler complains that AnotherInterfaceImpl does not implement MyInterface?
Because it doesn't implement it. It has a member that implements it.
That is like saying "my customer object has an orders (list) property; how come my customer isn't a list?"
If you had either:
interface AnotherInterface : MyInterface
or
class AnotherInterfaceImpl : AnotherInterface, MyInterface
then it would be true to say that AnotherInterfaceImpl implemented MyInterface.

you need to "explicitly" type your members as the interface defines them.
class AnotherInterfaceImpl : AnotherInterface
{
private MyInterfaceImpl _member1;
public MyInteface member1
{
get{ return _member1;}
set{ _member1 = value;}
}
...Other implementation
}

How to automatically copy a property declaration to base class

I have a property A in all subclasses of base class Base.
How can I generate an abstract property definition of property A into base class Base?
I know ReSharper's refactoring Pull Members Up, but that moves the property to base class.
I need an abstract property in base class and a overriding properties in all sub classes. Is there a refactoring in Visual Studio or in ReSharper that can do it automatically for me?

There is a checkbox "Make abstract" for that in ReSharper Pull Members Up dialog :

I'm not sure Resharper can move up and create an abstraction as you want automatically, but you can atleast define it manually like this
In abstract class:
public abstract double A
{
get;
}
In Sub class:
public override double A
{
get
{
return 3.141;
}
}
It might be a clearner design to define a new Interface (or use an existing one) and define the property in the interface. That way, your existing subclasses won't have to use override.

public interface IInterface {
string MyProperty { get; }
}
public class Class : IInterface {
public string MyProperty { get; set; }
}
public abstract class AbstractClass {
public abstract string Value { get; }
}
public class ConcreteClass : AbstractClass {
private string m_Value;
public override string Value {
get { return m_Value; }
}
public void SetValue(string value) {
m_Value = value;
}
}
I hope this will be helpful to you.

Can an interface require a property, but not specify a required type?

I have a simple interface, defined as such:
interface iFace
{
int Value { get; }
}
In this case, any class implementing iFace must have a property named Value of type int. The usage of this interface is going to be with databinding, and I don't care what type the property is. Do I have any options? I'd like to avoid this solution:
interface iFace<T>
{
T Value { get; }
}
as I'd like to refer to the interface without specifying type
Edit:
I'd like to be able able to apply the same interface to both a NumericUpDown control, and a Trackbar control. One's value property is of type decimal, and the other is of type int.
Having the property be of type object wouldn't work in this case.

If you don't care whether it is strictly-typed, change the property type to object.

Try this:
interface MyInterface
{
Object MyProperty
{
get;
set;
}
}
class MyClass : MyInterface
{
Object MyInterface.MyProperty
{
get
{
return this.MyProperty;
}
set
{
if (value is MyType)
this.MyProperty = (MyType)value;
}
}
public MyType MyProperty
{
get;
set;
}
}

In response to your edit: You're coming up against the well-known problem that .NET has no INumeric interface. It exists in source code I've seen, but it has been commented out, which implies that Microsoft has taken it seriously enough and run into some significant issues with it.
Danny Varod's solution is a good one; you can also extend it by creating a generic and a non-generic version of the interface. Another solution is to add methods to the interface that represent the numeric operations for which you're now using mathematical operators, like Increment(), for example.
I'll call the interface IHasValue here (partly because it is somewhat comedic):
interface IHasValue
{
object Value { get; set; }
void Increment();
void Decrement();
}
interface IHasValue<TValue> : IHasValue { new TValue Value { get; set; } }
abstract class UpDownValueControl<T> : IHasValue<T>
{
public T Value { get; set; }
object IHasValue.Value
{
get { return this.Value; }
set { this.Value = (T)value; }
}
public abstract void Increment();
public abstract void Decrement();
}
class NumericUpDownControl : UpDownValueControl<decimal>
{
public override void Increment() { Value++; }
public override void Decrement() { Value--; }
//rest of the implementation
}
class TrackbarControl : UpDownValueControl<int>
{
public override void Increment() { Value++; }
public override void Decrement() { Value--; }
//rest of the implementation
}
It's frustrating that the base class can't take care of repetitive code like the increment and decrement methods, but at least this approach allows the base class to take care of everything else aside from the repetitive mathematical operator code.
I suspect, in the end, that the complexity of this solution adds more cost than benefit; I think I'd be more likely to go with something like Danny Varod's solution.

Class Design - Base class with Generic Descendant

I have the following classes
class GridBase
{
public object DataSource { get; set; }
}
class GenericGrid<T> : GridBase
{
public new T DataSource { get; set; }
}
Both GridBase and Generic Grid classes can be instantiated and one can descend from either as well.
Is this considered the correct/accepted way to implement such a hierarchy?
Or should you go the extra mile and implement it like the following
class GridBase
{
protected object dataSource;
public object DataSource { get { return dataSource; } set { dataSource = value; } }
}
class GenericGrid<T> : GridBase
{
public new T DataSource { get { return (T)dataSource; } set { dataSource = value; } }
}
The same applies to non generic classes when a property is re-introduced in a descendant, I'm just using a generic example here.
Another case and question
abstract class SomeBase
{
protected abstract void DoSomething();
}
class Child : SomeBase
{
protected override void DoSomething()
{
/* Some implementation here */
}
}
The situation here is that framework "X" declares SomeBase allowing you to define your own descendants. The classes they create (at run time) then descend from your class (Child in the this case). However, they don't call your DoSomething() method, from their implementation of DoSomething().
On their part, they can't blindly call base.Dosomething() either because the typical case is that the class they generate normally descends from SomeBase and since the method is abstract that's not valid. (Personally, I don't like this behavior in C#).
But anyway, is that good or accepted design, that is not calling base.xxx(), especially when the the "intent" seems to contradict?
EDIT From a framework design perspective. Is it ok/acceptable that it does this? If not how would it be designed so as to either prevent such a case or better impart their intent (in both cases).

I would prefer something like this:
interface IGrid {
object DataSource { get; }
}
interface IGrid<T> {
T DataSource { get; }
}
public Grid : IGrid {
public object DataSource { get; private set; }
// details elided
}
public Grid<T> : IGrid<T> {
public T DataSource { get; private set; }
object IGrid.DataSource { get { return this.DataSource; } }
// details elided
}
Note that I am NOT inheriting from Grid.

For the DataSource question I prefer the following pattern
abstract class GridBase {
public abstract object DataSource { get; }
}
class GenericGrid<T> : GridBase {
private T m_data;
public override object DataSource {
get { return m_data; }
}
public T DataSourceTyped {
get { return m_data; }
set { m_data = value; }
}
}
Reasons
Having the GridBase.DataSource member be writable is type unsafe. It allows me to break the contract of GenericGrid<T> by setting the value to a non-T instance
This is more of a matter of opinion but I dislike the use of new because it often confuses users. I prefer the suffix ~Type" for this scenario
This only requires the data be stored once
Doesn't require any unsafe casting.
EDIT OP corrected that GridBase and GenericGrid are both usable types
In that case I would say you need to reconsider your design a bit. Having them both as usable types opens you up to very easy to expose type errors.
GenericGrid<int> grid = new GenericGrid<int>();
GridBase baseGrid = grid;
baseGrid.DataSource = "bad";
Console.Write(grid.DataSource); // Error!!!
The design will be a lot more reliable if separate the storage from the access of the values in a manner like my original sample. You could extend it further with the following code to have a usable non-generic container
class Grid : GridBase {
private objecm m_data;
public override object DataSource {
get { return m_data; }
}
public object DataSourceTyped {
get { return m_data; }
set { m_data = value; }
}
}

The second form of the generic inheritance (casting the base class' attribute) is more correct as it does not violate Liskov Substitution Principle. It is conceivable that an instance of the generic class is cast into base class and accessing Data through the base class points to a different property. You will need to keep both in sync in order for the derived class to be substitutable for the base class.
Alternatively, you can implement some sort of a strategy pattern where the base class asks for the Data property from the derived class, in order to avoid awkward downcasting. This is what I had in mind:
public class Base {
private readonly object m_Data; //immutable data, as per JaredPar suggestion that base class shouldn't be able to change it
publlic Base(object data) {
m_Data = data;
}
protected virtual object GetData() {return m_Data;}
public Object DataSource {get {return GetData();}}
}
public class Derived<T> : Base {
private T m_Data;
public Derived():base(null){}
protected override object GetData() {return m_Data;}
protected new T Data {return m_Data;}
}
With regards to the second question, I am note sure I understand the question. Sound like the problem you are having is to with the framework not calling the abstract method when it generates a proxy at runtime, which is always legal in abstract classes, as the only way for that code to execute is through a derived class which must override the abstract method.

Override get, but not set

I have an abstract class that defines a get, but not set, because as far as that abstract class is concerned, it needs only a get.
public abstract BaseClass
{
public abstract double MyPop
{get;}
}
However, in some of the derive class, I need a set property, so I am looking at this implementation
public class DClass: BaseClass
{
public override double MyPop
{get;set;}
}
The problem is, I got a compilation error, saying that
*.set: cannot override because *. does not have an overridable set accessor.
Even though I think that the above syntax is perfectly legitimate.
Any idea on this? Workaround, or why this is so?
Edit: The only approach I can think of is to put both get and set as in the abstract class, and let the subclass throws a NotImplementedException if set is called and it's not necessary. That's something I don't like, along with a special setter method .

One possible answer would be to override the getter, and then to implement a separate setter method. If you don't want the property setter to be defined in the base, you don't have many other options.
public override double MyPop
{
get { return _myPop; }
}
public void SetMyPop(double value)
{
_myPop = value;
}

New in C# 6.0:
If you are only calling the setter within your constructor, you can resolve this problem using read-only properties.
void Main()
{
BaseClass demo = new DClass(3.6);
}
public abstract class BaseClass
{
public abstract double MyPop{ get; }
}
public class DClass : BaseClass
{
public override double MyPop { get; }
public DClass(double myPop) { MyPop = myPop;}
}

It is not possible to do what you want. You have to define the setter in the abstract property, otherwise you won't be able to override it properly.
The only case I know where a getter is defined and a getter/setter are implemented is by using an interface:
public interface IBaseInterface
{
double MyPop { get; }
}
public class DClass : IBaseInterface
{
public double MyPop { get; set; }
}

If BaseClass is in your own codebase, then you can do:
abstract public class BaseClass
{
abstract public double MyPop { get; protected set; }
}
public class DClass : BaseClass
{
private double _myProp;
public override double MyProp
{
get { return _myProp; }
protected set { _myProp = value; }
}
}
EDIT: You can then go make a public method in DClass SetMyProp(double myProp) or the like. The class design for your domain model should be clear about or speak for itself why you can't set the property directly in the base class and why you can do so in the derived one.

Are you sure that doing what you are trying to do would be a good design if you found a way to do it?
It would allow objects of the subclass to make state changes that objects of the parent class can not make. Wouldn't that violate the Liskov Substitution Principle?

You could do something like this:
abstract class TestBase
{
public abstract int Int { get; }
}
class TestDerivedHelper : TestBase
{
private int _Int;
public override int Int
{
get
{
return _Int;
}
}
protected void SetInt(int value)
{
this._Int = value;
}
}
class TestDerived : TestDerivedHelper
{
public new int Int
{
get { return base.Int; }
set { base.SetInt(value); }
}
}
Using TestDerived will have the functionality you're looking for. The only drawback I can see from this method is that you have to implement every abstract method in TestDerivedHelper, but it gives you more control later.
Hope this helps. ;)

The reason that this is not possible is due to the way parameters are "Magicked" into existence by C#. When you define a parameter, C# creates a private field that the implicit getter and setter manipulate. If there is no setter in the base class, it's impossible to change this variable from a method written in a sub class (as the private flag prohibits even sub classes from accessing it). What usually happens is it uses the implicit setter of the base class instead.
I wouldn't advise putting the set in the base class if not all sub classes can do it, because this goes against the whole principle of polymorphic programming (any abstract method defined in the abstract class must be implemented by a subclass). Creating a special setter method, as described in other answers is probably the best way go.

Siege
abstract class TestBase
{
public abstract int Int { get; }
}
class TestDerivedHelper : TestBase
{
private int _Int;
public override int Int
{
get
{
return _Int;
}
}
protected void SetInt(int value)
{
this._Int = value;
}
}
class TestDerived : TestDerivedHelper
{
public new int Int
{
get { return base.Int; }
set { base.SetInt(value); }
}
}
Using TestDerived will have the functionality you're looking for. The
only drawback I can see from this method is that you have to implement
every abstract method in TestDerivedHelper, but it gives you more
control later.
I use this approach and works very well for me.
Also, I made my "TestDerivedHelper" class abstract too, then all the methods must be implemented on "TestDerived" class.

Even though this thread is old I'm positing my solution, in case it helps someone. It is not my own but is based off answers in other SO topics.
public abstract BaseClass
{
public double MyPoP { get { return GetMyPoP; } }
protected abstract double GetMyPoP { get; }
}
public class DClass: BaseClass
{
public new double MyPoP { get; set; }
protected override double GetMyPop { get { return MyPoP; } }
}
This solution adds an extra line of code for each such property that needs accessor modified. However, there is no change to external visibility and provides needed functionality.

public abstract class BaseClass
{
public abstract double MyPop { get; }
}
public class DClass: BaseClass
{
private double _myPop = 0;
public override double MyPop
{
get { return _myPop; }
}
// some other methods here that use the _myPop field
}
If you need to set the property from outside DClass then maybe it would be better to put the setter into the base class.

EDIT:
OK I may have been hasty with this response, but I've given it some more thought now.
Do you have to use an abstract base class? If it's not required, try this:
public interface ISomeRelevantName
{
double MyPop { get; }
}
public class DClass : ISomeRelevantName
{
public double MyPop { get; set; }
}

Why not just have a property in the base class that has a private setter, then in your subclass that needs the setter, override it and make it public.

You cannot override the set accessor since the base class has no set accessor defined.
What you can do is use the new keyword to hide the base classes implementation, but that may not be what you want.