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

Question

Я часто вижу это:

class A { def operation(b: B) = A.operation(a,b) }
object A { def operation(a: A, b: B) = /* impl */ }

Вместо просто:

class A { def operation(b: B) = /* impl */ }
object A { def operation(a: A, b: B) = a.operation(b) }

Или даже просто:

class A { def operation(b: B) = /* impl */ }

В основном в книгах по функциональному программированию, но я также видел такой шаблон в нашем производственном коде несколько раз. Между тем operation почти никогда не называется A.operation(a,b) - вместо этого он всегда a.operation(b) или a operation b, что имеет смысл, поскольку инфиксная запись просто (возможно, возможно) более читабельна.

* 1017 Зачем вообще определять метод в объекте-компаньоне, если вы его никогда не используете? Почему вы хотите делегировать это? Есть ли какая-либо практическая причина для этого или это просто какой-то "каждый, кто делает это, начиная с Х, так что мы могли бы это сделать?"

Answer 1

Имо, основная причина в том, что def operation(a: A, b: B) = ??? может и должна быть реализована как чистая функция , и это семанти c указывает это более четко по сравнению с class A { def operation(b: B)}.

Последний - объектно-ориентированный подход. И, если кто-то знаком с OOP, он может изменить состояние A, что приведет к побочному эффекту.

Итак, все это указывает на то, что реализация не имеет побочных эффектов.