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

Question

У меня есть этот интерфейс ...

public interface ICheckThatDocumentExistsCommand
{
   bool Execute( string userId, string docId );
}

В реализации я хочу проверить только два идентификатора и, если они действительны, вернуть результат другого интерфейса ...

public interface ICheckThatDocumentExistsCommand
{
   bool Execute( UserId userId, DocumentId docId );
}

Я хочу определить интерфейсы в одной и той же сборке бизнес-домена, но мне трудно решить, как различать два (или более) уровня.Логично, что я чувствую, что они похожи, если не идентичны по названию, поэтому я не могу поместить их в одно и то же пространство имен.Я разделяю через пространство имен?Пространство имен «Проверка» и пространство имен «Что-то еще»?Или я могу расширить и без того многословное имя до чего-то немного смешного, например ...

public interface IValidateIdsAndThenCheckThatDocumentExistsCommand

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

Answer 1

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

public interface ICheckThatDocumentExistsCommand
{
  bool Execute<t1,t2>(t1 userID, t2 docId);
}

Answer 2

Мне нравится ответ Тимса, потому что он умный, и мне нравится ответ Томаса, потому что он, очевидно, знает территорию.

Если бы это был я, я бы, скорее всего, использовал разные пространства имен.

Answer 3

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

Я вижу головные боли для двух интерфейсов с одинаковыми именами:

1. Любой класс, которыйссылки на обе сборки должны будут использовать полностью определенное имя класса.
2. Проблемы с контролем исходного кода, связанные с хранением файлов прямо в вашей голове (какую я сейчас объединяю?), при условии, что имена ваших файлов совпадают с именами классов.
3. Тип GoTo в Resharper всегда требует дополнительного шага.

Я согласен, что дополнительная работа, выполненная первым интерфейсом, должна быть отражена в имени.Ваше предложение будет работать, но вы можете сократить его до что-то вроде

IValidateIdsAndCheckForDocumentCommand

Это не слишком долго.:)