IntelliJ и встроенный интерфейс функций Java - PullRequest
0 голосов
/ 07 ноября 2018

Компоненты My Spring реализуют функцию java.util.function. Идея заключается в том, чтобы создать функциональный стиль с небольшими инкапсулированными функциями.

@Component
public class MyFunction implements Function<In, Out> {
    public Out apply(In in) { .... }
}

// example usage
@RestController
public class MyApi {
    private MyFunction f;
    public void foo() {
        someList.stream()
            .map(f)
            . // whatever
    }
}

С IntelliJ 2018.1 возникают две проблемы:

  • «Найти использование» предлагает выбор, чтобы найти использование основного метода. Если я случайно нажму «Да», IntelliJ найдет миллион использований и замедлится, пока он почти не замерзнет. Ну, я определенно должен выбрать «Нет», но это все еще небольшая проблема.
  • Использование функции в потоке (например, фильтра) с «Ссылкой на метод» (как предполагает IntelliJ) еще более проблематично. Использование «Find Usages» и выбор «No» не покажут «реального» использования, которое я ищу. Это затрудняет навигацию по коду.

Это подводит меня к моим вопросам: это хорошая практика - использовать встроенный интерфейс функций или мне следует написать собственную функцию, не объявляя ее как FunctionalInterface? Считаете ли вы упомянутые проблемы ошибкой IntelliJ? Есть ли обходные пути, о которых вы знаете?

Ответы [ 2 ]

0 голосов
/ 07 ноября 2018

Ваш подход мне кажется верным, но я стараюсь избегать прямой реализации Function в максимально возможной степени. Основная причина: наименование .

Я могу понять, что если у класса есть значимое имя (например, InOutMapFunction), вам может не потребоваться, чтобы у метода также было значимое имя. Тем не менее, я предпочитаю имена, такие как InOutMapper.mapInToOut для InOutMapFunction.apply.

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

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

  • SomeParticularTypeContextFinder и
  • Function<SomeParticularType, SomeParticularTypeContext>.

Вот как я могу реализовать ваш пример:

@Component
public class PlainInOutMapper implements InOutMapper {
    @Override
    public Out mapInToOut(In in) { .... }
}

@FunctionalInterface
interface InOutMapper {
    Out mapInToOut(In in);
}

// example usage
@RestController
public class MyApi {
    private List<In> someList;

    private InOutMapper mapper;
    public void foo() {
        someList.stream()
                .map(mapper::mapInToOut)
                . // whatever
    }
}
0 голосов
/ 07 ноября 2018

Вы можете ограничить область поиска с помощью «Настройки поиска» (по умолчанию в Windows: CTRL + ALT + SHFT + F7)

enter image description here

Настройки применяются к поиску через ALT + F7, а также к колесику мыши. Может быть, ограничение вашего текущего модуля делает свое дело?

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