ARTS 打卡第一周

Algorithm

Lettcode 141 给定一个链表，判断链表中是否有环



根据题意，判断一个单项链表中是否有环。 解决思路是通过快慢指针，快指针是慢指针的两倍倍速， 当快指针遇见慢指针时，则认为有环。 否则没有



    public boolean hasCycle(ListNode head) {
        if (head == null) return false;
        // 快慢指针初始为头指针
        ListNode slow = head;
        ListNode fast = head;
        while (fast != null && fast.next != null) {
        		// 每次走一步
            slow = slow.next;
            // 每次走两步
            fast = fast.next.next;
            // 快慢指针相遇则认为有环，直接返回
            if (slow == fast) {
                return true;
            }
        }
        return false;
    }



复杂度分析：

空间复杂度：因为只用到了快慢指针两个变量引用， 并未创建新的空间，所以是O（1）

时间复杂度：最坏的情况将整个链表遍历一次，时间复杂度是O（N）

Review

什么是ribbon

Ribbon plays a critical role in supporting inter-process communication in the cloud. The library includes the Netflix client side load balancers and clients for middle tier services.



ribbon在进程间通信扮演着至关重要的角色， 客户端支持负载均衡，以及中间层服务。



ribbon的功能特性

1. Multiple and pluggable load balancing rules 多个可插拔的负载均衡规则

2. Integration with service discovery 集成服务发现

3. Built-in failure resiliency 内置弹性失败

4. Cloud enabled 云端启用

5. Clients integrated with load balancers 客户端集成负载均衡

6. Archaius configuration driven client factory 通过Archaius配置驱动客户端工厂



ribbon三个子工程

1. ribbon-core: includes load balancer and client interface definitions, common load balancer implementations, integration of client with load balancers and client factory. 包括负载均衡及客户端接口定义，通用负责均衡实现， 客户端与负载均衡和client工厂集成

2. ribbon-eureka: includes load balancer implementations based on Eureka client, which is the library for service registration and discovery. 基于eureka cleint包含负载均衡实现，这个库包含有服务注册与发现

3. ribbon-httpclient: includes the JSR-311 based implementation of REST client integrated with load balancers. 包括基于JSR-311rest客户端实现，集成客户端负载均衡



总结： 主要介绍了ribbon的功能特性， 以及项目组成部分（各个模块里面包含的主要功能）

Tip

今日tip是关于git分支合并的小细节， 日常合并分支的方式大致有如下两种：

1. git merge 分支名 将指定分支合并到当前分支

2. git merge --no-ff -m "merge with no-ff" 分支名 也是将指定分支合并到当前分支，当加上--no-ff参数后，就可以用普通模式合并，合并后的历史有分支合并记录，能看出来曾经做过合并。



Share

理解单一职责



一个类或一个模块只有一种职责



背后的思想解读



定义本身是比较简单的。以类的角度来讲，强调的是类只负责一组相关的功能或者业务，也就是高内聚性。 然而如何定义一个类是否符合单一职责是比较主观的。因为在不同应用场景，以及不同业务阶段类是否符合单一定义都不一样。所以业务在变，对类的单一定义也会边。



权衡利弊



过度追求单一会造成类或模块膨胀，然而不考虑单一职责代码又会耦合。



一般设计过程中，先以一个抽象层面定位，粗粒度设计代码。再根据需求迭代不断演进。