Scala: выбор функции, возвращающей Option, против PartialFunction
Я относительный новичок в Scala и хотел бы получить совет, как продолжить реализацию, которая, кажется, может быть сделана либо с функцией, возвращающей Option, либо с PartialFunction. Я прочитал все соответствующие сообщения, которые смог найти (см. внизу вопроса), но они, похоже, касаются технических деталей использования PartialFunction или преобразования одной функции в другую; я ищу ответ типа "если обстоятельства таковы: X,Y,Z, то используйте A, иначе B, но также рассмотрите C".
Мой пример использования - поиск пути между локациями с помощью библиотеки искателей путей. Скажем, местоположения имеют тип L, путь имеет тип P, а желаемым результатом поиска пути будет Iterable[P]. Результат поиска пути должен быть собран путем запроса всех устройств поиска пути (в чем-то вроде Google maps это могут быть велосипед, автомобиль, пешком, метро и т.д.) на их предложения пути, которые могут быть или не быть определены для конкретной пары начального и конечного местоположения.
Кажется, есть два пути решения этой задачи:
(a) определить средство поиска пути как f: (L,L) => Option[P] и затем получить результат с помощью чего-то вроде finders.map( _.apply(l1,l2) ).filter( _.isDefined ).map( _.get )
(b) определить средство поиска пути как f: PartialFunction[(L,L),P] и затем получить результат через что-то вродеfinders.filter( _.isDefined( (l1,l2) ) ).map( _.apply( (l1,l2)) )`
Кажется, что использование функции, возвращающей Option[P], позволит избежать двойной оценки результатов, поэтому для дорогостоящих вычислений это может быть предпочтительнее, если только не кэшировать результаты. Также кажется, что при использовании Option можно иметь произвольную входную сигнатуру, тогда как PartialFunction ожидает один аргумент. Но мне особенно интересно услышать от кого-то с практическим опытом о менее непосредственных, более "широких соображениях", таких как взаимодействие с библиотекой Scala. Будет ли использование PartialFunction иметь значительные преимущества в обеспечении доступности определенных методов API коллекций, которые могут окупиться другими способами? Будет ли такой код в целом более лаконичным?
Смежные, но разные вопросы: