Должен ли я передать список этому методу или один за другим? - PullRequest
0 голосов
/ 03 июля 2011

В настоящее время я пробираюсь через небольшое приложение и наткнулся на то, что не знаю, как решить.Приложение позволяет людям выбирать водителей, которые, по их мнению, закончат на определенной позиции.Страница будет построена в ASP.NET.

Мой тест:

[Test]
public void SubmitPrediction()
{
    Prediction prediction = new Prediction();

    Dictionary<int, string> selectedDrivers = new Dictionary<int, string>()
    {
        {1, "Michael Schumacher"},
        {2, "Jensen Button"}
    };

    prediction.SubmitPrediction(selectedDrivers);
}

Сейчас я перехожу к SubmitPrediction() selectedDrivers, , но , я также могу передать позицию (целое число) и идентификатор драйвера (также int, вероятно, будет заменен объектом с именем Driver, который будет иметь все, что связано с драйвером):

prediction.SubmitPrediction(1, "Michael Schumacher");

Вероятно, будет:

prediction.SubmitPrediction(1, driver);

Меня интересует, какой подход лучше.Возможно, было бы даже лучше инкапсулировать водителя и должность в одном классе, но я не могу придумать приличное имя.Прогноз уже принят в том смысле, что у него есть куча выбранных водителей и их позиций.Тогда я мог бы сделать словарь списком.

prediction.SubmitPrediction(SomeEncapsulatedClassHere);

Ответы [ 2 ]

1 голос
/ 04 июля 2011

В соответствии с вопросом в заголовке, если вы уже обдумываете такой вопрос, то я бы предложил передать список. Список может содержать только один элемент, поэтому он будет хорошо работать вместо метода «один за другим», наоборот, потребуется изменить ваши интерфейсы (или подписи классов).

Я тоже на борту с инкапсулирующим драйвером и позицией в одном классе. Имя? Как насчет DriverPlacement?

PS: возьми все с крошкой соли, поскольку я не знаю твоего контекста

0 голосов
/ 03 июля 2011

Это зависит от ваших требований.Я думаю, что нет прямого ответа, который работает для всех, особенно для такой проблемы, как решение типа параметра.Вы должны понимать реальную проблему, которую вы пытаетесь решить, стоящую за проблемой кода.Не делайте красивый дизайн своей целью.Я сильный адепт эмерджентного дизайна.Форма следует за функцией.Реализация вашего сценария без ошибок - ваша цель.В хорошем дизайне будет меньше ошибок, но если вы чувствуете, что у вас недостаточно опыта, просто попробуйте что-нибудь, протестируйте различные решения.Иногда лучше написать код, который выполняет эту работу, и выполнить рефакторинг позже, как только вы четко заметите недостаток вашего текущего решения.В этом и заключается преимущество TDD, фактически база для TDD: красный, зеленый, рефакторинг.

Хотите минимизировать трафик данных между клиентом и сервером, чем использовать объект, который требует наименьшего количества памяти, идентификатор драйвера.Как вы назначаете эти идентификаторы?Если список обновляется, может ли новый идентификатор означать драйвер из старого списка?

...