Конструктор C #, использующий динамический интерфейс против интерфейса в качестве параметра - PullRequest
Новая
       51

Конструктор C #, использующий динамический интерфейс против интерфейса в качестве параметра

5 голосов
/ 25 мая 2011

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

Итак, мой вопрос: каковы плюсы и минусы в том, чтобы делать что-то вроде этого: 

class Class1
{
    public string Description { get; set; }
    public string Name { get; set; }

    public Class1(dynamic obj)
    {
        Name = obj.Name;
        Description = obj.Description;
    }
}

против 

class Class1
{
    public string Description { get; set; }
    public string Name { get; set; }

    public Class1(IClass1 obj)
    {
        Name = obj.Name;
        Description = obj.Description;
    }
}

Ответы [ 2 ]

7 голосов
/ 25 мая 2011

Плюсы интерфейса:

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

Плюсы dynamic:

  • Вам не нужно объявлять интерфейс или реализовывать его
  • Существующие классы со свойствами Name и Description могутиспользоваться без изменений
  • Анонимные типы могут использоваться в одной сборке , если они имеют свойства Name и Description

Лично я обычно использую C # как статическитипизированный язык, если только я не взаимодействую с чем-то естественным образом динамическим (например, где бы я иначе использовал отражение, или вызывал в COM или DLR) ... но я вижу, что в некоторых случаях это может быть полезно.Только не переусердствуйте :)

1 голос
/ 25 мая 2011

В обоих сценариях, чтобы метод функционировал должным образом, как ожидается, объекты, передаваемые в метод, должны иметь ваши свойства Name и Description.

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

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

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

...