Запрос объекта, каковы плюсы и минусы? - PullRequest
7 голосов
/ 23 сентября 2011

Допустим, у меня есть следующий метод:

public Stream GetMusic(string songTitle, string albumName) { ... }

Мой коллега убежден, что это плохой метод подписи. Он хотел бы, чтобы я использовал объект Request, который преобразовал бы сигнатуру метода в это:

public Stream GetMusic(SongRequest request) { ... }

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

Лично я не думаю, что это хорошая идея. Использование параметров делает явным то, что требуется для запуска метода. Кроме того, это заставляет нас создавать еще один объект за небольшую сумму.

Каковы плюсы и минусы использования объектов Request? Используете ли вы его в своих проектах и ​​почему?

Ответы [ 2 ]

2 голосов
/ 23 сентября 2011

Вы получаете данные, используя метод GetMusic(...).Если это так, то, вероятно, было бы слишком много усилий для использования дополнительной сущности без особой необходимости.

Действительно, в ситуации, когда имеется только один входной параметр, вы можете использовать пользовательский класс.Но если этот класс является единственным местом для использования, поэтому, если SongSignature, как говорит название класса, необходимо использовать специально для этого класса, то это плохая практика использования "пакетов параметров", потому что это плохо читается.

Кроме того, если кто-то глупо говорит, что SongSignature должна быть структурой, и в этой структуре есть указатель на некоторые данные, которые должны быть изменены внутри метода, этот указатель никогда не изменится, потому что каждый раз GetMusicвызывается копия пакета свойств .

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

Давайте предположим следующую ситуацию:

Если в команде один программист заменяет параметры классом SongRequest, второй программист не обнаружил, что он используется в качестве параметра для функций (потому что он удаляет информацию в имени класса), иизменив его на структуру на следующей итерации, третий программист использовал этот метод таким образом, что он должен быть классом (например, использовать ссылку на класс)nces inside SongRequest) ... В результате никто действительно не знал, почему что-то не работает, потому что у каждого из них есть купол right вещь ... Нет оправдания использованию класса для локальногоиспользование вместо неявного объявления параметров.

Обычно у вас есть хорошие шансы получить такую ​​ситуацию в будущем, потому что:

  • вы не тот, кто меняет ваш код (то есть GetMusic)
  • кто-то может просмотреть код и найти класс 'SongReqest' полезным (так что ситуация идет еще хуже - от локального использования до глобального использования класса)
  • добавлениекласс SongReuest может добавить дополнительные зависимости для вашего метода (если кто-то изменит этот класс, скорее всего, ваш фундамент не скомпилирует)
  • с использованием SongRequest в качестве property bag блокирует его использование только в качествекласс, как упоминалось ранее.
  • используя этот класс, вы, вероятно, никогда не поделитесь своими параметрами с другими вызовами функций (по какой причине?)
  • наконец, используя SongRequest class оТолько для передачи параметров для конкретной функции дает дополнительную нагрузку на память, потому что, если этот метод вызывается часто, с одной стороны, это приведет к созданию большого количества ненужных объектов в памяти, которые необходимо будет собрать, с другой стороны, если такиеметод используется редко, будет просто не практично создавать класс для передачи нескольких переменных в один вызов

Существует только одна реальная причина использовать класс вместо двух строкАргументы: вы, программист, любите такие вызовы и хотите сделать весь код «красивее, чем раньше», более монадическим, несмотря на то, что это не очень практично и полезно.

Я бы никогда не советовал вам делать код таким, пока вы не захотите, чтобы он выглядел лучше.

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

2 голосов
/ 23 сентября 2011

У передачи объекта есть одно главное преимущество -

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

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

При этом каждая ситуация уникальна. Я не рекомендовал бы один подход по сравнению с другим для каждой ситуации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...