Создание метода, который имеет много параметров, является главным грехом. Всякий раз, когда возникает необходимость создать такой метод, вдыхайте воздух: это кодовый запах. Укрепите свои юнит-тесты, а затем рефакторинг. Нет оправданий, но нет. Refactor! Используйте шаблон компоновщика или еще лучше используйте Fluent API. Для последнего может помочь аннотированный процессор fluflu .
С учетом всего сказанного мы можем прийти к моменту в нашей жизни, когда столкнемся с реальной жизнью, а не с идеалистической моделью, которой мы можем следовать в наших хобби-проектах. Приходит унаследованный монстр корпоративной библиотеки, у которого есть метод тысяч параметров, и у вас нет полномочий, времени, смелости или интереса (что плохо для вас) изменить… опс… реорганизовать его. Вы могли бы создать конструктор как фасад, который бы скрывал за ним уродливый API, если бы у вас было время. Создание компоновщика — это все еще код, который вы должны тестировать модулем еще до того, как напишите (вы знаете, TDD), и у вас просто может не хватить времени. Код, который вызывает чудовищный метод, также уже есть, вы просто поддерживаете его.
Вы все еще можете сделать небольшой трюк. Это может быть не идеально, но все же что-то.
Предположим, что есть метод:
|
1
2
3
4
5
|
public void monster(String contactName, String contactId, String street, String district, ... Long pT){...} |
Первое, что нужно, — это выбрать локальные переменные в месте расположения вызывающего абонента. Жаль, что имена уже выбраны, и вы не можете изменить его. Для этого может быть какая-то причина, например, соблюдается соглашение об именовании, которое может иметь смысл, даже если не ваш стиль. Итак, звонок:
|
1
|
monster(nm, "05300" + dI, getStrt(), d, ... , z+g % 3L ); |
это не совсем то, о чем я говорил. Это то, что у вас есть, и вы можете жить с этим или просто вставить новые переменные в код:
|
1
2
3
4
5
6
7
|
String contactName = nm;String contactId = "05300" + dI;String street = getStrt();Street district = d;...Long pT = z+g % 3L;monster(contactName, contactId, street, district, ... ,pT ); |
или вы можете даже написать это не так, как это принято в Java, хотя и совершенно законно:
|
1
2
3
4
|
String contactName, contactId, street, district;...Long pT;monster(contactName = nm, contactId = "05300" + dI, street = getStrt(), district = d, ... ,pT = z+g % 3L ); |
Вкусно это? Смотря как. Я бы не стал спорить о вкусе. Если вам это не нравится, есть альтернативный способ. Вы можете определить вспомогательные и очень простые статические методы:
|
1
2
3
4
5
6
7
8
|
static <T> T contactName(T t){ return T;}static <T> T contactId(T t){ return T;}static <T> T street(T t){ return T;}static <T> T district(T t){ return T;}...static <T> T pT(T t){ return T;}monster(contactName(nm), contactId("05300" + dI), street(getStrt()(, district(d), ... ,pT(z+g % 3L) ); |
Код все еще уродлив, но немного более читабелен в месте вызова. Вы даже можете собирать статические методы в служебный класс или интерфейс в случае Java 8, названного как with , using , to и так далее. Вы можете статически импортировать их в свой код и вызывать некоторые вызовы методов:
|
1
|
doSomething(using(someParameter), with(someOtherParameter), to(resultStore)); |
Когда все это есть, вы можете чувствовать себя честно, если ответите на последний вопрос: что за блаженство * является параметром pT .
( * «Все», что вы можете заменить другими словами, как хотите)
| Ссылка: | Именованные параметры в Java от нашего партнера JCG Питера Верхаса из блога Java Deep . |