hooks in function argument to accommodate future data?

I have to validate data with some stuff which I don't know yet. I want to provide some placeholders in the function arguments in order to support those objects.

Current

Execute(start_time, end_time, DataSet, some_other_data_hook)

At present, I have implemented this hook as a dictionary so that people can put name of the data and then values in the list

Dictionary<name_of_the_data,List<value>> so开发者_运维知识库me_other_data_hook;

This sure looks ugly, and I can't think of any better way to solve this problem.

I think the better approach would be to only engineer what you need right now. Even if you "know" and are promised by domain experts and business owners that more rules will be coming, if they're not here now, don't try to set placeholders.

Part of this is for a maintenance aspect, you shouldn't have any unreferenced/unused code in your assembly. It causes problems with maintainability because you're not sure if someone might be using it.

Another aspect is the amount of energy you're going to consume now to define something undefined. Perhaps one future hook is Duration, so you plan for it, only for product owners to decide duration isn't a good idea. In the end, you'll architect something you might not need.

Make sure you methods are easily modified, that they won't cause breaking changes, and then only set up hooks for what needs to be done today.

Think of it as someone building a computer, you wouldn't want them to throw down a whole bunch of extra solder on the motherboard because there might be a time in the future where new devices would be needed. Same thing with code, if you don't have a defined need, right now, don't code it.

"some stuff" is pretty vague. Is it something that would lend itself to passing in an interface? Something like: Execute(start_time, end_time, DataSet, IValidationRule) where IValidationRule is:

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

This would provide you with maximum flexibility to plug in different "validation hooks" of wildly varying structure as requirements change. I would probably create my own return value type, like ValidationResult or something along those lines as well. You can code around structure ambiguity if you can enforce a contract on the required behavior.

If you don't have the slightest clue what the structure OR behavior of the "hooks" are going to look like then I'd agree with taylonr. You can't model something that far out in left field.