摘要: 刚看了老赵的一片文章，发现现在做的项目的配置文件，就有点儿像内部DSL了，汗颜...不过现在这个配置处理方式并不太完美，比如说前套中加入功能，外层的处理很难给内层的处理加功能，只能是再在中间加上一层处理并且可能会重复执行某些已经做的事情来解决这个问题，举个例子：classA可以获取到矩形，假如是写死的；classB可以获取到屏幕截图，前提是需要一个矩形范围；classC可以将图片转换为二进制格式，...阅读全文

摘要: 今儿又做了个大东西，集大成的东西往往是职责不明确、修改不方便、通用性不强的。如果发现某个类不容易测试，就说明这个类有职责过多、耦合严重的问题了。阅读全文

摘要: 今天在包装一个功能的时候遇到一个问题，谁应该知道更多的信息？问题是这样的，一个类，需要一个文件路径参数，这个参数是写在构造函数中还是写在方法签名中？1.写在构造函数中：好处是可以在构造时送入，可以通过配置读取送入，并且配置读取模块不用分离在个各类中，即在同一处做配置文件读取，并初始化好这个类以后就可以送入其他类来使用了。坏处是不太容易理解，接口缺少这个参数，会变得有一些难以理解。2.写在方法签名中...阅读全文

摘要: 今天一口气把这本书读完了，收获确实不小，书中提到的一些提高效率的理念，比如利用各种工具完成任务、去掉重复、尽可能自动化等等，都是非常实用的。1.利用各种代码分析工具比如静态分析工具、源代码分析工具等，找出潜在的Bug。2.如果对getter/setter不加限制的使用，无异于对外暴露细节破坏封装特性，是数据与预期的不一致。所以还是妥善使用，比如空置访问权限（在.net中建议的做法是使用proper...阅读全文

摘要: 重新修改了Operator的大框架，Operator与Service的交互分布在不同的逻辑层次上，使得对Service通信的封装也就需要在不同的逻辑层次。现在使用的办法是通过传递失血对象，将Service可能提供或者需要的参数全部包含进对象中，这样，可以将与Service通信的部分独立出来，但是需要在处理逻辑内部维护和同步一些状态、参数等信息，并且这个并不是最佳实践。另外琢磨了一下，是否可以采用类...阅读全文