#c# #.net #oop #frameworks
#c# #.net #ооп #фреймворки
Вопрос:
Мне нужно проверить данные с помощью некоторых вещей, которые я еще не знаю. Я хочу предоставить некоторые заполнители в аргументах функции, чтобы поддерживать эти объекты.
Текущий
Execute(start_time, end_time, DataSet, some_other_data_hook)
В настоящее время я реализовал этот перехват в виде словаря, чтобы люди могли помещать имя данных, а затем значения в список
Dictionary<name_of_the_data,List<value>> some_other_data_hook;
Это, конечно, выглядит некрасиво, и я не могу придумать лучшего способа решить эту проблему.
Комментарии:
1. Будут ли все объекты-заменители одного и того же типа?
2. нет, может быть что угодно, но, как @taylonr, упомянутый в ответе ниже, я, вероятно, беспокоюсь о чем-то, что никто никогда не будет использовать. (особенно, если он еще не определен)
Ответ №1:
Я думаю, лучшим подходом было бы спроектировать только то, что вам нужно прямо сейчас. Даже если вы «знаете» и вам обещают эксперты в предметной области и владельцы бизнеса, что появятся новые правила, если их сейчас здесь нет, не пытайтесь устанавливать заполнители.
Частично это связано с аспектом обслуживания, у вас не должно быть никакого кода без ссылок / неиспользуемого кода в вашей сборке. Это вызывает проблемы с ремонтопригодностью, потому что вы не уверены, может ли кто-то его использовать.
Другой аспект — это количество энергии, которое вы собираетесь потратить сейчас, чтобы определить что-то неопределенное. Возможно, одним из будущих перехватов является Duration , поэтому вы планируете это, только для владельцев продукта, чтобы решить, что duration не является хорошей идеей. В конце концов, вы создадите то, что вам может не понадобиться.
Убедитесь, что ваши методы легко модифицируются, что они не приведут к критическим изменениям, а затем настраивайте перехваты только для того, что необходимо сделать сегодня.
Представьте себе, что кто-то собирает компьютер, и вы бы не хотели, чтобы он выбрасывал целую кучу дополнительного припоя на материнскую плату, потому что в будущем может наступить время, когда понадобятся новые устройства. То же самое с кодом, если у вас нет определенной потребности прямо сейчас, не кодируйте это.
Комментарии:
1. согласен — код необходимо изменить, как только эти аргументы станут определенными, и верный способ гарантировать, что эти изменения будут внесены, — не предоставлять средств их передачи 🙂
Ответ №2:
«кое-что» довольно расплывчато. Это что-то, что могло бы использоваться для передачи в интерфейсе? Что-то вроде: Execute(start_time, end_time, DataSet, IValidationRule) где IValidationRule находится:
public interface IValidationRule
{
bool IsValid(DataSet data);
}
Это обеспечило бы вам максимальную гибкость при подключении различных «перехватов проверки» с сильно изменяющейся структурой по мере изменения требований. Я бы, вероятно, создал свой собственный тип возвращаемого значения, например ValidationResult или что-то в этом роде. Вы можете закодировать неоднозначность структуры, если сможете принудительно применить контракт к требуемому поведению.
Если у вас нет ни малейшего представления о том, как будет выглядеть структура ИЛИ поведение «зацепок», я бы согласился с taylonr. Вы не можете смоделировать что-то настолько далеко в левом поле.