Получить методы: один против многих

Question

getEmployeeNameByBatchId (int batchID)
getEmployeeNameBySSN (Object SSN)
getEmployeeNameByEmailId (String emailID)
getEmployeeNameBySalaryAccount (SalaryAccount salaryAccount)

или

getEmployeeName (int typeOfIdentifier, byte [] identifier) ​​-> В этих методах typeOfIdentifier сообщает, является ли идентификатор batchID / SSN / emailID / salaryAccount

Какой из вышеперечисленных является лучшим способом реализации метода get?

Эти методы будут в сервлете, и вызовы будут выполняться из API, который будет предоставлен клиентам.

Answer 1

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

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

Лично я бы рекомендовал использовать уникальное имя для метода, чтобы впоследствии не возникало проблем с попыткой перегрузить один и тот же параметр методами объекта. Кроме того, если в будущем кто-то расширит ваш класс и внедрит другой void getEmployeeName (String name), он не будет переопределять ваш.

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

Answer 2

Я согласен со Стефаном: одна задача, одно имя метода , даже если вы можете сделать это несколькими способами. Функция перегрузки метода была предоставлена ​​именно для вашего случая.

• getEmployeeName (int BatchID)
• getEmployeeName (String Email)
• и т.д.

И Избегайте вашего второго решения любой ценой. Пахнет как "твой старый пустота * из C". Аналогично, передача Java-объекта почти так же плоха, как и C void *.

Answer 3

Я бы использовал первый вариант или перегрузил бы его в этом случае, так как у вас есть 4 разных параметра подписи. Однако конкретность помогает понять код через 3 месяца.

Answer 4

Если переписать вопрос, вы можете задать:

"ВЫБРАТЬ имя ИЗ ..."
"ВЫБЕРИТЕ SSN ОТ ..."
"ВЫБЕРИТЕ электронную почту ОТ ..."
против
"ВЫБРАТЬ * ИЗ ..."

И я думаю, что ответ на этот вопрос прост, и все это знают.

Что произойдет, если вы измените класс Employee? Например: Вы должны удалить электронную почту и добавить новый фильтр, например, отдел. Со вторым решением у вас есть огромный риск не заметить никаких ошибок, если вы просто измените порядок идентификатора int «константы». С первым решением вы всегда заметите, если вы используете метод в некоторых давно забытых классах, в противном случае вы забыли бы изменить новый идентификатор.

Answer 5

Первый, вероятно, лучший в Java, учитывая, что он безопасен (в отличие от других). Кроме того, для «нормальных» типов второе решение, по-видимому, обеспечивает только громоздкое использование для пользователя. Однако, поскольку вы используете Object в качестве типа для SSN (который имеет семантическое значение вне Object), вам, вероятно, не сойдет с рук этот тип API.

В общем, в данном конкретном случае я бы использовал подход со многими добытчиками. Если все идентификаторы имеют свой собственный тип класса, я мог бы пойти по второму пути, но переключиться внутри класса вместо предоставленного / определяемого приложением идентификатора типа.

Answer 6

В таком тривиальном случае я бы пошел с перегрузкой. То есть:

getEmployeeName( int batchID );
getEmployeeName( Object SSN );

etc.

Только в особых случаях я бы указывал тип аргумента в имени метода, т. Е. Если тип аргумента сложно определить, если существует несколько типов аргументов, которые имеют одинаковый тип данных (batchId и employeeId, оба int) или если методы получения сотрудника радикально отличаются для каждого типа аргумента.

Не понимаю, зачем мне это использовать

getEmployeeName(int typeOfIdentifier, byte[] identifier)

, так как требуется, чтобы вызывающий и вызывающий вызывали значение на основе typeOfIdentifier. Плохой дизайн.

Answer 7

Вы думаете C / C ++.

Использовать объекты вместо байта идентификатора (или целого числа).

Плохо, подход с перегрузкой лучше, а использование SSN в качестве первичного ключа не очень хорошо

public ??? getEmployeeName(Object obj){

if (obj instanceof Integer){

  ...

} else if (obj instanceof String){

...

} else if .... // and so on


} else throw SomeMeaningFullRuntimeException()

return employeeName
}

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

Документируйте это, чтобы клиент знал, какие объекты ожидать. Или создайте свои собственные обертки. Я предпочитаю первый вариант.

Answer 8

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

Примечание: кстати, использование Enums может быть чем-то, что следует учитывать в некоторых случаях.

Answer 9

Разделение между процессом поиска и критериями поиска, которые предлагает Джрудольф в своем примере, превосходно. Интересно, почему это не самое популярное решение? Я что-то пропустил?

Answer 10

Лично я предпочитаю иметь явное имя "... ByRoomNumber", потому что, если вы столкнетесь со многими "перегрузками", вы в конечном итоге внесете нежелательные ошибки. Быть откровенным imho лучший способ.