本文主要是介绍clean code-代码整洁之道 阅读笔记(第十一章),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
第十一章 系统
“复杂要人命,它消磨开发者的生命,让产品难以规划、构建和测试。”
--RayOzzie,微软公司首席技术官
11.1 如何建造一个城市
每个城市都有一组组人管理不同的部分,有些人负责全局,其他人负责细节。
城市能运转,还因为它演化出恰当的抽象等级和模块,好让个人和他们所管理的“组件”即便在不了解全局时也能有效地运转。
11.2 将系统的构造与使用分开
软件系统应将启始过程和启始过程之后的运行时逻辑分离开,在启始过程中构建应
用对象,也会存在互相缠结的依赖关系。
下例就是典型的情形:延迟初始化/赋值
public Service getService(){if(service==null)service = new MyServiceImpl(...); // Good enoughdefault for most cases?return service;
}
应当将这个过程从正常的运行时逻辑中分离出来,确保拥有解决主要依赖问题的全局性一贯策略。
11.2.1 分解main
将构造与使用分开的方法之一是将全部构造过程搬迁到main或被称之为main的模块中,设计系统的其余部分时,假设所有对象都已正确构造和设置。
11.2.2 工厂
有时应用程序也要负责确定何时创建对象。
比如,在某个订单处理系统中,应用程序必须创建LineItem实体,添加到Order对象。在这种情况下,我们可以使用抽象工厂模式让应用自行控制何时创建LineItems,但构造的细节却隔离于应用程序代码之外。
11.2.3 依赖注入
有一种强大的机制可以实现分离构造与使用,那就是依赖注入(Dependency Injection,DI),控制反转(Inversion of Control,IoC)在依赖管理中的一种应用手段。控制反转将第二权责从对象中拿出来,转移到另一个专注于此的对象中,从而遵盾了单一权责原则。
在依赖管理情景中,对象不应负责实体化对自身的依赖。反之,它应当将这份权责移交给其他"有权力"的机制,从而实现控制的反转。因为初始设置是一种全局问题题,这种授权机制通常要么是main例程,要么是有特定目的的容器。
11.3 扩容
“一开始就做对系统”纯属神话。反之,我们应该只去实现今天的用户故事,然后重构,明天再扩展系统、实现新的用户故事。这就是迭代和增量敏捷的精髓所在。测试驱动开发、重构以及它们打造出的整洁代码,在代码层面保证了这个过程的实现。
软件系统与物理系统可以类比。它们的架构都可以递增式地增长,只要我们持续将关注面恰当地切分。
横贯式关注面
AOP是一种恢复横贯式关注面模块化的普适手段。
在AOP中,被称为方面(aspect)的模块构造指明了系统中哪些点的行为会以某种方式被修改,从而支持某种特定的场景。这种说明是用某种简洁的声明或编程机制来实现的一致的。
11.4 Java代理
Java代理适用于简单的情况,例如在单独的对象或类中包装方法调用。然而,JDK提供的动态代理仅能与接口协同工作。对于代理类,你得使用字节码操作库,比如CGLIB、ASM或Javassist。
11.5 纯 Java AOP 框架
幸运的是,编程工具能自动处理大多数代理模板代码。在数个Java相架中,代理都是内嵌的,如SpringAOP和JBossAOP等,从而能够以纯Java代码实现面向方面编程。在Spring中,你将业务逻辑编码为旧式Java对象。POJO自扫门前雪,并不依赖于企业框架(或其他域)。因此,它在概念上更简单、更易于测试驱动。相对简单性也较易于保证正确地实现相应的用户故事,并为未来的用户故事维护和改进代码。
使用描述性配置文件或API,你把需要的应用程序构架组合起来,包括持久化、事务、安全、缓存、恢复等横贯性问题。在许多情况下,你实际上只是指定Spring或Jboss类库,框架以对用户透明的方式处理使用Java代理或字节代码库的机制。这些声明驱动了依赖注入(DI)容器,DI容器再实体化主要对象,并按需将对象连接起来。
11.6 AspectJ 的方面
通过方面来实现关注面切分的功能最全的工具是AspectJ语言,一种提供“一流的”将方面作为模块构造处理支持的Java扩展。在80%~90%用到方面特性的情况下,SpringAOP和JBossAOP提供的纯Java实现手段足够使用。然而,AspectJ却提供了一套用以切分关注面的丰富而强有力的工具。AspectJ的弱势在于,需要采用几种新工具,学习新语言构造和使用方式。
藉由AspectJ近期引入的“annotation form”(使用Java5annotation定义纯Java代码的方面),新工具采用的问题大大减少。另外,Spring Framework 也有一些让拥有较少 AspectJ 经验的团队更容易组合基于annotation的方面的特性。
11.7 测试驱动系统架构
最佳的系统架构由模块化的关注面领域组成,每个关注面均用纯Java(或其他语言)对象实现。不同的领域之间用最不具有侵害性的方面或类方面工具整合起来,这种架构能测试驱动,就像代码一样。
11.8 优化决策
模块化和关注面切分成就了分散化管理和决策。在巨大的系统中,不管是一座城市或一个软件项目,无人能做所有决策。众所周知,最好是授权给最有资格的人。但我们常常忘记了,延迟决策至最后一刻也是好手段。
拥有模块化关注面的POJO系统提供的敏捷能力,允许我们基于最新的知识做出优化的、时机刚好的决策,决策的复杂性也降低了。
11.9 明智使用添加了可论证价值的标准
有了标准,就更易复用想法和组件、雇用拥有相关经验的人才、封装好点子,以及将组件连接起来。不过,创立标准的过程有时却漫长到行业等不及的程度,有些标准没能与它要服务的采用者的真实需求相结合。
11.10 系统需要领域特定语言
领域特定语言(Domain-SpecificLanguage,DSL)是一种单独的小型脚本语言或以标准语言写就的API,领域专家可以用它编写读起来像是组织严谨的散文一般的代码。
DSL在有效使用时能提升代码惯用法和设计模式之上的抽象层次。它允许开发者在恰当的抽象层级上直指代码的初衷。
领域特定语言允许所有抽象层级和应用程序中的所有领域,从高级策略到底层细节,使用POJO来表达。
11.11 小结
系统也应该是整洁的。侵害性架构会湮灭领域逻辑,冲击敏捷能力。当领域逻辑受到困扰,质量也就堪忧,因为缺陷更易隐藏,用户故事更难实现。当敏捷能力受到损害时,生产力也会降低,TDD的好处遗失殆尽。
在所有的抽象层级上,意图都应该清晰可辨。只有在编写POJO并使用类方面的机制来无损地组合其他关注面时,这种事情才会发生。
无论是设计系统或单独的模块,别忘了使用大概可工作的最简单方案。
这篇关于clean code-代码整洁之道 阅读笔记(第十一章)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!