functional-programming - 我应在多大程度上采用参照透明性？

Question

我正在使用erlang，mnesia和webmachine建立一个网站。我阅读的大多数文档都赞扬具有参照透明功能的优点。

问题是，所有数据库访问都是外部状态。这意味着，任何命中数据库的方法都不再是参照透明的。

可以说我在数据库中有一个用户对象，还有一些用于身份验证的函数。

参照不透明函数可能看起来像:

handle_web_request(http_info) ->
  is_authorized_user(http_info.userid),
  ...
%referentially opaque
is_authorized_user(userid) ->
  User = get_user_from_db(userid),
  User.is_authorized.

%referentially opaque
lots_of_other_functions(that_are_similar) ->
  db_access(),
  foo.

参照透明性要求我尽量减少参照不透明代码的数量，因此调用者必须从数据库中获取对象并将其作为参数传递给函数:

handle_web_request(http_info) ->
  User = get_user(http_info.userid),
  is_authorized_user(User),
  ...

%referentially opaque
get_user(userid) ->
  get_user_from_db(userid).

%referentially transparent      
is_authorized(userobj) ->
  userobj.is_authorized.

%referentially transparent    
lots_of_other_functions(that_are_similar) ->
  foo.

上面的代码显然不是生产代码-纯粹是出于说明目的。

我不想陷入教条。引用透明代码的好处(例如可证明的单元测试)是否证明了界面不太友好？我追求参照透明应该走多远？

Answer 1

为什么不完全采用参照透明性？

考虑get_user_from_db的定义。它如何知道如何与数据库对话？显然，它假设一些(全局)数据库上下文。您可以更改此函数，以便它返回一个以数据库上下文为参数的函数。你拥有的是...

get_user_from_db :: userid -> User

这是个谎言。您不能从用户ID转到用户。您还需要其他东西:数据库。

get_user_from_db :: userid -> Database -> User

现在，只需使用userid进行 curry 处理，并在稍后提供数据库，该函数将为您提供一个User。当然，在现实世界中， Database将是句柄，数据库连接对象或其他对象。为了进行测试，请为其提供一个模拟数据库。