ARTS - Week 1

Algorithm

LeetCode 15 题： 3 Sum

这道题的关键点是将问题转化为一个查询的问题。细节上要注意的点是结果集要去重。

基本思路是：

• 求解2Sum问题时，我们会将问题变成“在数组中查询0-a是否存在”

• 那么接下来我们要做的就只是优化查询速度，那么无非就是hash，二分查找等。

• 3Sum的基本思路也是这样，将问题转化成查询问题，然后优化查询速度寻找最优解

• 暴力解法：三重循环遍历

方法一：

两重循环，第三重循环改成查找，最终的三元组的解添加到一个Set里进行去重

方法二：

先排序，之后第一重循环里，分别从剩余数组元素的左边和右边向中间遍历。由于数组有序，可以通过比较大小的方式来选择移动左边还是右边

Review

来自Robert C. Martin（Bob大叔）的 [Why Clojure?]

通篇文章的中心主题都是围绕着作者为什么认为Clojure这一款LISP语言是他所认为的最棒的语言。

Bob大叔年纪已经非常大了，完全可以算得上是“骨灰级程序员”、“大师级程序员”。文章开篇就列举了他40年以来所使用过的各种语言，只有你没听过的，没有他没用用过的，以此来表明他有足够的资格和立场来对比市面上所有的语言。

他对认为Clojure是最棒的语言这一论点持有的最核心的论据是：Syntax reduces economy of expression。也就是说“一门语言的保留字太多，会减少它表达能力的经济性”。。。说实话，这个观点让我非常的无法感同身受。有可能是由于我入行太浅，还不懂大师的品味。也有可能是第一门语言（Java）对一个人的影响是深远的。

Bob大叔通过一个非常简单的例子——求前25个正整数的平方：

(println (take 25 (map #(* % %) (range))))

向我们展示了LISP型的函数式语言的魅力。

这里不得不承认大师的文字能力，真的是通俗易懂，简单透彻。让我这个第一次接触LISP代码的人几分钟就看懂了它的语法。

Bob大叔是从一个“神”的眼光去评判的一种语言的，但是我个人会有一些不同的角度，比如Java为什么这么火，就是因为他的Syntax很多，很难做到“一行代码”，但是这也恰恰使得它能让很多“初级程序员”非常轻易的开发大型系统（这可能并不算一个优点 :p)。

我相信用Clojure写代码的确会非常轻松愉快，但是我依然对它的可读性，重构友好度持保留意见，（逃～）

Tips

利用JDK AtomicInteger类实现一个简单的无锁编程。具体代码如下：

				//假设场景每一分钟的0秒去数据库读一次配置加载到内存中
				if (clockTic && atomicInteger.compareAndSet(0, 1)) {
          //这里会去访问数据库
            System.out.println("Connect to Database");
            atomicInteger.compareAndSet(1, 0);
        } else {
            System.out.println("Failed");
        }

平时我们经常会碰到这样的场景，定时去某个地方（例如数据库）读一下最新的配置，在高并发的场景下，我们肯定是希望这个行为只发生一次，即只访问一次数据库。

假设现在同时有100个线程进入到上面的代码的if这一行，虽然不能100%保证只有一个线程能compareAndSet成功，但是能compareAndSet成功的线程远小于100个

这意味着在高并发场景下，我们只用了一个简单的AtomicInteger就能大大提高程序性能！

Share

来自极客时间的一篇课程文章，如何利用基于充血模型的DDD开发一个虚拟钱包系统？

为什么选择share这篇文章，是因为之受人误导，错误的理解了DDD。而这篇文章，通俗易懂，让我清晰的了解了DDD的一个基本概况。把我的DDD道路“扳直”回到正途。

之前我错误的理解：



DDD只是把Service的代码移到了Domain对象中，所以DDD是为了面向对象而面向对象。



看完争哥的课程，虽然远谈不上理解了DDD，但是起码让我知道了，DDD长什么样，它是为了解决什么问题。

真正的DDD：

1. 对于简单的CRUD业务的系统，不适合DDD，基于面向过程的贫血模型开发即可，用DDD有一种杀鸡用牛刀的感觉。（没有用DDD开发过，体会不深）

2. 贫血模型和充血模型最大的区别是：贫血模型是数据和功能分离的，而充血模型是数据和功能都在一个类里面。

3. DDD绝不是将Service的代码挪到Domain类里这么简单，DDD的关键在于建立边界的业务模型，这就像“放盐少许”一样，有种只可意会，不可言传的意思。

4. 一些业务无关的代码，例如访问数据库，RPC调用，是可以不包括在领域对象里的。