C # требуется интерфейс для поля

Question

Я разработчик объективного C / swift и перехожу на C # для проекта. Я ищу что-то похожее на протоколы. Мое исследование показало, что я использую интерфейс или абстрактный класс, который вполне подойдет для моих целей. Я пытаюсь планировать будущих разработчиков в других местах.

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

Есть ли эквивалент C #? Есть ли способ заставить (или хотя бы настоятельно рекомендовать) поле класса в контроллере всегда реализовывать интерфейс или наследовать от абстрактного класса?

Answer 1

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

interface IDatasourceProvider
{
    void Save();
}


class FilesystemDatasource : IDatasourceProvider
{
   void Save()
   {
      // save to disk
   }
}


class SqlServerDatasource : IDatasourceProvider
{
   void Save()
   {
      // save to sql server
   }
}

Затем вы можете использовать DI, чтобы вводить поставщиков в конструктор, и использовать его для вызова * 1004.*, не заботясь о фактической реализации.У вас может быть служба с методами, которые принимают IDatasourceProvider, где вы можете вызвать Save.Это заставит вызывать передать реализацию интерфейса, если они хотят использовать метод.

void SaveToDatasource(IDatasourceProvider provider)
{
    provider.Save();
}

Answer 2

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

Этот параметр может помочь предотвратить дублирование кода и в таких общих вещах, как работа со списком (ofThings). Вы можете создать виртуальный метод «GetThings ()», и ваш основной базовый класс все еще может переключаться между ними и работать с ними.

Так что есть много путей, по которым вы можете пойти.

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

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

Абстрактный класс - это скорее объявление класса того, что должно быть найдено в классе.

Однако, определяя код класса WITH, который работает с (чем угодно), вы можете получить его, не повторяя код повсюду.

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