Реализация частного класса с двумя открытыми интерфейсами, а затем приведение к ним обоим? Плохая идея?

Question

Это считается хорошей идеей?Тип приведение одного и того же класса к двум различным интерфейсам, которые он реализует.Я думаю, что это хорошая идея ... но я не уверен.

public interface Abc
{
    int xyz { get; }
}

public interface Xyz
{
    int abc { get; }
}

internal class MyClass : Abc, Xyz
{

    public int xyz
    {
        get
        {
            return 0;
        }
    }

    public int abc
    {
        get
        {
            return 1;
        }
    }
}

        var myclass = new MyClass();

        var abc = myclass as Abc;
        var xyz = myclass as Xyz;

Answer 1

Если он реализует интерфейс, вам не нужно будет приводить его.

Использовать свойства интерфейса.

Answer 2

Я думаю, что это одна из причин, по которой появились интерфейсы. При использовании интерфейса, в конце концов, вас не волнует, какой конкретный класс его реализует, если он правильно реализует этот интерфейс.

Кроме того, вам не нужно кастовать. Назначение класса, реализующего интерфейс и переменную этого интерфейса, является неявным.

Answer 3

Да, это хорошая идея, особенно если ваши классы выполняют разные роли. Abc и Xyz могут быть не лучшими примерами, но что-то вроде ICanValidate, IHaveDefault, IHaveAnEngine и т. Д. Может быть лучше:)

Где такой дизайн сияет, когда определенные функции не являются обязательными. Возьмите пример ICanValidate: где-то в вашем постоянном конвейере вы safe приводите свою сущность к ICanValidate. Если он возвращает ноль, то вы игнорируете его; однако, если он возвращает интерфейс, вы можете позвонить entity.IsValid().

Просто записка о кастинге. В некоторых ответах говорится, что вам не нужно приводить при реализации интерфейса. Это верно для неявной реализации - для явной реализации вам понадобится приведение. Но я думаю, это было бы довольно очевидно:)

Answer 4

Прежде всего. Если вы хотите, чтобы другие использовали ваш код, вы должны действительно следовать Правилам разработки для разработки библиотек классов . Похоже, вы используете правила именования, используемые в Java.

Единственная причина сделать что-то внутреннее - это запретить другим создавать класс. Это все еще возможно, хотя с помощью отражения. Кроме этого, нет никаких причин. Если вы не хотите, чтобы другие продлевали ваш класс, просто сделайте его sealed. Но для этого тоже должна быть веская причина.

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

Answer 5

Нет никаких сомнений относительно хорошего или плохого типа, например.Список реализует IList и IEnumerable.когда итерация требуется для списка, используется IEnumerable, и когда необходимо выполнить операцию над списком (например, добавить элемент), необходимо использовать IList.

, поэтому это зависит от функциональности (от какого интерфейса).Также вам не нужно CASTING, когда интерфейс реализован классом.