Лучшая практика для передачи многих аргументов в метод? - PullRequest
78 голосов
/ 12 марта 2010

Иногда нам приходится писать методы, которые получают много аргументов, например:

public void doSomething(Object objA , Object objectB ,Date date1 ,Date date2 ,String str1 ,String str2 )
{
}

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

Map<Object,Object> params = new HashMap<Object,Object>();
params.put("objA",ObjA) ;

......

public void doSomething(Map<Object,Object> params)
{
 // extracting params 
 Object objA = (Object)params.get("objA");
 ......
 }

Это не очень хорошая практика, инкапсуляция параметров в карту - это пустая трата эффективности. Хорошая вещь, чистая подпись, легко добавлять другие параметры с наименьшими изменениями. Какова наилучшая практика для такого рода проблем?

Ответы [ 15 ]

2 голосов
/ 12 марта 2010

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

1 голос
/ 12 марта 2010

Создайте класс компонента, установите все параметры (метод установки) и передайте этот объект компонента в метод.

0 голосов
/ 15 марта 2010
  • Посмотрите на свой код и выясните, почему все эти параметры передаются. Иногда возможно реорганизовать сам метод.

  • Использование карты делает ваш метод уязвимым. Что если кто-то, использующий ваш метод, неправильно введет имя параметра или отправит строку, в которой ваш метод ожидает UDT?

  • Определить Перенос объекта . Это обеспечит вам проверку типов как минимум; может даже оказаться возможным выполнить некоторую проверку в месте использования, а не в рамках вашего метода.

0 голосов
/ 12 марта 2010

Если вы передаете слишком много параметров, попробуйте изменить метод.Может быть, он делает много вещей, которые он не должен делать.Если это не так, попробуйте заменить параметры одним классом.Таким образом, вы можете инкапсулировать все в один экземпляр класса и передавать его, а не параметры

0 голосов
/ 12 марта 2010

Это часто указывает на то, что ваш класс несет более одной ответственности (т. Е. Ваш класс делает СЛИШКОМ много).

См. Принцип единой ответственности

для получения более подробной информации.

...