Когда метод имеет слишком много параметров? [закрытый]

Когда нужно спросить, вероятно, будет слишком много.

Великий Будда !! Девяносто семь????

Хорошая практика обычно говорит о макс. от шести до восьми. Конечно, ymmv, и время от времени может быть веская причина для девятого. Но 97 ?? !!

Несколько мыслей ... это просто данные, или решения принимаются на основе их значений?

Если многие / большинство влияют на управление потоком, у вас есть почти недостижимый (даже понятный или проверяемый) «проект» (для небольших значений «design»).

Если это просто данные, могут ли они быть сгруппированы в структуры и указатели на переданные структуры?

Есть ли у вас проектная документация? Это могло бы объяснить, что происходит.

Да и «Опасно, Уилл Робинсон» - любой, кто открыто передает 97 параметров, может также передать любое число - не так очевидно - в качестве глобальных переменных.

Ps не знаю, как Eclipse работает на Java, но с C / C ++, если вы поместите параметры в отдельные строки

char DoEverything(
        int meaninglessParameterName1,
        char *meaninglessParameterName2,
        ....
        long double *meaninglessParameterName97)
        { return !NULL;}

Eclipse фактически идентифицирует строку с плохим параметром

Что ж, если вы сделаете его объектом JSON, вы можете заключить все 97 (или более) в этот объект и отправить только один объект.

Если его более 5-10 параметров, тогда создайте объект, который принимает параметры вместо этого, это может быть типизированный набор данных, структура или что-то еще.

Вместо:

Mywebservice.CreateUser(Firstname, LastName, Age,Sex, Haircolor,AmountOfFingers,AmountOfTeeht,Childrens,,,,,,,,,,,,,and so on)

Сделайте:

Dim MyUser as new UserObject
MyUser.Firstname="Stefan"
...and so on...
MyWebservice.CreateUser(UserObject)

Для этого вызовите метод Hibernate Session.createSQLQuery (). Сначала необходимо получить сеанс гибернации, а затем использовать этот сеанс для выполнения SQL. См. эту ссылку , чтобы узнать, как получить сеанс Hibernate из приложения Grails. Затем см. эту ссылку для получения сведений об использовании Hibernate для выполнения SQL.

Часть jquery

// initialize counter
var counter = 0;

// set the + functionality
$('#plus').click( function(){$('#display').html( ++counter )} );
// set the - functionality
$('#minus').click( function(){$('#display').html( (counter-1<0)?counter:--counter )} );
// initialize display
$('#display').html( counter );

и html

<span id="plus">+</span>
<span id="minus">-</span>
<div id="display"></div>

По моему собственному опыту, сигнатуры методов начинают путаться и их трудно запомнить с более чем 5 или 6 параметрами. И как только вы преодолеваете 10 параметров, это просто смешно.

Эти параметры действительно должны быть объединены в объект (или небольшой набор объектов), который содержит все данные. В службах, которые я использую, каждая операция службы всегда принимает один объект Request и возвращает один объект Response.

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

Другое возможное решение - инкапсулировать параметры в некоторый класс метаданных, предназначенный для хранения параметров. Это упростило бы подпись метода. Однако в некоторых отношениях вы просто перекладываете проблему на класс параметров. Но если параметры можно разделить на темы, этот метод можно использовать, используя несколько классов метаданных, каждый из которых будет включен в качестве параметра в веб-службу. Это должно упростить задачу и помочь вам сориентироваться в этом монстре.

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

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

Для всего остального я использую 3 параметра и иногда поднимаюсь до 5.

Как Стив МакКоннелл упоминает в Code Complete , золотое правило - 4 +/- 3 параметра. Обычному человеку сложно запомнить более 4 параметров, 5-7 следует использовать только в особых случаях, и никогда не следует использовать 8 или более.