-
二叉查找树学习笔记
二叉查找树如其名是一种主要用于查找的每个非叶子节点最多有两个子节点（左右子节点）的树，其特点是： a b c 任何a, b, c三个节点（父节点和两个子节点，左右子节点可能只有一个或者都没有）满足a < b < c。对于相等的值使用节点计数+1或者节点中的链表等不同的方式来处理。 a < b < c这个条件乍一看和二分搜索binary_search很像，实际查找元素时也是类似的，时间复杂度在O(logn)。 一般的二叉查找树（不考虑链表退化和平衡的处理）包含查找，创建树/增加节点，删除节点，前/中/后序遍历等操作，下面分别介绍。
-
代码吐槽1
我发现离厕所远一点有一点好：在去厕所的路上经常会有idea出来，这篇文章就是其中之一。 言归正传，我对看到的别人的代码吐槽的想法由来已久。大部分时候，碍于情面不能直说。有时候委婉地说了，愿意听的当场改，大部分时候都我行我素。以至于我觉得写这些代码的时候是不是都是从北大青鸟出来的？ 第一个：尤达表达式，null = someVariable（Java代码中） 我很敬佩从C/C++转到Java的人，但是我很看不起转过来了不学习相应语法的人。 第二个：collection.size() == 0 估计老师没教过collection.isEmpty() 第三个：StringUtils.equals(“foo”, someVariable) 公司规范的受害者，而且顽固不化。什么时候需要用工具类来比较，什么时候不需要分不清。 第四个：someMap.get(SomeConstains.ABC)出现多处 只有一处问题不大，多处不知道static import。
-
并发，缓存与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方法。
-
简易顺序执行框架attic开发笔记1
最近业余时间在写一个叫做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开发笔记第一部分。
-
个人小结的Java中常见日志与异常处理实践
原本我以为日志和异常没啥东西，只要按照《Effective Java》中编码就行。但是实际情况告诉我写Java代码的人有些不知道《Effective Java》，还有些人只会依样画葫芦，甚至把错误的拼写比如accessable也一并画了下来。更让我头疼的是，两者加在一起导致的前人所有的异常都打印ERROR级别日志+抛出异常，后面的人想也不想一样的也全打ERROR级别日志+抛出异常。好吧，其实我想说打印日志也是有好的实践的，Java的异常也不是随便乱用的。 不是所有异常都需要打印ERROR级别日志 这很明显，但是似乎有人不明白什么时候不打ERROR级别日志。以下是个人建议的级别使用策略：
-
commons-httpclient 3.x如何按照host单独配置连接数和超时参数
以下内容是个人工作中对commons-httpclient分析的小结。 jakarta commons-httpclient是常用的HTTP Client实现，基于HTTP的协议比如SOAP的一些实现比如XFire也有使用commons-httpclient。作为一个常用的类库，学习如何正确和高效地使用是非常有必要的。 首先，按照官方网站的建议：为了提高性能，建议使用单个httpclient实例。（个人认为开启多个Http Client就像开启多个浏览器实例一样……） 第二，并发情况下使用MultiThreadedHttpConnectionManager，这条不难理解。 接下来是参数配置。官方网站提供的配置文档 中提供了很多参数，这里给出连接数和超时配置（大部分都是配置在HttpConnectionManager级别的：
-
service, manager and dao
酝酿这篇文章其实有一段时间了，只是最近晚上回家之后没啥动力（颓废？），于是只能在某个休息日的早上写了。 首先说明一下service、manager和dao指的是java web中常见的分层，我要讲的是自己在这种分层设计上的进一步理解，基于从学java开始到现在工作两年左右的经验。 简略地概括下现阶段我对分层的职责的认识：