学习如何避免OOP中的副作用和状态的最佳资源是什么？

我最近一直在玩函数式编程,关于副作用的主题有很好的处理方法,为什么要包含它们等等.在使用OOP的项目中,我正在寻找一些资源来规划一些策略.最小化副作用和/或状态.

一个很好的例子是RESTful Web Services一书,它为您提供了最小化Web应用程序状态的策略.还存在其他什么？

请记住,我不是在寻找另一个OOP分析师/设计模式书(尽管良好的封装和松耦合有助于避免副作用),而是主题本身就是状态/副作用的资源.

一些汇编的答案

主要关心状态的OOP程序员因并发而这样做,因此请阅读Java Concurrency in Practice.[ 正是我所寻找的]

使用TDD使副作用更明显[我喜欢它,例如:你的setUps越大,运行测试所需的状态就越多=好警告]

命令查询分离 [好东西,防止更改函数参数的副作用,这通常令人困惑]

方法只做一件事,如果他们改变对象的状态,可能会使用描述性名称,因此它很简单明了.

使对象不可变 [我真的很喜欢这个]

将值作为参数传递,而不是将它们存储在成员变量中.[我不联系这个; 它混乱了功能原型,并且被"清洁代码"和其他书籍积极劝阻,尽管我承认它有助于国家问题]

重新计算值而不是存储和更新它们[我也非常喜欢这个; 我在应用程序中处理性能是一个小问题]

同样,如果可以避免,请不要复制状态.让一个对象负责保留它并让其他人访问它.[基本OOP原则,好建议]

rtperson.. 7

我不认为你会在OO世界中找到关于这个主题的很多当前材料,仅仅因为OOP(以及大多数命令式编程,就此而言)依赖于状态和副作用.例如,考虑记录.这是纯粹的副作用,但在任何自尊的J2EE应用程序中,它无处不在.Hoare的原始QuickSort依赖于可变状态,因为你必须围绕一个数据库交换值,但它也无处不在.

这就是为什么许多OO程序员难以绕过函数式编程范例的原因.他们试图重新分配"x"的价值,发现它无法完成(至少不会像他们所使用的其他语言一样),他们举起手来喊"这是不可能!" 最终,如果他们有耐心,他们会学习递归和曲线以及地图功能如何取代循环的需要,并且他们冷静下来.但有些人的学习曲线可能非常陡峭.

如今,那些最关心避免状态的OO程序员是那些致力于并发的人.原因很明显 - 当你试图管理线程之间的并发时,可变状态和副作用会引起巨大的麻烦.因此,我在OO世界中看到的关于避免状态的最佳讨论是Java Concurrency in Practice.

我不认为你会在OO世界中找到关于这个主题的很多当前材料,仅仅因为OOP(以及大多数命令式编程,就此而言)依赖于状态和副作用.例如,考虑记录.这是纯粹的副作用,但在任何自尊的J2EE应用程序中,它无处不在.Hoare的原始QuickSort依赖于可变状态,因为你必须围绕一个数据库交换值,但它也无处不在.

这就是为什么许多OO程序员难以绕过函数式编程范例的原因.他们试图重新分配"x"的价值,发现它无法完成(至少不会像他们所使用的其他语言一样),他们举起手来喊"这是不可能!" 最终,如果他们有耐心,他们会学习递归和曲线以及地图功能如何取代循环的需要,并且他们冷静下来.但有些人的学习曲线可能非常陡峭.

如今,那些最关心避免状态的OO程序员是那些致力于并发的人.原因很明显 - 当你试图管理线程之间的并发时,可变状态和副作用会引起巨大的麻烦.因此,我在OO世界中看到的关于避免状态的最佳讨论是Java Concurrency in Practice.

我认为规则很简单:方法应该只做一件事,并且意图应该在方法名称中清楚地传达.

方法应该查询或更改数据,但不能同时查询或更改数据