柔性设计

昨天和同学打电话,

讨论在类的一个方法,关于在方法体中满足某些条件

或者不满足某些条件直接return的做法，

与在方法体中进行很多的逻辑判断在方法体的最后位置return掉好的做法的优劣比较.

感觉如果在方法体的最后做逻辑判断并且return的话,

阅读代码的人要阅读很多无用的代码,

会增加大脑的负荷.

而且这种做法一般是c语言等面向过程思维的结果.

另外一个问题是关于方法堆栈的问题,

因为静态类的不修改类属性的静态方法在多线程并发的环境中调用是否安全.

类的方法是方法体的代码堆栈在整个内存中是为多个线程共享的,

对于不同的线程,线程拥有各自的隔离区,

包含该方法体内部的局部变量和临时变量,

因此在多线程环境中调用静态类的不修改类属性的静态方法在内存角度看是安全的.

接下来是关于方法的引用参数的问题.

我最近常常写这样的代码

void modifyDOContent(XXDO xxDo);

通过参数引用来修改参数状态

然后在把这个参数引用传递给另外一个方法

void modifyDOStatus(XXDO xxDo);

之前考虑这样写的优点是可以创建比较少的值对象,

通过变更值对象的属性来实现业务逻辑功能.

但是缺陷随之而来

就像你在吃火锅的时候,夹起一块羊肉,蘸蘸火锅料,蘸蘸芝麻酱,再蘸蘸甜面酱..

到最后乱糟糟的一块,也忘记最后吃的到底是什么了.

另外对于方法体内部的代码逻辑并没有进行显性地说明,

阅读者必须通过阅读整体的方法体代码才能了解处理的意图.

因此无法做到对业务逻辑或者代码逻辑的封装.

更加恶劣的是如果方法内的逻辑失败,

除非抛出异常否则因为不修改参数引用只是修改参数引用对象的属性,

这个很参数引用对象还是可用的,因此就为代码质量埋下了隐患.

另外修改值对象本身就破坏了领域对象的封装性,

如果有多个领域逻辑混杂在一起是不法简单地通过值对象状态来区分的.

恰好手边有 领域驱动设计 这本书

里面有一章讲解 柔性设计

对于这种情况,采用了释意接口,不可变值对象和无副作用函数的方法解决这一问题

释意接口可以认为是一种类似与约定优先的编程理念,对方法内部逻辑在名称上做直观显性地说明.

不可变值对象,一个包含业务逻辑的值对象创建后既不修改引用也不修改属性,

如果有这方面的需求可以使用DTO

数据传输对象

无副作用函数

不修改传过来的方法参数引用对象,而是作为返回结果返回一个新的值对象

如果方法内部逻辑处理失败可以通过抛出自定义异常或者返回null值来进行控制

楼主的句子好长，读一句要换两口气

  我会改进的