Добрый день!
Возникла следующая задача:
Есть абстрактный класс:

class abstract TDataObject
    {
    //строка в DataTable
    public DataRow Row;
    //состояние строки
    public DataRowState State {get {return Row.RowState;}}
    }

И есть наследующие абстрактный класс

class TConcreteDataObject : TDataObject
    {
      //типизированная строка, наследуюая DataRow должна заместить DataRow   
        //в абстрактном классе
        override TypedDataRow Row;
        
        Some methods .....
    }

На данную реализацию компилятор ругается!
Возможно ли заменять члены абстрактного класса в наследниках членами,унаследованными от членов абстрактного класса? если да то как ?

Если нет то возможен ли ещё вариант чтобы для типизированных строк определить общую логику поведения на уровне DataRow, а конкретную реализацию в каждом конкретном классе?

Здравствуйте, Andrew Merkulov, Вы писали:

AM>Добрый день!
AM>Возникла следующая задача:
AM>На данную реализацию компилятор ругается!
AM>Возможно ли заменять члены абстрактного класса в наследниках членами,унаследованными от членов абстрактного класса? если да то как ?

AM>Если нет то возможен ли ещё вариант чтобы для типизированных строк определить общую логику поведения на уровне DataRow, а конкретную реализацию в каждом конкретном классе?
Использовать вместо поля виртуальное свойство.

Здравствуйте, Andrew Merkulov, Вы писали:


AM>На данную реализацию компилятор ругается!
AM>Возможно ли заменять члены абстрактного класса в наследниках членами,унаследованными от членов абстрактного класса? если да то как ?

Use the override modifier to modify a method, a property, an indexer, or an event.

AM>Если нет то возможен ли ещё вариант чтобы для типизированных строк определить общую логику поведения на уровне DataRow, а конкретную реализацию в каждом конкретном классе?

Использовать открытые переменные в таком случае нельзя. Нужно объявлять свойства вместо переменных, а в классе наследнике новое свойство помечать new. В данном случае объявлять переменную в абстрактном классе вобще не нужно.

Здравствуйте, Apollo13, Вы писали:

A>Здравствуйте, Andrew Merkulov, Вы писали:


AM>>На данную реализацию компилятор ругается!
AM>>Возможно ли заменять члены абстрактного класса в наследниках членами,унаследованными от членов абстрактного класса? если да то как ?

A>

A>Use the override modifier to modify a method, a property, an indexer, or an event.

Прошу прощения, там были определены свойства, а не переменные...

class abstract TDataObject
    {
    //строка в DataTable 
    public abstract DataRow Row {get{}set{}};
    //состояние строки
    public DataRowState State {get {return Row.RowState;}}
    }

И в наследнике соотвественно в общем виде вот так:

class TConcreteDataObject : TDataObject
    {
            private TypedDataRow row;
            
      //типизированная строка, наследуюая DataRow должна заместить DataRow   
      //в абстрактном классе
        public TypedDataRow Row {get{return row;};set{}};
        
        Some methods .....
    }

И при получении ((TDataObject)Instance).State вернуло бы состояние TConcreteDataObject.Row.State

Это нормально реализуется с абстрактыми членами в случае если их тип совпадает с типом в наследниках, а в данном случае хотелось бы подменить базовый тип унаследованными от базового

Здравствуйте, Andrew Merkulov, Вы писали:

AM>Это нормально реализуется с абстрактыми членами в случае если их тип совпадает с типом в наследниках, а в данном случае хотелось бы подменить базовый тип унаследованными от базового

Этот фокус обычно делается при помощи интерфейсов:

public interface IDataObject
{
    DataRow Row {get; set;}
    DataRowState State {get;}
}

public class DataObjectBase : IDataObject
{
    DataRow IDataObject.Row
    {
        get { return InternalRow; }
    }
    
    protected abstract DataRow InternalRow { get; }
    
    public DataRowState State
    {
        get { return Row.RowState; }
    }
}

public class SomeDataObject : DataObjectBase
{
    private TypedDataRow _row;
    
    public TypedDataRow Row
    {
        get { return _row; }
    }

    protected override DataRow InternalRow
    {
        get { return Row; }
    }
}

Здравствуйте, AndrewVK, Вы писали:

AVK>Этот фокус обычно делается при помощи интерфейсов:

Откровенно говоря интерфейсы тут необязательны. Наоборот абстрактыне методы хороший путь реализовать большую часть интерфейса в базовом классе и позволить переопределять его отдельные методы в наследниках.

Здравствуйте, VladD2, Вы писали:

AVK>>Этот фокус обычно делается при помощи интерфейсов:

VD>Откровенно говоря интерфейсы тут необязательны. Наоборот абстрактыне методы хороший путь реализовать большую часть интерфейса в базовом классе и позволить переопределять его отдельные методы в наследниках.

Ты исходный вопрос прочел? Можешь предложить решение задачи без интерфейсов?

Здравствуйте, AndrewVK, Вы писали:

AVK>Ты исходный вопрос прочел? Можешь предложить решение задачи без интерфейсов?

Прочел. Там без интерфейса обойтись легко.

class abstract TDataObject
{
    //строка в DataTable
    public abstract DataRow Row { get; }
    //состояние строки
    public DataRowState State { get { return Row.RowState; } }
}

...

class TConcreteDataObject : TDataObject
{
    //типизированная строка, наследуюая DataRow должна заместить DataRow   
    //в абстрактном классе
    public override DataRow Row
    {
        get
        {
            ...
            return ...
        }
    }[/b]
    
}

Здравствуйте, VladD2, Вы писали:

VD>Прочел. Там без интерфейса обойтись легко.

Твое решение хуже, поскольку при необходимости вызова методов специализированного типа тебе придется делать приведение, а компилятор не проверит правильность используемого типа. Для внутреннего пользования такой вариант прокатит, а вот во вне такой интерфейс совать не стоит.

Здравствуйте, AndrewVK, Вы писали:

AVK>Твое решение хуже, поскольку при необходимости вызова методов специализированного типа тебе придется делать приведение, а компилятор не проверит правильность используемого типа. Для внутреннего пользования такой вариант прокатит, а вот во вне такой интерфейс совать не стоит.

Читал... долго думал... о чем это ты?