Действительно ли желательно иметь интерфейс как тип возврата?
У меня есть ряд классов с теми же функциями, но с другой логикой. Однако каждая функция класса может возвратить много объектов. Безопасно установить тип возврата как интерфейс?
Каждый класс (все использование того же интерфейса) делает это с различной бизнес-логикой.
protected IMessage validateReturnType; <-- This is in an abstract class
public bool IsValid() <-- This is in an abstract class
{
return (validateReturnType.GetType() == typeof(Success));
}
public IMessage Validate()
{
if (name.Length < 5)
{
validateReturnType = new Error("Name must be 5 characters or greater.");
}
else
{
validateReturnType = new Success("Name is valid.");
}
return validateReturnType;
}
Есть ли какие-либо ловушки с поблочным тестированием тип возврата функции? Кроме того, это считают плохим дизайном, чтобы иметь функции, бывшие должные быть выполненными для них для следования? В этом примере Проверьте (), должен был бы быть выполнен, прежде чем IsValid () или иначе IsValid () будут всегда возвращать false.
Спасибо.
3 ответа
Однако каждая функция класса может вернуть количество объектов. Это безопасно чтобы установить возвращаемый тип как interface?
Это обычная и хорошая практика. Например, посмотрите, как был построен COM, он в значительной степени полагается на эту методологию.
Есть ли подводные камни при модульном тестировании типа возвращаемого значения функции
Нет.
Кроме того, считается ли плохой дизайн наличие функций, которые необходимо запускать для их успешного выполнения? В этом примере Validate () должен быть запущен до IsValid (), иначе IsValid () всегда будет возвращать false.
Это нормально для работы с парадигмой объектно-ориентированного программирования, например, для работы с сокетами. Обычно перед отправкой и получением данных используется метод подключения.
При этом, как правило, лучше сохранять меньше состояний, чем больше состояний, потому что таким образом легче доказать правильность вашей программы. Например, вам нужно протестировать каждую функцию, которая полагается на эту функцию не одним способом, а двумя способами. Возможные состояния программы растут экспоненциально, если у вас много состояний. Взгляните на функциональное программирование , если вас интересует, почему состояние - это плохо.
Наличие интерфейса в качестве возвращаемого типа - это хорошо, потому что ваш метод будет совместим с большим количеством типов сообщений.
Также считается ли плохой дизайн наличие функций, которые необходимо запускать для их успешного выполнения? В этом примере Validate () должен быть запущен до IsValid (), иначе IsValid () всегда будет возвращать false.
Есть исключения, но в целом вам следует избегать создания такого рода API. Это называется «временной зависимостью», что является просто причудливым термином, означающим «одно должно произойти раньше другого». Проблема с временными зависимостями в том, что они редко описываются сами по себе. Другими словами, API сам по себе не сообщает, как он предназначен для использования. API, которые полагаются на временные зависимости, часто труднее интуитивно понять и использовать, чем аналогичный код.
В вашем примере я бы рассмотрел возможность рефакторинга API для достижения следующих целей разработки:
- Избавьтесь от IsValid altogther.
- Validate возвращает список ошибок проверки.
- Переопределите «успех», как если бы функция Validate () возвращала пустой список без ошибок.
Если вам просто необходим IsValid, переопределите его, чтобы проверить №3. Если вы хотите кэшировать результаты, чтобы вам не приходилось постоянно пересчитывать IsValid, рассмотрите возможность реализации INotifyPropertyChanged и аннулирования кешированного результата в PropertyChanged.