上面的类图是针对最近改造的类图。 原先有多个command，执行各自的逻辑。现在由于command涉及的配置需要放缓存，抽象出config。config和command存在一定的映射关系，通过CommandFactory维持。考虑到config存入缓存时会以接口或者抽象类方式，取出时丢失了直接类型。使用VISITOR模式多态创建command。 现有command中有一个是条件型的，会根据执行时的上下文生成新的command并执行。在配置分离后，理论上变成生成新的config转换成command后执行。因为不想在CommandFactory中带入执行上下文（这样就破坏了简单的config-command关系），所以只能延迟到command执行时委托条件command的配置计算得到实际配置，再通过CommandFactory重新生成command，最后执行实际逻辑。 个人认为，这里理解的难点在于延迟执行。如果存在并不能立即决定的逻辑，则可以考虑返回一个实现某个接口的类，并包含执行的相关数据。比如这里返回ConditionalCommand，包含了ConditionalConfig和CommandFactory，在实际执行时计算。并通过CommandFactory的引用创建实际执行的Command后运行逻辑。

最近业余时间在写一个叫做attic的东西。attic的灵感来自《敏捷开发》中的验收测试，比如下面的验收测试脚本： AddEmp 1429 “Robert Martin” 3215.98 Payday Verfiy Paycheck EmpId 1429 Grosspay 3215.88 这是不懂编程的人，具体来说是业务人员也能看懂的验收测试脚本。《敏捷开发》没有对脚本的执行与实现做介绍，但是我觉得我get the point了： 按照行解析执行命令（Command） 类似CSV方式解析行，因为存在空格，不能直接按照空格split 有很多命令，需要命令库或者动态加载命令 转化为程序设计就是 val context = new CommandContext file.getLines.foreach{line => createCommand(line).execute(context) } context是命令之间交互的载体，个人认为命令之间肯定存在依赖关系 createCommand完成解析和创建命令，可能是这样： def createCommand(line: String): Command = { val cmdNameAndArgs = parse(line) val cmd = Class.forName(cmdNameAndArgs.name).newInstance.asInstanceOf[Command] cmd.setArguments(cmdNameAndArgs.arguments) return cmd } 这里cmd直接用load class的方式，便于扩展。parse部分相对难一些，我暂时用空格分割实现，之后肯定要换成类似CSV解析格式。 以上就是attic开发笔记第一部分。

原本我以为日志和异常没啥东西，只要按照《Effective Java》中编码就行。但是实际情况告诉我写Java代码的人有些不知道《Effective Java》，还有些人只会依样画葫芦，甚至把错误的拼写比如accessable也一并画了下来。更让我头疼的是，两者加在一起导致的前人所有的异常都打印ERROR级别日志+抛出异常，后面的人想也不想一样的也全打ERROR级别日志+抛出异常。好吧，其实我想说打印日志也是有好的实践的，Java的异常也不是随便乱用的。 不是所有异常都需要打印ERROR级别日志 这很明显，但是似乎有人不明白什么时候不打ERROR级别日志。以下是个人建议的级别使用策略：