Является ли хорошей практикой инкапсулировать много одинаковых параметров в структуру

Question

В принципе, у меня есть что-то вроде следующего:

public string SomeDBMethod(string server, string dbName, string userName, string password,...)

Это хорошая практика для рефакторинга следующего:

public string SomeDbMethod(DBParams parameters, ...)

Где DBParams определяется следующим образом:

public struct DBParams
{
  string Server {get;set;}
  string DbName {get;set;}
  string UserName {get;set;}
  string Password {get;set;}
}

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

Я также обнаружил, что у этого подхода есть некоторые ограничения: если SomeDbMethod должен быть представлен как метод веб-службы, я не могу использовать структуру DBParams в качестве параметра (насколько я понимаю предмет веб-служб ... что не очень далеко).

Итак, это слишком много проблем для небольшой выгоды, или я что-то здесь делаю?

Answer 1

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

Метод использования структуры не накладывает никаких ограничений в отношении веб-сервисов. Вам просто нужно сделать тип сериализуемым (DataContract в WPF, я считаю), и не должно быть никаких проблем.

Answer 2

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

Однако в большинстве случаев я использую класс, а не структуру. Преимущества структур никогда не были мне ясны, и во многих ситуациях они вызывают боль в спине (я полагаю, сценарий веб-сервисов - только один пример).

Вы можете сделать класс неизменным, если не хотите, чтобы люди его изменили (если это было причиной использования struct)

Answer 3

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

Answer 4

Я бы предложил прочитать этот вопрос о структурах стихах значениях объектов

В этом случае почти наверняка сделать структуру изменяемой - действительно плохая идея.

Учитывая, что именованные параметры появятся в c # 4.0, я хотел бы предположить, что что-то вроде этого просто будет раздражать позже, и его следует избегать, если нет серьезной необходимости передавать этот «пакет» информации во многих различных тем а также операции, которые имеют для них значение.

Если честно, если класс / структура не поддерживает / не применяет некоторый инвариант, тогда нет особого смысла.

Answer 5

Вы можете использовать Struct, если хотите инкапсулировать связанные переменные. Это не обязательно должен быть объект. Поскольку структуры являются типами значений, в отличие от классов, они не требуют кучи распределение, также они передаются по значению, а не по ссылке, как объекты.

ИМХО в этом случае создание класса для хранения этой информации не добавляет ценности, но если вы планируете что-то более сложное с информацией DBParams (выставляя ее в качестве параметра для веб-службы), то подумайте об использовании объекта. Если вы хотите просто передать эти параметры в сжатой форме, структура в порядке.

Вы можете получить больше информации здесь:

http://discuss.joelonsoftware.com/default.asp?dotnet.12.489354.15