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

Question

Существует проблема дизайна, подобная этой.

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

Пример: ClassA имеет такие методы.

void Add(string str);
void Delete(string str);
List<string> GetInfo(string name);

Другой класс, ClassBимеет следующие методы.

void Add(Dictionary Info);
void Delete(string str);
Dictionary GetInfo(string name);

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

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

Answer 1

Вы можете использовать общий интерфейс здесь. Пример:

interface IModifiable<T>
{
  void Add(T Info);
  void Delete(T item);
  T GetInfo(string name);
}
public class MyClass : IModifiable<List<string>>
{
   public void Add(List<string> list)
   { 
      //do something
   }

   public void Delete(List<string> item)   {  }
   public List<string> GetInfo(string name)  {  }
}

Answer 2

Обобщения помогут вам, если вы сможете немного изменить свой дизайн:

interface IFoo<TKey, TValue>
{
    void Add(TKey name, TValue value);
    void Delete(TKey name);
    IEnumerable<TValue> GetInfo(TKey name);
}

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

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

Answer 3

public interface IInt<T> {
    void Add(T val);
    void Delete(string str);
    T GetInfo(string name);
}

Answer 4

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

public void Detele<T>(T toDelete); //optional : where T 

и определите его в общем интерфейсе (или абстрактном классе, если это ваш случай)

В противном случае очень старая, но все еще надежная техника - перегрузка метода. Вы можете определить несколько методов с одним и тем же именем, но с разными аргументами. .Net активно использует этот шаблон в таких классах, как StreamReader, ToString и т. Д.

Из предоставленных вами подписей похоже, что вы можете найти для этого применение.

Третий вариант (хотя и более сложный для кодирования) - использование лямбда-выражений.

Add<T,P>(Action<T,P> addingAction, T source, P param) ( addingAction(source,param); );
//this is naive p.Add(q) it can be arbitralily more complicated
aObject.Add( (p,q) => p.Add(q), myObj, myParam);

Таким образом Вы определяете общее действие по добавлению, которое затем может быть инкапсулировано в Ваши объекты. Подпись, которую я предоставил, может быть легко изменена. Также Вы можете не захотеть выполнить действие сразу, а запланировать его для отложенного выполнения или выполнить асинхронно. Возможности с лямбда-выражениями бесконечны.

Также я предоставил реализацию, которая использует делегат Action. Вы можете легко преобразовать этот код в класс Expression, с помощью которого вы можете создавать свои собственные делегаты во время выполнения кода (и кэшировать их после инициализации, поскольку это довольно медленный процесс, т. Е. Отражение и прочее). Я настоятельно рекомендую злоупотреблять делегатами и выражениями. когда это возможно.

Береги себя Лукаш

Answer 5

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

Подробнее здесь: http://www.objectmentor.com/resources/articles/srp.pdf

Вы также можете прочитать эту превосходную книгу о некоторых принципах дизайна: http://cdn.cloudfiles.mosso.com/c82752/pablos_solid_ebook.pdf