зацепляет аргумент функции для размещения будущих данных?

Question

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

Текущий

Execute(start_time, end_time, DataSet, some_other_data_hook)

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

Dictionary<name_of_the_data,List<value>> some_other_data_hook;

Это выглядит ужасно, и я не могу придумать лучшего способа решить эту проблему.

Answer 1

Я думаю, что лучший подход - это создать только то, что вам нужно прямо сейчас. Даже если вы «знаете» и эксперты по доменам и владельцы бизнеса обещают, что появятся новые правила, если их здесь нет, не пытайтесь устанавливать заполнители.

Часть этого относится к аспекту обслуживания, в вашей сборке не должно быть никакого кода, на который нет ссылок / не использованного. Это вызывает проблемы с ремонтопригодностью, потому что вы не уверены, что кто-то может его использовать.

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

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

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

Answer 2

"некоторые вещи" довольно расплывчаты.Это что-то, что поддается передаче в интерфейсе?Что-то вроде: Execute(start_time, end_time, DataSet, IValidationRule), где IValidationRule - это:

public interface IValidationRule
{
    bool IsValid(DataSet data);
}

. Это обеспечит вам максимальную гибкость при подключении различных «проверочных хуков» сильно изменяющейся структуры при изменении требований.Я бы, вероятно, создал свой собственный тип возвращаемого значения, например ValidationResult или что-то в этом роде.Вы можете закодировать неоднозначность структуры, если сможете принудительно заключить контракт на требуемое поведение.

Если у вас нет ни малейшего понятия, как будет выглядеть структура ИЛИ поведение "крючков", тогда я 'буду согласен с тайлонром.Вы не можете смоделировать что-то так далеко в левом поле.