Как создать интерфейс метода с переменными параметрами / различными сигнатурами метода?

Question

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

, например

public interface IViewModel
{
    //...
    void ResetReferences(); 
}

// and then, in my class implementations, something like this:
public class LocationViewModel : IViewModel
{
    public void ResetReferences(List<StateProvinces> stateProvinces) //...
}

public class ProductViewModel : IViewModel
{
    public void ResetReferences(List<Color> colors, List<Size> sizes) //...
}

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

// variable parameters
void ResetReferences(params object[] list); 

Но тогда как мне заставить меня выполнять проверку типов или вызывать фактическую сигнатуру метода, которую я хочу, и т. Д.?

Может быть, интерфейс не подходит для использования? Может быть, просто базовый класс и некоторые соглашения о кодировании?

Спасибо

Answer 1

Замените ваши списки аргументов объектами, которые реализуют связанный интерфейс:

public interface IViewModel
{
    //...
    void ResetReferences(IResetValues vals); 
}

Я должен добавить, что IMO, "ResetReferences ()" не должен принимать аргумент ... он должен сбрасываться до некоторого значения по умолчанию, которое будет специфичным для отдельных типов (типов), которые реализуют ваш интерфейс ... "Сброс «для меня это слово означает« восстановить в исходное состояние »... добавление аргументов подразумевает, что вы можете это контролировать.

Answer 2

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

Если я полностью не понимаю, что вы пытаетесь выполнить,вы на неправильной дороге.

Answer 3

Если параметры могут быть разными, то это не совсем обычный интерфейс. Скажем так: вызывающий абонент должен знать класс реализация ? Если это так, вы потеряли преимущества слабой связи интерфейсов.

Один из вариантов - это инкапсулировать параметры в другой тип и сделать класс универсальным для этого типа. Например:

public interface IViewModel<T>
{
    void ResetReferences(T data);
}

Тогда вы бы инкапсулировали List<Color> colors, List<Size> sizes в один тип и, возможно, поместили List<StateProvinces> stateProvinces в другой.

Хотя это немного неловко ...

Answer 4

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

Определением интерфейса является вся подпись.

Также может быть возможно передать объект в качестве параметра (возможно, полученного из базового класса ParameterProvider), так что объект инкапсулирует динамическую природу и все еще позволяет интерфейсу быть статичным. Но в этот момент вы в основном работаете с системой типов.

Answer 5

Вам нужно будет реализовать метод интерфейса, но вы все равно можете делать то, что хотите

public class LocationViewModel : IViewModel
{
    public void ResetReferences(List<StateProvinces> stateProvinces) // ...

    void IViewModel.ResetReferences() // ...
}