-
并发，缓存与guava
作为一个已经用了很长时间缓存的javaer，老实说到今天为止才真正知道缓存该怎么用。为什么这么说呢？考虑如下代码： public Object compute(Object key) { Object value = null; if ( (value = cache.get(key)) == null ) { value = compteValue(key); } cache.put(key, value); } 是不是很熟悉？典型的缓存客户端代码，但是这段代码是有问题的。问题不在cache，而在于这段代码本身。考虑如下的场景：
-
简易顺序执行框架attic开发笔记2
接上篇。 空格的处理 本来想自己写词法分析的，结果自己编译原理基础不牢固写出来老是死循环，所以使用opencsv。核心代码如下： CSVReader csvReader = new CSVReader(reader, ‘ ‘); String[] fields = null; while ((fields = csvReader.readNext()) != null) { // do stuff with fields } csvReader.close(); 这里使用空格代替CSV默认的分割符号冒号。
-
多态与延迟执行
上面的类图是针对最近改造的类图。 原先有多个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后运行逻辑。
-
设计模式笔记1
设计模式的资料主要来自sourcemaking和《敏捷软件开发 原则、模式与实践》。 按照sourcemaking，设计模式主要分为 构造型模式 结构型模式 行为型模式 个人认为模式理解难度从低到高。 构造型模式 模式名 个人理解 FACTORY 由工厂决定创建哪个子类。多个子类，子类实例构造复杂时建议使用。Java中有基于static方法和新建工厂的方式。 ABSTRACT FACTORY 子类实例构造分组，比如多个“平台”，超类包含通用逻辑。“平台”与子类的实例矩阵。 BUILDER 多步创建。如果单步（方法）的参数比较复杂时推荐使用。 OBJECT POOL 对象池，典型如commons-pool，需要考虑并发问题。 PROTOTYPE 以某个实例为蓝本创建其他实例。Java中需要实现clone方法。