Абстрактный базовый класс, реализующий методы интерфейса производного класса

Question

У меня есть следующие классы и интерфейсы. Я хочу существенно заморозить интерфейс IOld (который будет устаревать) и заставить пользователей использовать интерфейс INew, который будет содержать те же методы, что и IOld. Однако метод INew Meth3 представляет ту же функциональность, что и IOld Meth2, но с другим типом возврата, и чтобы отличить их лучше, я думал, что этот дизайн будет подходящим. Мой вопрос в том, считается ли это хорошей практикой кодирования?

ПРИМЕЧАНИЕ: IOld и INew живут в отдельных агрегатах. NewClass не может ссылаться на IOld каким-либо образом, поскольку он будет отображаться как удаленный объект (MarshalByRef), с которым клиенты будут подключаться через интерфейс INew. Я не хочу, чтобы новые клиенты ссылались на сборку IOld.

public interface IOld 
{ 
    void Meth1(); 
    double Meth2(int input); 
} 

public interface INew 
{ 
    void Meth1(); 
    float Meth3(int input); 
} 

public abstract class BaseClass 
{ 
    public virtual void Meth1() 
    { 
    } 

    public virtual double Meth2(int input) 
    { 
     throw new NotImplementedException(); 
    } 
} 

public class OldClass 
: 
    BaseClass, 
    IOld 
{ 
    public override double Meth2(int input) 
    { 
     return 0; 
    } 
} 

public class NewClass 
: 
    BaseClass, 
    INew 
{ 
    public float Meth3(int input) 
    { 
     return 0; 
    } 
} 

Answer 1

Я хотел бы попробовать что-то вроде этого:

public class OldClass : BaseClass, IOld 
{ 
    public override double Meth2(int input) 
    { 
     return 0.0; 
    } 
} 

public class NewClass : OldClass, INew // now implements IOld and INew using the Method2() from OldClass 
{ 
    [Obsolete("This method is deprecated . Use Method3() instead.")] 
    public override double Meth2(int input) 
    { 
     return base.Meth2(input); 
    } 
    public float Meth3(int input) 
    { 
     return return 0.0f; 
    } 
} 

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

Answer 2

Сядьте вниз и постройте свою пирамиду с прочной основой. То, как вы это задали, абстрактный базовый класс и интерфейс - это конкурирующие методы выполнения одной и той же концепции. Вы делаете это прежде всего для того, чтобы облегчить «Старый» или «Новый», но при этом вы получите довольно забавный график зависимостей.

С тем, что вы написали, ваш единственный способ - это методы с той же подписью. Если бы не эта проблема, вы могли бы легко расширить старый интерфейс и не столкнуться с проблемами. Если этот метод изменяется в новом, это рефакторинг (приемлемый) или совершенно другой результат? Другими словами, может ли старый клиент вызвать новое? Если это так, нет необходимости использовать этот метод и в другом интерфейсе.

Удостоверьтесь, что вы осуждаете методы, поэтому пользователи знают, что они потеряют старые методы. Также убедитесь, что он задокументирован.

Answer 3

Я бы предпочел добавить новый метод с немного другим именем вместо создания нового интерфейса.

Так старый интерфейс будет, например:

public interface IOld 
{ 
    void Meth1(); 
    [Obsolete("Use Meth22 instead.")] 
    double Meth2(int input); 
    float Meth22(int input); 
}