The Art of Language Design

Today there are thousands of high-level programming languages, and new ones continue to emerge. Human beings use assembly language only for specialpurpose applications. In a typical undergraduate class, it is not uncommon to find users of scores of different languages. Why are there so many? There are several possible answers:

今天有成千上万种高级编程语言,而且新的语言不断涌现。人类只在特定应用中使用汇编语言。在典型的本科课程中,发现使用数十种不同语言的情况并不罕见。为什么会有这么多种语言?这有几个可能的答案:

Evolution.

Computer science is a young discipline; we’re constantly finding better ways to do things. The late 1960s and early 1970s saw a revolution in “structured programming,” in which the goto-based control flow of languages like Fortran,Cobol,and Basic3 gave way to while loops, case (switch) statements, and similar higher level constructs. In the late 1980s the nested block structure of languages like Algol,Pascal,and Ada began to give way to the object-oriented structure of Smalltalk, C++, Eiffel, and the like.

计算机科学是一个年轻的学科;我们不断发现更好的做事方式。20世纪60年代末和70年代初,出现了“结构化编程”的革命,其中像Fortran、Cobol和Basic3这样基于goto的控制流让位给了while循环、case(switch)语句和类似的更高级构造。到了20世纪80年代末,像Algol、Pascal和Ada这样的语言的嵌套块结构开始让位于Smalltalk、C++、Eiffel等面向对象的结构。

Special Purposes.

Many languages were designed for a specific problem domain. The various Lisp dialects are good for manipulating symbolic data and complex data structures. Icon and Awk are good for manipulating character strings. C is good for low-level systems programming. Prolog is good for reasoning about logical relationships among data. Each of these languages can be used successfully for a wider range of tasks, but the emphasis is clearly on the specialty.

许多编程语言是为特定的问题领域而设计的。各种Lisp方言适用于操纵符号数据和复杂数据结构。Icon和Awk适用于操纵字符串。C适用于低级系统编程。Prolog适用于推理数据之间的逻辑关系。这些语言都可以成功地用于更广泛的任务,但重点显然在于专业领域。

Personal Preference.

Different people like different things. Much of the parochialism of programming is simply a matter of taste. Some people love the terseness of C; some hate it. Some people find it natural to think recursively; others prefer iteration. Some people like to work with pointers; others prefer the implicit dereferencing of Lisp, Clu, Java, and ML. The strength and variety of personal preference make it unlikely that anyone will ever develop a universally acceptable programming language.

不同的人喜欢不同的东西。编程中的很多偏见只是品味上的问题。有些人喜欢C的简洁性;有些人则讨厌。有些人觉得递归思考很自然;而其他人则更喜欢迭代。有些人喜欢使用指针;其他人则更喜欢Lisp、Clu、Java和ML中隐式解引用的方式。个人偏好的强大和多样性使得几乎不可能有人能够开发出一个被普遍接受的编程语言。

Of course, some languages are more successful than others. Of the many that have been designed, only a few dozen are widely used. What makes a language successful? Again there are several answers:

当然,一些语言比其他语言更成功。在众多被设计出来的语言中,只有几十种被广泛使用。是什么让一种语言成功?这个问题有几个答案:

Expressive Power.

One commonly hears arguments that one language is more “powerful” than another, though in a formal mathematical sense they are all Turing complete—each can be used, if awkwardly, to implement arbitrary algorithms. Still, language features clearly have a huge impact on the programmer’s ability to write clear, concise, and maintainable code, especially for very large systems. There is no comparison, for example, between early versions of Basic on the one hand, and Common Lisp or Ada on the other. The factors that contribute to expressive power—abstraction facilities in particular—are a major focus of this book.

人们经常听到有关一种语言比另一种语言更“强大”的论点,尽管从正式的数学意义上讲,它们都是图灵完备的——每种语言都可以被使用(虽然有时会很笨拙)来实现任意算法。然而,语言特性显然对程序员编写清晰、简洁和易维护的代码能力产生巨大影响,特别是对于非常庞大的系统。例如,早期的Basic与Common Lisp或Ada之间是无法比较的。构成表达能力的因素——尤其是抽象设施——是本书的主要关注点。

Ease of Use for the Novice.

While it is easy to pick on Basic, one cannot deny its success. Part of that success is due to its very low “learning curve.” Logo is popular among elementary-level educators for a similar reason: even a 5-year-old can learn it. Pascal was taught for many years in introductory programming language courses because, at least in comparison to other “serious” languages, it is compact and easy to learn. In recent years Java has come to play a similar role. Though substantially more complex than Pascal, it is much simpler than, say, C++.

虽然批评Basic很容易,但人们无法否认它的成功。它的成功部分归功于其非常低的“学习曲线”。类似的原因,Logo在小学教育者中很受欢迎:甚至5岁的孩子都可以学会。Pascal在很多年里被用来教授入门级编程语言课程,因为至少与其他“严肃”的语言相比,它更为简洁且易学。近年来,Java也开始扮演类似的角色。虽然比Pascal复杂得多,但它比如C++等语言简单得多。

Ease of Implementation.

In addition to its low learning curve, Basic is successful because it could be implemented easily on tiny machines, with limited resources. Forth has a small but dedicated following for similar reasons. Arguably the single most important factor in the success of Pascal was that its designer, Niklaus Wirth, developed a simple, portable implementation of the language, and shipped it free to universities all over the world (see Example 1.15).4 The Java designers took similar steps to make their language available for free to almost anyone who wants it.

除了其低学习曲线之外,Basic之所以成功,还因为它可以轻松在资源有限的小型设备上实现。Forth也因类似的原因拥有一小部分忠实的追随者。可以说,Pascal成功的最重要因素之一是其设计者尼古拉斯·沃斯(Niklaus Wirth)开发了一种简单、可移植的语言实现,并免费提供给全球各地的大学(见示例1.15)。Java的设计者们也采取了类似的措施,让他们的语言几乎可以免费提供给任何想要使用它的人。

Standardization.

Almost every widely used language has an official international standard or (in the case of several scripting languages) a single canonical implementation; and in the latter case the canonical implementation is almost invariably written in a language that has a standard. Standardization—of both the language and a broad set of libraries—is the only truly effective way to ensure the portability of code across platforms. The relatively impoverished standard for Pascal, which is missing several features considered essential by many programmers (separate compilation, strings, static initialization, random-access I/O), is at least partially responsible for the language’s drop from favor in the 1980s. Many of these features were implemented in different ways by different vendors.

几乎每种广泛使用的编程语言都有一个官方的国际标准,或者(在一些脚本语言的情况下)有一个单一的规范实现;而在后一种情况下,规范实现几乎总是用一种有标准的语言编写。标准化——无论是语言本身还是一套广泛的库——是确保代码在各种平台上可移植的唯一真正有效的方法。Pascal的标准相对较为简陋,缺少许多被许多程序员认为是必不可少的功能(如独立编译、字符串、静态初始化、随机访问I/O),这在一定程度上导致了该语言在20世纪80年代失宠。许多这些功能是由不同的供应商以不同的方式实现的。

Open Source.

Most programming languages today have at least one open-source compiler or interpreter, but some languages—C in particular—are much more closely associated than others with freely distributed, peer-reviewed, community-supported computing. C was originally developed in the early 1970s by Dennis Ritchie and Ken Thompson at Bell Labs,5 in conjunction with the design of the original Unix operating system. Over the years Unix evolved into the world’s most portable operating system—the OS of choice for academic computer science—and C was closely associated with it. With the standardization of C, the language has become available on an enormous variety of additional platforms. Linux, the leading open-source operating system, is written in C. As of October 2008, C and its descendants account for 66% of the projects hosted at the sourceforge.net repository.

如今,大多数编程语言至少都有一个开源编译器或解释器,但有些语言——尤其是C语言——与自由分发、同行评审、社区支持的计算密切相关。C语言最初是在20世纪70年代初由贝尔实验室的丹尼斯·里奇(Dennis Ritchie)和肯·汤普逊(Ken Thompson)开发的,同时也是与最初的Unix操作系统的设计相关联的。多年来,Unix发展成为世界上最具可移植性的操作系统——成为学术计算机科学的首选操作系统,并与C语言密切相关。随着C语言的标准化,该语言已经可以在大量额外的平台上使用。领先的开源操作系统Linux就是用C语言编写的。截至2008年10月,在sourceforge.net代码库托管的项目中,C语言及其衍生版本占了66%。

Excellent Compilers.

Fortran owes much of its success to extremely good compilers. In part this is a matter of historical accident. Fortran has been around longer than anything else, and companies have invested huge amounts of time and money in making compilers that generate very fast code. It is also a matter of language design, however: Fortran dialects prior to Fortran 90 lack recursion and pointers, features that greatly complicate the task of generating fast code (at least for programs that can be written in a reasonable fashion without them!). In a similar vein, some languages (e.g., Common Lisp) are successful in part because they have compilers and supporting tools that do an unusually good job of helping the programmer manage very large projects.

Fortran的成功很大程度上归功于非常优秀的编译器。部分原因是历史的偶然性。Fortran的历史比其他任何语言都要悠久,许多公司投入了大量时间和资金来开发能够生成非常高效代码的编译器。然而,这也与语言设计有关:Fortran 90之前的方言缺乏递归和指针,这些特性会极大地复杂化生成高效代码的任务(至少对于可以在不使用它们的情况下以合理方式编写的程序来说是如此!)。类似地,一些语言(例如Common Lisp)之所以成功,部分原因在于它们具有编译器和支持工具,这些工具在帮助程序员管理非常大型项目方面做得异常出色。

Economics, Patronage, and Inertia.

Finally, there are factors other than technical merit that greatly influence success. The backing of a powerful sponsor is one. PL/I, at least to first approximation, owes its life to IBM. Cobol and, more recently, Ada owe their life to the U.S. Department of Defense: Ada contains a wealth of excellent features and ideas, but the sheer complexity of implementation would likely have killed it if not for the DoD backing. Similarly, C#, despite its technical merits, would probably not have received the attention it has without the backing of Microsoft. At the other end of the life cycle, some languages remain widely used long after “better” alternatives are available because of a huge base of installed software and programmer expertise, which would cost too much to replace.

最后,除了技术优势之外,还有其他因素极大地影响着成功。强大赞助商的支持是其中之一。例如,PL/I至少在最初阶段,归功于IBM。Cobol和最近的Ada都归功于美国国防部:Ada包含了大量出色的特性和想法,但如果没有美国国防部的支持,其实现的复杂性很可能会使其难以生存。同样,尽管C#在技术上有其优点,但如果没有微软的支持,它可能不会得到如今的关注。另一方面,一些语言在更好的替代方案出现后仍然被广泛使用,这是因为已安装的软件和程序员的专业知识庞大,替换它们的成本太高。

Clearly no single factor determines whether a language is “good.” As we study programming languages, we shall need to consider issues from several points of view. In particular, we shall need to consider the viewpoints of both the programmer and the language implementor. Sometimes these points of view will be in harmony, as in the desire for execution speed. Often, however, there will be conflicts and tradeoffs, as the conceptual appeal of a feature is balanced against the cost of its implementation. The tradeoff becomes particularly thorny when the implementation imposes costs not only on programs that use the feature, but also on programs that do not.

显然,没有单一因素能决定一种语言是否“优秀”。在研究编程语言时,我们需要从多个角度考虑问题。特别是,我们需要考虑程序员和语言实现者的观点。有时这些观点会保持一致,比如对执行速度的渴望。然而,通常会存在冲突和权衡,比如某项特性的概念吸引力与其实现成本之间的平衡。当实现不仅给使用该特性的程序带来成本,而且也给不使用该特性的程序带来成本时,这种权衡变得特别棘手。

In the early days of computing the implementor’s viewpoint was predominant. Programming languages evolved as a means of telling a computer what to do. For programmers, however, a language is more aptly defined as a means of expressing algorithms. Just as natural languages constrain exposition and discourse, so programming languages constrain what can and cannot easily be expressed, and have both profound and subtle influence over what the programmer can think. Donald Knuth has suggested that programming be regarded as the art of telling another human being what one wants the computer to do [Knu84].6 This definition perhaps strikes the best sort of compromise. It acknowledges that both conceptual clarity and implementation efficiency are fundamental concerns. This book attempts to capture this spirit of compromise,by simultaneously considering the conceptual and implementation aspects of each of the topics it covers.

在计算机的早期发展阶段,实现者的观点占据主导地位。编程语言演变为告诉计算机该做什么的手段。然而,对于程序员来说,语言更恰当地被定义为表达算法的手段。就像自然语言限制了表述和交流一样,编程语言也限制了什么可以和不能轻松地表达,并对程序员的思维产生深远而微妙的影响。Donald Knuth曾建议将编程视为告诉另一个人想让计算机做什么的艺术。这个定义或许达到了最好的折衷。它承认了概念上的清晰和实现效率都是基本关注点。本书试图捕捉这种折衷的精神,同时考虑所涵盖主题的概念和实现方面。

前言

作者的主要观念是关于系统解耦和信息隐藏,接口抽象就是隐藏不必要的细节防止对外暴露系统内的信息。作者提倡一个系统内的逻辑应该是“深”的而不是“宽”的(非常多的对外接口),这样会对外暴露更多的信息。

其余的内容大多是老生常谈的问题,例如如何写好注释。

这本书的另一个优点是行文简单,纯英文阅读很流畅,值得一读。

The most fundamental problem in computer science is problem decomposition: how to take a complex problem and divide it up into pieces that can be solved independently.

Writing computer software is one of the purest creative activities in the history of the human race. Programmers aren’t bound by practical limitations such as the laws of physics; we can create exciting virtual worlds with behaviors that could never exist in the real world.

There are two general approaches to fighting complexity, both of which will be discussed in this book.

The first approach is to eliminate complexity by making code simpler and more obvious.

The second approach to complexity is to encapsulate it, so that programmers can work on a system without being exposed to all of its complexity at once.

复杂性的本质

复杂性定义

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

复杂性的症状

  • Change amplification(变更放大)
  • Cognitive load(认知负担):开发者需要知道多少相关内容才能完成任务。代码长短并不能代表复杂度,更简单的实现方式可以降低认知负担(代码可能更长)
  • Unknown unknowns(不知道还有什么是不知道的):三个之中这个是最差的症状

One of the most important goals of good design is for a system to be obvious.

好的系统应该是显而易见的。

造成复杂性的原因

Complexity is caused by two things: dependencies and obscurity.

复杂度是逐渐递增的

复杂性不是由一个灾难性的错误导致的,而是大量的小块组成。复杂性的渐进性使其难以控制。

结论

复杂性来自依赖和模糊的积累。随着复杂性的增加,会导致变化放大、认知负荷增加以及未知的未知因素。因此,实现每个新功能需要更多的代码修改。此外,开发人员花费更多时间获取足够的信息以确保安全修改,甚至在最糟糕的情况下,他们甚至无法找到所需的所有信息。总之,复杂性使得修改现有代码基础变得困难且风险高。

能跑的代码是不够的(战略和战术编程)

战术编程

在实现新功能或修复bug时只关注让代码跑起来就行。 这是造成系统复杂度的根源。

战略编程

首先需要意识到能work的代码是不够的。为了快速完成当前的任务引入不必要的复杂性是不可接受的。

代价

每次付出开发时间的10%-20%来进行战略编程是合理的。

总结

天下没有免费的午餐。小错误累计会引发大错误。幸运的是,好的设计最终会证明他自己是值得的。

好的模块应该是“深”的

抽象

An abstraction is a simplified view of an entity, which omits unimportant details.

Deep modules

对使用者暴露面越小越好

Classitis(类的炎症)

类不是越小越好,无意义的拆分只会导致额外的复杂度。

总结

通过将模块的接口与其实现分离,我们可以将实现的复杂性对系统的其余部分进行隐藏。模块的用户只需要理解接口提供的抽象。在设计类和其他模块时,最重要的问题是使它们深入,这样它们就具有简单的接口用于常见用例,同时仍然提供重要的功能。这最大程度地隐藏了复杂性的量。

信息隐藏(和泄露)

The most important technique for achieving deep modules is information hiding.

Information hiding reduces complexity in two ways.

First, it simplifies the interface to a module.

Second, information hiding makes it easier to evolve the system.

Temporal decomposition(时空分解)

通过功能执行的时间顺序来涉及代码容易导致信息泄露。

Order usually does matter, so it will be reflected somewhere in the application.

When designing modules, focus on the knowledge that’s needed to perform each task, not the order in which tasks occur.

总结

信息隐藏和深度模块密切相关。如果一个模块隐藏了大量信息,那往往会增加模块提供的功能数量,同时减少其接口。这使得模块更深。相反,如果一个模块没有隐藏太多信息,那么要么它功能不多,要么它的接口复杂;无论哪种情况,该模块都是浅的。在将系统分解为模块时,尽量不要受到运行时操作顺序的影响;这将使您进入时间分解的路径,导致信息泄露和浅层模块。相反,考虑一下执行应用程序任务所需的不同知识片段,并设计每个模块来封装其中的一个或几个知识片段。这将产生一个清晰简洁的设计,其中包含深度模块。

为通用目标设计的模块应该更“深”

通用接口相对于特定接口具有许多优势。它们往往更简单,方法更少但更深入。它们还能在类之间提供更清晰的分离,而特定接口往往会在类之间泄露信息。使您的模块具有一定的通用性是减少整个系统复杂性的最佳途径之一。

One of the most important elements of software design is determining who needs to know what, and when.

何时需要一个更通用的模块?

  • What is the simplest interface that will cover all my current needs?
  • In how many situations will this method be used?
  • Is this API easy to use for my current needs?

不同的应用分层有不同的抽象内容

Pass-through methods(透传的方法)

透传的方法会让模块变“浅”(将下层的方法提供出来,扩大了接口暴露面)。也会让类之间的职责拆分变得模糊。

什么时候重复的接口是ok的?

dispatcher(调度器)模式的时候是ok的。

Decorators(装饰器模式)

Decorator classes often contain many pass-through methods.

Sometimes decorators make sense, but there is usually a better alternative.

Pass-through variables

使用context(上下文)来代替透传变量。

总结

每个添加到系统中的设计基础设施,比如接口、参数、函数、类或定义,都会增加复杂性,因为开发人员必须了解这个元素。为了使一个元素对抗复杂性产生净增益,它必须消除一些在设计元素缺失时会存在的复杂性。否则,最好不使用该特定元素来实现系统。例如,一个类可以通过封装功能来减少复杂性,这样类的使用者就不需要知道这些细节。

“不同层次,不同抽象”的规则只是这个想法的一种应用:如果不同层次具有相同的抽象,比如传递方法或装饰者,那么它们很可能没有提供足够的好处来补偿它们所代表的额外基础设施。同样,传递参数要求每个方法都意识到它们的存在(增加了复杂性),而并没有提供额外的功能。

Pull Complexity Downwards(复杂度下放)

在开发模块时,要寻找机会多承担一些额外的困难,以减少用户的困难。

it is more important for a module to have a simple interface than a simple implementation.

放在一起更好还是分开?

  • Bring together if information is shared
  • Bring together if it will simplify the interface
  • Bring together to eliminate duplication
  • Separate general-purpose and special-purpose code

Each method should do one thing and do it completely.

Define Errors Out Of Existence(通过定义来消除错误)

为什么异常会增加复杂度

错误处理会链式传递额外的信息。

消除异常处理复杂性的最佳方法是定义您的API,使其不产生需要处理的异常:通过定义消除错误存在的可能性。

ps: Linux设计哲学:没事的时候别乱报错。

classes with lots of exceptions have complex interfaces, and they are shallower than classes with fewer exceptions.

reduce the number of places where exceptions have to be handled.

Just crash

fail fast机制。

Design it Twice(设计两次)

The design-it-twice approach not only improves your designs, but it also improves your design skills. The process of devising and comparing multiple approaches will teach you about the factors that make designs better or worse. Over time, this will make it easier for you to rule out bad designs and hone in on really great ones.

Why Write Comments? The Four Excuses

一次击破不写注释的四个借口:

Good code is self-documenting.

接口文档是必须的,描述接口的功能和提供一些示例

If users must read the code of a method in order to use it, then there is no abstraction: all of the complexity of the method is exposed.

I don’t have time to write comments

注释先行,理清思路。

Comments get out of date and become misleading

Code reviews的重要性。 AI生成文档也是一条路。

All the comments I have seen are worthless

keep yourself simple and stupid.

后面几章都是对注释的啰嗦就不细写了。

  • Comments Should Describe Things that Aren’t Obvious from the Code
  • Choosing Names
  • Write The Comments First

一致性(减少心智负担和增加团队规范)

一致性是投资思维的另一个例子。确保一致性需要额外的一些工作:需要努力确定惯例,创建自动检查器,寻找类似情况以在新代码中模仿,并在代码审查中进行团队教育。这项投资的回报是,您的代码将更加明显。开发人员将能够更快速、更准确地理解代码的行为,这将使他们能够更快地工作,减少错误。

代码应该是显而易见的

从信息角度来考虑明显性的另一种方式是,如果代码不明显,通常意味着读者缺乏关于代码的重要信息:在 RaftClient 示例中,读者可能不知道 RaftClient 构造函数创建了新的线程;在 Pair 示例中,读者可能不知道 result.getKey() 返回当前期数的数字。

要使代码明显,您必须确保读者始终拥有理解代码所需的信息。您可以通过三种方式实现这一点。最好的方式是减少所需信息的量,使用抽象和消除特殊情况等设计技术。其次,您可以利用读者在其他情境中已经获得的信息(例如,遵循惯例和符合期望),这样读者就不必为了理解您的代码而学习新的信息。第三,您可以在代码中向他们呈现重要信息,使用良好的命名和战略性注释等技术。

总结

本书讨论的是一个问题:复杂性。处理复杂性是软件设计中最重要的挑战。它是导致系统难以构建和维护的原因,而且通常也会使系统变得缓慢。在本书中,我试图描述导致复杂性的根本原因,如依赖性和晦涩性。我讨论了可以帮助您识别不必要复杂性的红旗,例如信息泄露、不必要的错误条件或过于通用的名称。我提出了一些通用的思路,可以用来创建更简单的软件系统,比如努力使类深入且通用,将错误定义为不存在,并将接口文档与实现文档分开。最后,我讨论了产生简单设计所需的投资思维。

所有这些建议的缺点在于它们会在项目的早期阶段增加额外的工作量。此外,如果您不习惯思考设计问题,那么在学习良好的设计技术时您会变得更加缓慢。如果对您来说唯一重要的是尽快让您当前的代码运行起来,那么思考设计将会显得像是妨碍您真正目标的苦差事。

另一方面,如果良好的设计对您来说是一个重要目标,那么本书中的理念应该会让编程变得更有趣。设计是一个迷人的谜题:如何用最简单的结构解决特定的问题?探索不同的方法是很有趣的,而且发现既简单又强大的解决方案是一种很棒的感觉。一个清晰、简单和明显的设计是一件美妙的事情。

此外,您在良好设计上所做的投资将很快得到回报。在项目开始阶段精心定义的模块将在以后反复重用时节省您的时间。您六个月前编写的清晰文档将在您返回代码以添加新功能时为您节省时间。您花在磨练设计技能上的时间也将得到回报:随着您的技能和经验的增长,您会发现自己能够越来越快地产生良好的设计。一旦掌握了技巧,良好的设计实际上并不比草率设计花费更多时间。

成为一个优秀的设计师的回报是,您可以将更多的时间花在有趣的设计阶段。糟糕的设计师大部分时间都在追踪复杂而脆弱的代码中的错误。如果您提高了自己的设计技能,不仅能更快地生产出更高质量的软件,而且软件开发过程也会更加愉快。

Red Flag(坏味道)

Shallow Module

A shallow module is one whose interface is complicated relative to the functionality it provides. Shallow modules don’t help much in the battle against complexity, because the benefit they provide (not having to learn about how they work internally) is negated by the cost of learning and using their interfaces. Small modules tend to be shallow.

Information Leakage

Information leakage occurs when the same knowledge is used in multiple places, such as two different classes that both understand the format of a particular type of file.

Temporal Decomposition

In temporal decomposition, execution order is reflected in the code structure: operations that happen at different times are in different methods or classes. If the same knowledge is used at different points in execution, it gets encoded in multiple places, resulting in information leakage.

Overexposure

If the API for a commonly used feature forces users to learn about other features that are rarely used, this increases the cognitive load on users who don’t need the rarely used features.

Repetition

If the same piece of code (or code that is almost the same) appears over and over again, that’s a red flag that you haven’t found the right abstractions.

Special-General Mixture

This red flag occurs when a general-purpose mechanism also contains code specialized for a particular use of that mechanism. This makes the mechanism more complicated and creates information leakage between the mechanism and the particular use case: future modifications to the use case are likely to require changes to the underlying mechanism as well.

Conjoined Methods

It should be possible to understand each method independently. If you can’t understand the implementation of one method without also understanding the implementation of another, that’s a red flag. This red flag can occur in other contexts as well: if two pieces of code are physically separated, but each can only be understood by looking at the other, that is a red flag.

Nonobvious Code

If the meaning and behavior of code cannot be understood with a quick reading, it is a red flag. Often this means that there is important information that is not immediately clear to someone reading the code.

ask: 如何使用模板方法重构下面的代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public void exportOrder(OrderQueryDTO queryDTO, HttpServletResponse response) {
ExcelWriter excelWriter = EasyExcel.write(EasyExcelUtil.getOutputStream("订单导出", response)).build();

WriteSheet writeSheet = EasyExcel.writerSheet(1, "订单明细")
.head(OrderExportVO.class).build();
WriteSheet writeSheet2 = EasyExcel.writerSheet(2, "订单商品明细")
.head(OrderGoodsExportVO.class).build();

PageDto pageDto = new PageDto(1, 1000, false);
while (true) {
IPage<Order> page = this.page(setPage(pageDto), getLQW(queryDTO));
List<Order> records = page.getRecords();
List<OrderExportVO> exports = setUpOrderExportVO(records);

List<OrderGoodsExportVO> orderGoodsExports = setUpOrderGoodsExportExportVO(records);

excelWriter.write(exports, writeSheet);
excelWriter.write(orderGoodsExports, writeSheet2);

if (page.getCurrent() >= page.getPages()) {
break;
}
pageDto.setPage(pageDto.getPage() + 1);
}
excelWriter.finish();
}

answer:

这里的模板方法模式可以用来将导出过程的骨架定义在一个抽象类中,然后通过子类来实现特定的步骤。这样可以让代码更加清晰和可扩展。

首先,我们创建一个ExportStep抽象类,定义导出过程的骨架:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public abstract class ExportStep {
protected ExcelWriter excelWriter;
protected WriteSheet writeSheet;

public ExportStep(ExcelWriter excelWriter, String sheetName, Class<?> clazz) {
this.excelWriter = excelWriter;
this.writeSheet = EasyExcel.writerSheet(sheetName).head(clazz).build();
}

public abstract List<?> setupExportData(List<Order> records);

public void writeData(List<Order> records) {
List<?> data = setupExportData(records);
excelWriter.write(data, writeSheet);
}
}

然后,我们创建具体的导出类,实现特定的步骤:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class OrderExportStep extends ExportStep {
public OrderExportStep(ExcelWriter excelWriter) {
super(excelWriter, "订单明细", OrderExportVO.class);
}

@Override
public List<OrderExportVO> setupExportData(List<Order> records) {
return setUpOrderExportVO(records);
}
}

public class OrderGoodsExportStep extends ExportStep {
public OrderGoodsExportStep(ExcelWriter excelWriter) {
super(excelWriter, "订单商品明细", OrderGoodsExportVO.class);
}

@Override
public List<OrderGoodsExportVO> setupExportData(List<Order> records) {
return setUpOrderGoodsExportExportVO(records);
}
}

最后,在主方法中使用具体的导出类来进行导出:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public void exportOrder(OrderQueryDTO queryDTO, HttpServletResponse response) {
ExcelWriter excelWriter = EasyExcel.write(EasyExcelUtil.getOutputStream("订单导出", response)).build();

ExportStep[] steps = new ExportStep[] {
new OrderExportStep(excelWriter),
new OrderGoodsExportStep(excelWriter)
};

PageDto pageDto = new PageDto(1, 1000, false);
while (true) {
IPage<Order> page = this.page(setPage(pageDto), getLQW(queryDTO));
List<Order> records = page.getRecords();

for (ExportStep step : steps) {
step.writeData(records);
}

if (page.getCurrent() >= page.getPages()) {
break;
}
pageDto.setPage(pageDto.getPage() + 1);
}
excelWriter.finish();
}

这样,我们就使用模板方法模式重构了这段代码,使得代码更加清晰和可扩展。

ask: 可以把上述代码中的while循环改成迭代器模式吗

answer:

是的,我们可以使用迭代器模式来改造这个while循环。迭代器模式提供了一种方法访问一个容器对象中各个元素,而又不暴露该对象的内部细节。

首先,我们需要创建一个迭代器:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class OrderIterator implements Iterator<List<Order>> {
private final OrderService orderService;
private final OrderQueryDTO queryDTO;
private final PageDto pageDto;
private IPage<Order> currentPage;

public OrderIterator(OrderService orderService, OrderQueryDTO queryDTO, PageDto pageDto) {
this.orderService = orderService;
this.queryDTO = queryDTO;
this.pageDto = pageDto;
this.currentPage = orderService.page(setPage(pageDto), getLQW(queryDTO));
}

@Override
public boolean hasNext() {
return currentPage.getCurrent() < currentPage.getPages();
}

@Override
public List<Order> next() {
List<Order> records = currentPage.getRecords();
pageDto.setPage(pageDto.getPage() + 1);
this.currentPage = orderService.page(setPage(pageDto), getLQW(queryDTO));
return records;
}
}

然后,我们在exportOrder方法中使用OrderIterator

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public void exportOrder(OrderQueryDTO queryDTO, HttpServletResponse response) {
ExcelWriter excelWriter = EasyExcel.write(EasyExcelUtil.getOutputStream("订单导出", response)).build();

ExportStep[] steps = new ExportStep[] {
new OrderExportStep(excelWriter),
new OrderGoodsExportStep(excelWriter)
};

OrderIterator orderIterator = new OrderIterator(this, queryDTO, new PageDto(1, 1000, false));
while (orderIterator.hasNext()) {
List<Order> records = orderIterator.next();

for (ExportStep step : steps) {
step.writeData(records);
}
}
excelWriter.finish();
}

这样,我们就使用迭代器模式重构了这段代码,使得代码更加清晰和可扩展。

ask: 可以将上述代码的ExportStep改用责任链模式重构吗

answer:

当然可以。责任链模式(Chain of Responsibility Pattern)是一种设计模式,其中对象的接收者形成一个链,并沿着这个链传递请求,直到一个对象处理它为止。这使得多个对象都有机会处理请求。

首先,我们需要修改ExportStep类,让它能够引用下一个ExportStep

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public abstract class ExportStep {
protected ExcelWriter excelWriter;
protected WriteSheet writeSheet;
protected ExportStep nextStep;

public ExportStep(ExcelWriter excelWriter, String sheetName, Class<?> clazz) {
this.excelWriter = excelWriter;
this.writeSheet = EasyExcel.writerSheet(sheetName).head(clazz).build();
}

public abstract List<?> setupExportData(List<Order> records);

public void writeData(List<Order> records) {
List<?> data = setupExportData(records);
excelWriter.write(data, writeSheet);
if (nextStep != null) {
nextStep.writeData(records);
}
}

public void setNextStep(ExportStep nextStep) {
this.nextStep = nextStep;
}
}

然后,我们在主方法中使用责任链模式:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public void exportOrder(OrderQueryDTO queryDTO, HttpServletResponse response) {
ExcelWriter excelWriter = EasyExcel.write(EasyExcelUtil.getOutputStream("订单导出", response)).build();

ExportStep orderExportStep = new OrderExportStep(excelWriter);
ExportStep orderGoodsExportStep = new OrderGoodsExportStep(excelWriter);
orderExportStep.setNextStep(orderGoodsExportStep);

OrderIterator orderIterator = new OrderIterator(this, queryDTO, new PageDto(1, 1000, false));
while (orderIterator.hasNext()) {
List<Order> records = orderIterator.next();
orderExportStep.writeData(records);
}
excelWriter.finish();
}

这样,我们就使用责任链模式重构了这段代码,使得代码更加清晰和可扩展。

0%