引言

北京中鼎项目用到了 .NET 的依赖注入框架，借此机会了解了控制反转等设计理念，追溯到 Martin Fowler 的这篇 Inversion of Control Containers and the Dependency Injection pattern，特作此博文研读。

One of the entertaining things about the enterprise Java world is the huge amount of activity in building alternatives to the mainstream J2EE technologies, much of it happening in open source. A lot of this is a reaction to the heavyweight complexity in the mainstream J2EE world, but much of it is also exploring alternatives and coming up with creative ideas. A common issue to deal with is how to wire together different elements: how do you fit together this web controller architecture with that database interface backing when they were built by different teams with little knowledge of each other. A number of frameworks have taken a stab at this problem, and several are branching out to provide a general capability to assemble components from different layers. These are often referred to as lightweight containers, examples include PicoContainer, and Spring.

Java 社群近来掀起了一阵轻量级容器的热潮，这些容器能够帮助开发者将来自不同项目的组件组装成为一个内聚的应用程序。在它们的背后有着同一个模式，这个模式决定了这些容器进行组件装配的方式。人们用一个大而化之的名字来称呼这个模式：“控制反转”（Inversion of Control，IoC）。在本文中，我将深入探索这个模式的工作原理，给它一个更能描述其特点的名字——“依赖注入”（Dependency Injection），并将其与“服务定位器”（Service Locator）模式作一个比较。不过，这两者之间的差异并不太重要，更重要的是：应该将组件的配置与使用分离开——两个模式的目标都是这个。

在企业级 Java 的世界里存在一个有趣的现象：有很多人投入很多精力来研究主流 J2EE 技术的替代品——自然，这大多发生在开源社群。在很大程度上，这可以看作是开发者对主流 J2EE 技术的笨重和复杂作出的回应，但其中的确有很多极富创意的想法，的确提供了一些可供选择的方案。J2EE 开发者常遇到的一个问题就是如何组装不同的程序元素：如果 web 控制器体系结构和数据库接口是由不同的团队所开发的，彼此几乎一无所知，你应该如何让它们配合工作？很多框架尝试过解决这个问题，有几个框架索性朝这个方向发展，提供了更通用的“组装各层组件”的方案。这样的框架通常被称为“轻量级容器”，PicoContainer 和 Spring 都在此列中。

Underlying these containers are a number of interesting design principles, things that go beyond both these specific containers and indeed the Java platform. Here I want to start exploring some of these principles. The examples I use are in Java, but like most of my writing the principles are equally applicable to other OO environments, particularly .NET.

在这些容器背后，一些有趣的设计原则发挥着作用。这些原则已经超越了特定容器的范畴，甚至已经超越了 Java 平台的范畴。在本文中，我就要初步揭示这些原则。我使用的范例是 Java 代码，但正如我的大多数文章一样，这些原则也同样适用于别的 OO 环境，特别是.NET。

组件服务 Components and Services

The topic of wiring elements together drags me almost immediately into the knotty terminology problems that surround the terms service and component. You find long and contradictory articles on the definition of these things with ease. For my purposes here are my current uses of these overloaded terms.

“装配程序元素”，这样的话题立即将我拖进了一个棘手的术语问题：如何区分“服务”（service）和“组件”（component）？你可以毫不费力地找出关于这两个词定义的长篇大论，各种彼此矛盾的定义会让你感受到我所处的窘境。有鉴于此，对于这两个遭到了严重滥用的词汇，我将首先说明它们在本文中的用法。

I use component to mean a glob of software that’s intended to be used, without change, by an application that is out of the control of the writers of the component. By ‘without change’ I mean that the using application doesn’t change the source code of the components, although they may alter the component’s behavior by extending it in ways allowed by the component writers.

所谓“组件”是指这样一个软件单元：它将被作者无法控制的其他应用程序使用，但后者不能对组件进行修改。也就是说，使用一个组件的应用程序不能修改组件的源代码，但可以通过作者预留的某种途径对其进行扩展，以改变组件的行为。

A service is similar to a component in that it’s used by foreign applications. The main difference is that I expect a component to be used locally (think jar file, assembly, dll, or a source import). A service will be used remotely through some remote interface, either synchronous or asynchronous (eg web service, messaging system, RPC, or socket.)

服务和组件有某种相似之处：它们都将被外部的应用程序使用。在我看来，两者之间最大的差异在于：组件是在本地使用的（例如 JAR 文件、程序集、DLL、或者源码导入）；而服务是要通过——同步或异步的——远程接口来远程使用的（例如 web service、消息系统、RPC，或者 socket）。

I mostly use service in this article, but much of the same logic can be applied to local components too. Indeed often you need some kind of local component framework to easily access a remote service. But writing “component or service” is tiring to read and write, and services are much more fashionable at the moment.

在本文中，我将主要使用“服务”这个词，但文中的大多数逻辑也同样适用于本地组件。实际上，为了方便地访问远程服务，你往往需要某种本地组件框架。不过，“组件或者服务”这样一个词组实在太麻烦了，而且“服务”这个词当下也很流行，所以本文将用“服务”指代这两者。

一个简单的例子 A Naive Example

To help make all of this more concrete I’ll use a running example to talk about all of this. Like all of my examples it’s one of those super-simple examples; small enough to be unreal, but hopefully enough for you to visualize what’s going on without falling into the bog of a real example.

In this example I’m writing a component that provides a list of movies directed by a particular director. This stunningly useful function is implemented by a single method.

为了更好地说明问题，我要引入一个例子。和我以前用的所有例子一样，这是一个超级简单的例子：它非常小，小得有点不够真实，但足以帮助你看清其中的道理，而不至于陷入真实例子的泥潭中无法自拔。

在这个例子中，我编写了一个组件，用于提供一份电影清单，清单上列出的影片都是由一位特定的导演执导的。实现这个伟大的功能只需要一个方法：

class MovieLister...

  public Movie[] moviesDirectedBy(String arg) {
      List allMovies = finder.findAll();
      for (Iterator it = allMovies.iterator(); it.hasNext();) {
          Movie movie = (Movie) it.next();
          if (!movie.getDirector().equals(arg)) it.remove();
      }
      return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);
  }

The implementation of this function is naive in the extreme, it asks a finder object (which we’ll get to in a moment) to return every film it knows about. Then it just hunts through this list to return those directed by a particular director. This particular piece of naivety I’m not going to fix, since it’s just the scaffolding for the real point of this article.

你可以看到，这个功能的实现极其简单：moviesDirectedBy 方法首先请求 finder（影片搜寻者）对象（我们稍后会谈到这个对象）返回后者所知道的所有影片，然后遍历 finder 对象返回的清单，并返回其中由特定的某个导演执导的影片。非常简单，不过不必担心，这只是整个例子的脚手架罢了。

The real point of this article is this finder object, or particularly how we connect the lister object with a particular finder object. The reason why this is interesting is that I want my wonderful moviesDirectedBy method to be completely independent of how all the movies are being stored. So all the method does is refer to a finder, and all that finder does is know how to respond to the findAll method. I can bring this out by defining an interface for the finder.

我们真正想要考察的是 finder 对象，或者说，如何将 MovieLister 对象与特定的 finder 对象连接起来。为什么我们对这个问题特别感兴趣？因为我希望上面这个漂亮的 moviesDirectedBy 方法完全不依赖于影片的实际存储方式。所以，这个方法只能引用一个 finder 对象，而 finder 对象则必须知道如何对 findAll 方法作出回应。为了帮助读者更清楚地理解，我给 finder 定义了一个接口：

public interface MovieFinder {
    List findAll();
}

Now all of this is very well decoupled, but at some point I have to come up with a concrete class to actually come up with the movies. In this case I put the code for this in the constructor of my lister class.

现在，两个对象之间没有什么耦合关系。但是，当我要实际寻找影片时，就必须涉及到 MovieFinder 的某个具体子类。在这里，我把“涉及具体子类”的代码放在 MovieLister 类的构造子中。

class MovieLister...

  private MovieFinder finder;
  public MovieLister() {
    finder = new ColonDelimitedMovieFinder("movies1.txt");
  }

The name of the implementation class comes from the fact that I’m getting my list from a colon delimited text file. I’ll spare you the details, after all the point is just that there’s some implementation.

这个实现类的名字就说明：我将要从一个逗号分隔的文本文件中获得影片列表。你不必操心具体的实现细节，只要设想这样一个实现类就可以了。

Now if I’m using this class for just myself, this is all fine and dandy. But what happens when my friends are overwhelmed by a desire for this wonderful functionality and would like a copy of my program? If they also store their movie listings in a colon delimited text file called “movies1.txt” then everything is wonderful. If they have a different name for their movies file, then it’s easy to put the name of the file in a properties file. But what if they have a completely different form of storing their movie listing: a SQL database, an XML file, a web service, or just another format of text file? In this case we need a different class to grab that data. Now because I’ve defined a MovieFinder interface, this won’t alter my moviesDirectedBy method. But I still need to have some way to get an instance of the right finder implementation into place.

如果这个类只由我自己使用，一切都没问题。但是，如果我的朋友叹服于这个精彩的功能，也想使用我的程序，那又会怎么样呢？如果他们也把影片清单保存在一个逗号分隔的文本文件中，并且也把这个文件命名为“ movie1.txt”，那么一切还是没问题。如果他们只是给这个文件改改名，我也可以从一个配置文件获得文件名，这也很容易。但是，如果他们用完全不同的方式——例如 SQL 数据库、XML 文件、web service，或者另一种格式的文本文件——来存储影片清单呢？在这种情况下，我们需要用另一个类来获取数据。由于已经定义了 MovieFinder 接口，我可以不用修改 moviesDirectedBy 方法。但是，我仍然需要通过某种途径获得合适的 MovieFinder 实现类的实例。

Figure 1 shows the dependencies for this situation. The MovieLister class is dependent on both the MovieFinder interface and upon the implementation. We would prefer it if it were only dependent on the interface, but then how do we make an instance to work with?

图 1 展现了这种情况下的依赖关系：MovieLister 类既依赖于 MovieFinder 接口，也依赖于具体的实现类。我们当然希望 MovieLister 类只依赖于接口，但我们要如何获得一个 MovieFinder 子类的实例呢？

In my book P of EAA, we described this situation as a Plugin. The implementation class for the finder isn’t linked into the program at compile time, since I don’t know what my friends are going to use. Instead we want my lister to work with any implementation, and for that implementation to be plugged in at some later point, out of my hands. The problem is how can I make that link so that my lister class is ignorant of the implementation class, but can still talk to an instance to do its work.

在 Patterns of Enterprise Application Architecture 一书中，我们把这种情况称为“插件”（plugin）：MovieFinder的实现类不是在编译期连入程序之中的，因为我并不知道我的朋友会使用哪个实现类。我们希望 MovieLister 类能够与 MovieFinder 的任何实现类配合工作，并且允许在运行期插入具体的实现类，插入动作完全脱离我（原作者）的控制。这里的问题就是：如何设计这个连接过程，使 MovieLister 类在不知道实现类细节的前提下与其实例协同工作。

Expanding this into a real system, we might have dozens of such services and components. In each case we can abstract our use of these components by talking to them through an interface (and using an adapter if the component isn’t designed with an interface in mind). But if we wish to deploy this system in different ways, we need to use plugins to handle the interaction with these services so we can use different implementations in different deployments.

将这个例子推而广之，在一个真实的系统中，我们可能有数十个服务和组件。在任何时候，我们总可以对使用组件的情形加以抽象，通过接口与具体的组件交流（如果组件并没有设计一个接口，也可以通过适配器与之交流）。但是，如果我们希望以不同的方式部署这个系统，就需要用插件机制来处理服务之间的交互过程，这样我们才可能在不同的部署方案中使用不同的实现。

So the core problem is how do we assemble these plugins into an application? This is one of the main problems that this new breed of lightweight containers face, and universally they all do it using Inversion of Control.

所以，现在的核心问题就是：如何将这些插件组合成一个应用程序？这正是新生的轻量级容器所面临的主要问题，而它们解决这个问题的手段无一例外地是控制反转（Inversion of Control）模式。

控制反转 Inversion of Control

When these containers talk about how they are so useful because they implement “Inversion of Control” I end up very puzzled. Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels.

几位轻量级容器的作者曾骄傲地对我说：这些容器非常有用，因为它们实现了“控制反转”。这样的说辞让我深感迷惑：控制反转是框架所共有的特征，如果仅仅因为使用了控制反转就认为这些轻量级容器与众不同，就好象在说“我的轿车是与众不同的，因为它有四个轮子”。

The question is: “what aspect of control are they inverting?” When I first ran into inversion of control, it was in the main control of a user interface. Early user interfaces were controlled by the application program. You would have a sequence of commands like “Enter name”, “enter address”; your program would drive the prompts and pick up a response to each one. With graphical (or even screen based) UIs the UI framework would contain this main loop and your program instead provided event handlers for the various fields on the screen. The main control of the program was inverted, moved away from you to the framework.

问题的关键在于：它们反转了哪方面的控制？我第一次接触到的控制反转针对的是用户界面的主控权。早期的用户界面是完全由应用程序来控制的，你预先设计一系列命令，例如“输入姓名”、“输入地址”等，应用程序逐条输出提示信息，并取回用户的响应。而在图形用户界面环境下，UI 框架将负责执行一个主循环，你的应用程序只需为屏幕的各个区域提供事件处理函数即可。在这里，程序的主控权发生了反转：从应用程序移到了框架。

For this new breed of containers the inversion is about how they lookup a plugin implementation. In my naive example the lister looked up the finder implementation by directly instantiating it. This stops the finder from being a plugin. The approach that these containers use is to ensure that any user of a plugin follows some convention that allows a separate assembler module to inject the implementation into the lister.

对于这些新生的容器，它们反转的是“如何定位插件的具体实现”。在前面那个简单的例子中，MovieLister 类负责定位 MovieFinder 的具体实现——它直接实例化后者的一个子类。这样一来，MovieFinder 也就不成其为一个插件了，因为它并不是在运行期插入应用程序中的。而这些轻量级容器则使用了更为灵活的办法，只要插件遵循一定的规则，一个独立的组装模块就能够将插件的具体实现“注射”到应用程序中。

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

因此，我想我们需要给这个模式起一个更能说明其特点的名字——“控制反转”这个名字太泛了，常常让人有些迷惑。与多位 IoC 爱好者讨论之后，我们决定将这个模式叫做“依赖注入” （Dependency Injection）。

I’m going to start by talking about the various forms of dependency injection, but I’ll point out now that that’s not the only way of removing the dependency from the application class to the plugin implementation. The other pattern you can use to do this is Service Locator, and I’ll discuss that after I’m done with explaining Dependency Injection.

下面，我将开始介绍 Dependency Injection 模式的几种不同形式。不过，在此之前，我要首先指出：要消除应用程序对插件实现的依赖，依赖注入并不是唯一的选择，你也可以用 Service Locator 模式获得同样的效果。介绍完 Dependency Injection 模式之后，我也会谈到 Service Locator 模式。

依赖注入的几种形式 Forms of Dependency Injection

The basic idea of the Dependency Injection is to have a separate object, an assembler, that populates a field in the lister class with an appropriate implementation for the finder interface, resulting in a dependency diagram along the lines of Figure 2

Dependency Injection 模式的基本思想是：用一个单独的对象（装配器）来获得 MovieFinder 的一个合适的实现，并将其实例赋给 MovieLister 类的一个字段。这样一来，我们就得到了图2所示的依赖图：

依赖注入的形式主要有三种，我分别将它们叫做构造子注入（Constructor Injection）、设值方法注入（Setter Injection）和接口注入（Interface Injection）。如果读过最近关于 IoC 的一些讨论材料，你不难看出：这三种注入形式分别就是 type 1 IoC（接口注入）、type 2 IoC（设值方法注入）和 type 3 IoC（构造子注入）。我发现数字编号往往比较难记，所以我使用了这里的命名方式。

使用 PicoContainer 进行构造子注入

I’ll start with showing how this injection is done using a lightweight container called PicoContainer. I’m starting here primarily because several of my colleagues at Thoughtworks are very active in the development of PicoContainer (yes, it’s a sort of corporate nepotism.)

首先，我要向读者展示如何用一个名为 PicoContainer 的轻量级容器完成依赖注入。之所以从这里开始，主要是因为我在 ThoughtWorks 公司的几个同事在 PicoContainer 的开发社群中非常活跃——没错，也可以说是某种偏袒吧。

PicoContainer uses a constructor to decide how to inject a finder implementation into the lister class. For this to work, the movie lister class needs to declare a constructor that includes everything it needs injected.

PicoContainer 通过构造子来判断“如何将 MovieFinder 实例注入 MovieLister 类”。因此，MovieLister 类必须声明一个构造子，并在其中包含所有需要注入的元素：

class MovieLister...

  public MovieLister(MovieFinder finder) {
      this.finder = finder;       
  }

The finder itself will also be managed by the pico container, and as such will have the filename of the text file injected into it by the container.

MovieFinder 实例本身也将由 PicoContainer 来管理，因此文本文件的名字也可以由容器注入：

class ColonMovieFinder...

  public ColonMovieFinder(String filename) {
      this.filename = filename;
  }

The pico container then needs to be told which implementation class to associate with each interface, and which string to inject into the finder.

随后，需要告诉 PicoContainer：各个接口分别与哪个实现类关联、将哪个字符串注入 MovieFinder 组件。

private MutablePicoContainer configureContainer() {
    MutablePicoContainer pico = new DefaultPicoContainer();
    Parameter[] finderParams =  {new ConstantParameter("movies1.txt")};
    pico.registerComponentImplementation(MovieFinder.class, ColonMovieFinder.class, finderParams);
    pico.registerComponentImplementation(MovieLister.class);
    return pico;
}

This configuration code is typically set up in a different class. For our example, each friend who uses my lister might write the appropriate configuration code in some setup class of their own. Of course it’s common to hold this kind of configuration information in separate config files. You can write a class to read a config file and set up the container appropriately. Although PicoContainer doesn’t contain this functionality itself, there is a closely related project called NanoContainer that provides the appropriate wrappers to allow you to have XML configuration files. Such a nano container will parse the XML and then configure an underlying pico container. The philosophy of the project is to separate the config file format from the underlying mechanism.

这段配置代码通常位于另一个类。对于我们这个例子，使用我的 MovieLister 类的朋友需要在自己的设置类中编写合适的配置代码。当然，还可以将这些配置信息放在一个单独的配置文件中，这也是一种常见的做法。你可以编写一个类来读取配置文件，然后对容器进行合适的设置。尽管 PicoContainer 本身并不包含这项功能，但另一个与它关系紧密的项目 NanoContainer 提供了一些包装，允许开发者使用 XML 配置文件保存配置信息。NanoContainer 能够解析 XML 文件，并对底下的 PicoContainer 进行配置。这个项目的哲学观念就是：将配置文件的格式与底下的配置机制分离开。

To use the container you write code something like this.

使用这个容器，你写出的代码大概会是这样：

public void testWithPico() {
    MutablePicoContainer pico = configureContainer();
    MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
    Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
    assertEquals("Once Upon a Time in the West", movies[0].getTitle());
}

Although in this example I’ve used constructor injection, PicoContainer also supports setter injection, although its developers do prefer constructor injection.

尽管在这里我使用了构造子注入，实际上 PicoContainer 也支持设值方法注入，不过该项目的开发者更推荐使用构造子注入。

使用 Spring 进行设值方法注入

The Spring framework is a wide ranging framework for enterprise Java development. It includes abstraction layers for transactions, persistence frameworks, web application development and JDBC. Like PicoContainer it supports both constructor and setter injection, but its developers tend to prefer setter injection - which makes it an appropriate choice for this example.

Spring 框架是一个用途广泛的企业级 Java 开发框架，其中包括了针对事务、持久化框架、web 应用开发和 JDBC 等常用功能的抽象。和 PicoContainer 一样，它也同时支持构造子注入和设值方法注入，但该项目的开发者更推荐使用设值方法注入——恰好适合这个例子。

To get my movie lister to accept the injection I define a setting method for that service

为了让 MovieLister 类接受注入，我需要为它定义一个设值方法，该方法接受类型为 MovieFinder 的参数：

class MovieLister...

  private MovieFinder finder;
public void setFinder(MovieFinder finder) {
  this.finder = finder;
}

Similarly I define a setter for the filename.

类似地，在 MovieFinder 的实现类中，我也定义了一个设值方法，接受类型为 String 的参数：

class ColonMovieFinder...

  public void setFilename(String filename) {
      this.filename = filename;
  }

The third step is to set up the configuration for the files. Spring supports configuration through XML files and also through code, but XML is the expected way to do it.

第三步是设定配置文件。Spring 支持多种配置方式，你可以通过 XML 文件进行配置，也可以直接在代码中配置。不过，XML 文件是比较理想的配置方式。

<beans>
    <bean id="MovieLister" class="spring.MovieLister">
        <property name="finder">
            <ref local="MovieFinder"/>
        </property>
    </bean>
    <bean id="MovieFinder" class="spring.ColonMovieFinder">
        <property name="filename">
            <value>movies1.txt</value>
        </property>
    </bean>
</beans>

The test then looks like this.

于是，测试代码大概就像下面这样：

public void testWithSpring() throws Exception {
    ApplicationContext ctx = new FileSystemXmlApplicationContext("spring.xml");
    MovieLister lister = (MovieLister) ctx.getBean("MovieLister");
    Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
    assertEquals("Once Upon a Time in the West", movies[0].getTitle());
}

接口注入

The third injection technique is to define and use interfaces for the injection. Avalon is an example of a framework that uses this technique in places. I’ll talk a bit more about that later, but in this case I’m going to use it with some simple sample code.

除了前面两种注入技术，还可以在接口中定义需要注入的信息，并通过接口完成注入。Avalon 框架就使用了类似的技术。在这里，我首先用简单的范例代码说明它的用法，后面还会有更深入的讨论。

With this technique I begin by defining an interface that I’ll use to perform the injection through. Here’s the interface for injecting a movie finder into an object.

首先，我需要定义一个接口，组件的注入将通过这个接口进行。在本例中，这个接口的用途是将一个 MovieFinder 实例注入继承了该接口的对象。

public interface InjectFinder {
    void injectFinder(MovieFinder finder);
}

This interface would be defined by whoever provides the MovieFinder interface. It needs to be implemented by any class that wants to use a finder, such as the lister.

这个接口应该由提供 MovieFinder 接口的人一并提供。任何想要使用 MovieFinder 实例的类（例如 MovieLister 类）都必须实现这个接口。

class MovieLister implements InjectFinder

  public void injectFinder(MovieFinder finder) {
      this.finder = finder;
  }

I use a similar approach to inject the filename into the finder implementation.

然后，我使用类似的方法将文件名注入 MovieFinder 的实现类：

public interface InjectFinderFilename {
    void injectFilename (String filename);
}
class ColonMovieFinder implements MovieFinder, InjectFinderFilename...

  public void injectFilename(String filename) {
      this.filename = filename;
  }

Then, as usual, I need some configuration code to wire up the implementations. For simplicity’s sake I’ll do it in code.

class Tester...

  private Container container;

   private void configureContainer() {
     container = new Container();
     registerComponents();
     registerInjectors();
     container.start();
  }

When the dependent is a class written for this container, it makes sense for the component to implement the injector interface itself, as I do here with the movie finder. For generic classes, such as the string, I use an inner class within the configuration code.

class ColonMovieFinder implements Injector...

  public void inject(Object target) {
    ((InjectFinder) target).injectFinder(this);        
  }
class Tester...

  public static class FinderFilenameInjector implements Injector {
    public void inject(Object target) {
      ((InjectFinderFilename)target).injectFilename("movies1.txt");      
    }
    }

The tests then use the container.

测试代码则可以直接使用这个字段：

class Tester…

  public void testIface() {
    configureContainer();
    MovieLister lister = (MovieLister)container.lookup("MovieLister");
    Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
    assertEquals("Once Upon a Time in the West", movies[0].getTitle());
  }

The container uses the declared injection interfaces to figure out the dependencies and the injectors to inject the correct dependents. (The specific container implementation I did here isn’t important to the technique, and I won’t show it because you’d only laugh.)

使用 Service Locator Using a Service Locator

The key benefit of a Dependency Injector is that it removes the dependency that the MovieLister class has on the concrete MovieFinder implementation. This allows me to give listers to friends and for them to plug in a suitable implementation for their own environment. Injection isn’t the only way to break this dependency, another is to use a service locator.

依赖注入的最大好处在于：它消除了 MovieLister 类对具体 MovieFinder 实现类的依赖。这样一来，我就可以把 MovieLister 类交给朋友，让他们根据自己的环境插入一个合适的 MovieFinder 实现即可。不过，Dependency Injection 模式并不是打破这层依赖关系的唯一手段，另一种方法是使用 Service Locator 模式。

The basic idea behind a service locator is to have an object that knows how to get hold of all of the services that an application might need. So a service locator for this application would have a method that returns a movie finder when one is needed. Of course this just shifts the burden a tad, we still have to get the locator into the lister, resulting in the dependencies of Figure 3

Service Locator 模式背后的基本思想是：有一个对象（即服务定位器）知道如何获得一个应用程序所需的所有服务。也就是说，在我们的例子中，服务定位器应该有一个方法，用于获得一个 MovieFinder 实例。当然，这不过是把麻烦换了一个样子，我们仍然必须在 MovieLister 中获得服务定位器，最终得到的依赖关系如图 3 所示：

In this case I’ll use the ServiceLocator as a singleton Registry. The lister can then use that to get the finder when it’s instantiated.

在这里，我把 ServiceLocator 类实现为一个 Singleton 的注册表，于是 MovieLister 就可以在实例化时通过 ServiceLocator 获得一个 MovieFinder 实例。

class MovieLister...

  MovieFinder finder = ServiceLocator.movieFinder();
class ServiceLocator...

  public static MovieFinder movieFinder() {
      return soleInstance.movieFinder;
  }
  private static ServiceLocator soleInstance;
  private MovieFinder movieFinder;

As with the injection approach, we have to configure the service locator. Here I’m doing it in code, but it’s not hard to use a mechanism that would read the appropriate data from a configuration file.

和注入的方式一样，我们也必须对服务定位器加以配置。在这里，我直接在代码中进行配置，但设计一种通过配置文件获得数据的机制也并非难事。

class Tester...

  private void configure() {
      ServiceLocator.load(new ServiceLocator(new ColonMovieFinder("movies1.txt")));
  }
class ServiceLocator...

  public static void load(ServiceLocator arg) {
      soleInstance = arg;
  }

  public ServiceLocator(MovieFinder movieFinder) {
      this.movieFinder = movieFinder;
  }

Here’s the test code.

下面是测试代码：

class Tester...

  public void testSimple() {
      configure();
      MovieLister lister = new MovieLister();
      Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
      assertEquals("Once Upon a Time in the West", movies[0].getTitle());
  }

I’ve often heard the complaint that these kinds of service locators are a bad thing because they aren’t testable because you can’t substitute implementations for them. Certainly you can design them badly to get into this kind of trouble, but you don’t have to. In this case the service locator instance is just a simple data holder. I can easily create the locator with test implementations of my services.

我时常听到这样的论调：这样的服务定位器不是什么好东西，因为你无法替换它返回的服务实现，从而导致无法对它们进行测试。当然，如果你的设计很糟糕，你的确会遇到这样的麻烦；但你也可以选择良好的设计。在这个例子中，ServiceLocator 实例仅仅是一个简单的数据容器，只需要对它做一些简单的修改，就可以让它返回用于测试的服务实现。

For a more sophisticated locator I can subclass service locator and pass that subclass into the registry’s class variable. I can change the static methods to call a method on the instance rather than accessing instance variables directly. I can provide thread–specific locators by using thread–specific storage. All of this can be done without changing clients of service locator.

对于更复杂的情况，我可以从 ServiceLocator 派生出多个子类，并将子类型的实例传递给注册表的类变量。另外，我可以修改 ServiceLocator 的静态方法，使其调用 ServiceLocator 实例的方法，而不是直接访问实例变量。我还可以使用特定于线程的存储机制，从而提供特定于线程的服务定位器。所有这一切改进都无须修改 ServiceLocator 的使用者。

A way to think of this is that service locator is a registry not a singleton. A singleton provides a simple way of implementing a registry, but that implementation decision is easily changed.

一种改进的思路是：服务定位器仍然是一个注册表，但不是 Singleton。Singleton 的确是实现注册表的一种简单途径，但这只是一个实现时的决定，可以很轻松地改变它。

为定位器提供分离的接口

One of the issues with the simple approach above, is that the MovieLister is dependent on the full service locator class, even though it only uses one service. We can reduce this by using a role interface. That way, instead of using the full service locator interface, the lister can declare just the bit of interface it needs.

上面这种简单的实现方式有一个问题：MovieLister 类将依赖于整个 ServiceLocator 类，但它需要使用的却只是后者所提供的一项服务。我们可以针对这项服务提供一个单独的接口，减少 MovieLister 对 ServiceLocator 的依赖程度。这样一来，MovieLister 就不必使用整个的 ServiceLocator 接口，只需声明它想要使用的那部分接口。

In this situation the provider of the lister would also provide a locator interface which it needs to get hold of the finder.

此时，MovieLister 类的提供者也应该一并提供一个定位器接口，使用者可以通过这个接口获得 MovieFinder 实例。

public interface MovieFinderLocator {
    public MovieFinder movieFinder();

The locator then needs to implement this interface to provide access to a finder.

真实的服务定位器需要实现上述接口，提供访问 MovieFinder 实例的能力：

MovieFinderLocator locator = ServiceLocator.locator();
MovieFinder finder = locator.movieFinder();
public static ServiceLocator locator() {
     return soleInstance;
 }
 public MovieFinder movieFinder() {
     return movieFinder;
 }
 private static ServiceLocator soleInstance;
 private MovieFinder movieFinder;

You’ll notice that since we want to use an interface, we can’t just access the services through static methods any more. We have to use the class to get a locator instance and then use that to get what we need.

你应该已经注意到了：由于想要使用接口，我们不能再通过静态方法直接访问服务——我们必须首先通过 ServiceLocator 类获得定位器实例，然后使用定位器实例得到我们想要的服务。

动态服务定位器

The above example was static, in that the service locator class has methods for each of the services that you need. This isn’t the only way of doing it, you can also make a dynamic service locator that allows you to stash any service you need into it and make your choices at runtime.

上面是一个静态定位器的例子——对于你所需要的每项服务，ServiceLocator 类都有对应的方法。这并不是实现服务定位器的唯一方式，你也可以创建一个动态服务定位器，你可以在其中注册需要的任何服务，并在运行期决定获得哪一项服务。

In this case, the service locator uses a map instead of fields for each of the services, and provides generic methods to get and load services.

在本例中，ServiceLocator 使用一个 map 来保存服务信息，而不再是将这些信息保存在字段中。此外，ServiceLocator 还提供了一个通用的方法，用于获取和加载服务对象。

class ServiceLocator...

  private static ServiceLocator soleInstance;
  public static void load(ServiceLocator arg) {
      soleInstance = arg;
  }
  private Map services = new HashMap();
  public static Object getService(String key){
      return soleInstance.services.get(key);
  }
  public void loadService (String key, Object service) {
      services.put(key, service);
  }

Configuring involves loading a service with an appropriate key.

同样需要对服务定位器进行配置，将服务对象与适当的关键字加载到定位器中：

class Tester...

  private void configure() {
      ServiceLocator locator = new ServiceLocator();
      locator.loadService("MovieFinder", new ColonMovieFinder("movies1.txt"));
      ServiceLocator.load(locator);
  }

I use the service by using the same key string.

我使用与服务对象类名称相同的字符串作为服务对象的关键字：

class MovieLister...

  MovieFinder finder = (MovieFinder) ServiceLocator.getService("MovieFinder");

On the whole I dislike this approach. Although it’s certainly flexible, it’s not very explicit. The only way I can find out how to reach a service is through textual keys. I prefer explicit methods because it’s easier to find where they are by looking at the interface definitions.

总体而言，我不喜欢这种方式。无疑，这样实现的服务定位器具有更强的灵活性，但它的使用方式不够直观明朗。我只有通过文本形式的关键字才能找到一个服务对象。相比之下，我更欣赏“通过一个方法明确获得服务对象”的方式，因为这让使用者能够从接口定义中清楚地知道如何获得某项服务。

用 Avalon 兼顾服务定位器和依赖注入

Dependency injection and a service locator aren’t necessarily mutually exclusive concepts. A good example of using both together is the Avalon framework. Avalon uses a service locator, but uses injection to tell components where to find the locator.

Dependency Injection 和 Service Locator 两个模式并不是互斥的，你可以同时使用它们，Avalon 框架就是这样的一个例子。Avalon 使用了服务定位器，但“如何获得定位器”的信息则是通过注入的方式告知组件的。

Berin Loritsch sent me this simple version of my running example using Avalon.

对于前面一直使用的例子，Berin Loritsch 发送给了我一个简单的 Avalon 实现版本：

public class MyMovieLister implements MovieLister, Serviceable {
private MovieFinder finder;

    public void service( ServiceManager manager ) throws ServiceException {
        finder = (MovieFinder)manager.lookup(“finder”);
    } 

The service method is an example of interface injection, allowing the container to inject a service manager into MyMovieLister. The service manager is an example of a service locator. In this example the lister doesn’t store the manager in a field, instead it immediately uses it to lookup the finder, which it does store.

service 方法就是接口注入的例子，它使容器可以将一个 ServiceManager 对象注入 MyMovieLister 对象。ServiceManager 则是一个服务定位器。在这个例子中，MyMovieLister 并不把 ServiceManager 对象保存在字段中，而是马上借助它找到 MovieFinder 实例，并将后者保存起来。

作出一个选择 Deciding which option to use

So far I’ve concentrated on explaining how I see these patterns and their variations. Now I can start talking about their pros and cons to help figure out which ones to use and when.

到现在为止，我一直在阐述自己对这两个模式（Dependency Injection 模式和 Service Locator 模式）以及它们的变化形式的看法。现在，我要开始讨论他们的优点和缺点，以便指出它们各自适用的场景。

Service Locator vs. Dependency Injection

The fundamental choice is between Service Locator and Dependency Injection. The first point is that both implementations provide the fundamental decoupling that’s missing in the naive example - in both cases application code is independent of the concrete implementation of the service interface. The important difference between the two patterns is about how that implementation is provided to the application class. With service locator the application class asks for it explicitly by a message to the locator. With injection there is no explicit request, the service appears in the application class - hence the inversion of control.

首先，我们面临 Service Locator 和 Dependency Injection 之间的选择。应该注意，尽管我们前面那个简单的例子不足以表现出来，实际上这两个模式都提供了基本的解耦合能力——无论使用哪个模式，应用程序代码都不依赖于服务接口的具体实现。两者之间最重要的区别在于：这个“具体实现”以什么方式提供给应用程序代码。使用 Service Locator 模式时，应用程序代码直接向服务定位器发送一个消息，明确要求服务的实现；使用 Dependency Injection 模式时，应用程序代码不发出显式的请求，服务的实现自然会出现在应用程序代码中，这也就是所谓 “控制反转”

Inversion of control is a common feature of frameworks, but it’s something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn’t to say it’s a bad thing, just that I think it needs to justify itself over the more straightforward alternative.

控制反转是框架的共同特征，但它也要求你付出一定的代价：它会增加理解的难度，并且给调试带来一定的困难。所以，整体来说，除非必要，否则我会尽量避免使用它。这并不意味着控制反转不好，只是我认为在很多时候使用一个更为直观的方案（例如 Service Locator 模式）会比较合适。

The key difference is that with a Service Locator every user of a service has a dependency to the locator. The locator can hide dependencies to other implementations, but you do need to see the locator. So the decision between locator and injector depends on whether that dependency is a problem.

一个关键的区别在于：使用 Service Locator 模式时，服务的使用者必须依赖于服务定位器。定位器可以隐藏使用者对服务具体实现的依赖，但你必须首先看到定位器本身。所以，问题的答案就很明朗了：选择 Service Locator 还是 Dependency Injection，取决于“对定位器的依赖”是否会给你带来麻烦。

Using dependency injection can help make it easier to see what the component dependencies are. With dependency injector you can just look at the injection mechanism, such as the constructor, and see the dependencies. With the service locator you have to search the source code for calls to the locator. Modern IDEs with a find references feature make this easier, but it’s still not as easy as looking at the constructor or setting methods.

Dependency Injection 模式可以帮助你看清组件之间的依赖关系：你只需观察依赖注入的机制（例如构造子），就可以掌握整个依赖关系。而使用 Service Locator 模式时，你就必须在源代码中到处搜索对服务定位器的调用。具备全文检索能力的 IDE 可以略微简化这一工作，但还是不如直接观察构造子或者设值方法来得轻松。

A lot of this depends on the nature of the user of the service. If you are building an application with various classes that use a service, then a dependency from the application classes to the locator isn’t a big deal. In my example of giving a Movie Lister to my friends, then using a service locator works quite well. All they need to do is to configure the locator to hook in the right service implementations, either through some configuration code or through a configuration file. In this kind of scenario I don’t see the injector’s inversion as providing anything compelling.

这个选择主要取决于服务使用者的性质。如果你的应用程序中有很多不同的类要使用一个服务，那么应用程序代码对服务定位器的依赖就不是什么大问题。在前面的例子中，我要把 MovieLister 类交给朋友去用，这种情况下使用服务定位器就很好：我的朋友们只需要对定位器做一点配置（通过配置文件或者某些配置性的代码），使其提供合适的服务实现就可以了。在这种情况下，我看不出 Dependency Injection 模式提供的控制反转有什么吸引人的地方。

The difference comes if the lister is a component that I’m providing to an application that other people are writing. In this case I don’t know much about the APIs of the service locators that my customers are going to use. Each customer might have their own incompatible service locators. I can get around some of this by using the segregated interface. Each customer can write an adapter that matches my interface to their locator, but in any case I still need to see the first locator to lookup my specific interface. And once the adapter appears then the simplicity of the direct connection to a locator is beginning to slip.

但是，如果把 MovieLister 看作一个组件，要将它提供给别人写的应用程序去使用，情况就不同了。在这种时候，我无法预测使用者会使用什么样的服务定位器 API，每个使用者都可能有自己的服务定位器，而且彼此之间无法兼容。一种解决办法是为每项服务提供单独的接口，使用者可以编写一个适配器，让我的接口与他们的服务定位器相配合。但即便如此，我仍然需要到第一个服务定位器中寻找我规定的接口。而且一旦用上了适配器，服务定位器所提供的简单性就被大大削弱了。

Since with an injector you don’t have a dependency from a component to the injector, the component cannot obtain further services from the injector once it’s been configured.

另一方面，如果使用 Dependency Injection 模式，组件与注入器之间不会有依赖关系，因此组件无法从注入器那里获得更多的服务，只能获得配置信息中所提供的那些。这也是 Dependency Injection 模式的局限性之一。

A common reason people give for preferring dependency injection is that it makes testing easier. The point here is that to do testing, you need to easily replace real service implementations with stubs or mocks. However there is really no difference here between dependency injection and service locator: both are very amenable to stubbing. I suspect this observation comes from projects where people don’t make the effort to ensure that their service locator can be easily substituted. This is where continual testing helps, if you can’t easily stub services for testing, then this implies a serious problem with your design.

人们倾向于使用 Dependency Injection 模式的一个常见理由是：它简化了测试工作。这里的关键是：出于测试的需要，你必须能够轻松地在“真实的服务实现”与“供测试用的‘伪’组件” 之间切换。但是，如果单从这个角度来考虑，Dependency Injection 模式和 Service Locator 模式其实并没有太大区别：两者都能够很好地支持“伪”组件的插入。之所以很多人有 “Dependency Injection 模式更利于测试”的印象，我猜是因为他们并没有努力保证服务定位器的可替换性。这正是持续测试起作用的地方：如果你不能轻松地用一些“伪”组件将一个服务架起来以便测试，这就意味着你的设计出现了严重的问题。

Of course the testing problem is exacerbated by component environments that are very intrusive, such as Java’s EJB framework. My view is that these kinds of frameworks should minimize their impact upon application code, and particularly should not do things that slow down the edit-execute cycle. Using plugins to substitute heavyweight components does a lot to help this process, which is vital for practices such as Test Driven Development.

当然，如果组件环境具有非常强的侵略性（就像 EJB 框架那样），测试的问题会更加严重。我的观点是：应该尽量减少这类框架对应用程序代码的影响，特别是不要做任何可能使“编辑-执行” 的循环变慢的事情。用插件（plugin）机制取代重量级组件会对测试过程有很大帮助，这正是测试驱动开发（Test Driven Development，TDD）之类实践的关键所在。

So the primary issue is for people who are writing code that expects to be used in applications outside of the control of the writer. In these cases even a minimal assumption about a Service Locator is a problem.

所以，主要的问题在于：代码的作者是否希望自己编写的组件能够脱离自己的控制、被使用在另一个应用程序中。如果答案是肯定的，那么他就不能对服务定位器做任何假设——哪怕最小的假设也会给使用者带来麻烦。

构造子注入 vs. 设值方法注入

For service combination, you always have to have some convention in order to wire things together. The advantage of injection is primarily that it requires very simple conventions - at least for the constructor and setter injections. You don’t have to do anything odd in your component and it’s fairly straightforward for an injector to get everything configured.

在组合服务时，你总得遵循一定的约定，才可能将所有东西拼装起来。依赖注入的优点主要在于：它只需要非常简单的约定——至少对于构造子注入和设值方法注入来说是这样。相比于这两者，接口注入的侵略性要强得多，比起 Service Locator 模式的优势也不那么明显。

Interface injection is more invasive since you have to write a lot of interfaces to get things all sorted out. For a small set of interfaces required by the container, such as in Avalon’s approach, this isn’t too bad. But it’s a lot of work for assembling components and dependencies, which is why the current crop of lightweight containers go with setter and constructor injection.

所以，如果你想要提供一个组件给多个使用者，构造子注入和设值方法注入看起来很有吸引力：你不必在组件中加入什么希奇古怪的东西，注入器可以相当轻松地把所有东西配置起来。

The choice between setter and constructor injection is interesting as it mirrors a more general issue with object-oriented programming - should you fill fields in a constructor or with setters.

设值函数注入和构造子注入之间的选择相当有趣，因为它折射出面向对象编程的一些更普遍的问题：应该在哪里填充对象的字段，构造子还是设值方法？

My long running default with objects is as much as possible, to create valid objects at construction time. This advice goes back to Kent Beck’s Smalltalk Best Practice Patterns: Constructor Method and Constructor Parameter Method. Constructors with parameters give you a clear statement of what it means to create a valid object in an obvious place. If there’s more than one way to do it, create multiple constructors that show the different combinations.

一直以来，我首选的做法是尽量在构造阶段就创建完整、合法的对象——也就是说，在构造子中填充对象字段。这样做的好处可以追溯到 Kent Beck 在 Smalltalk Best Practice Patterns 一书中介绍的两个模式：Constructor Method 和 Constructor Parameter Method。带有参数的构造子可以明确地告诉你如何创建一个合法的对象。如果创建合法对象的方式不止一种，你还可以提供多个构造子，以说明不同的组合方式。

Another advantage with constructor initialization is that it allows you to clearly hide any fields that are immutable by simply not providing a setter. I think this is important - if something shouldn’t change then the lack of a setter communicates this very well. If you use setters for initialization, then this can become a pain. (Indeed in these situations I prefer to avoid the usual setting convention, I’d prefer a method like initFoo, to stress that it’s something you should only do at birth.)

构造子初始化的另一个好处是：你可以隐藏任何不可变的字段——只要不为它提供设值方法就行了。我认为这很重要：如果某个字段是不应该被改变的，“没有针对该字段的设值方法”就很清楚地说明了这一点。如果你通过设值方法完成初始化，暴露出来的设值方法很可能成为你心头永远的痛。（实际上，在这种时候我更愿意回避通常的设值方法约定，而是使用诸如 initFoo 之类的方法名，以表明该方法只应该在对象创建之初调用。）

But with any situation there are exceptions. If you have a lot of constructor parameters things can look messy, particularly in languages without keyword parameters. It’s true that a long constructor is often a sign of an over-busy object that should be split, but there are cases when that’s what you need.

不过，世事总有例外。如果参数太多，构造子会显得凌乱不堪，特别是对于不支持关键字参数的语言更是如此。的确，如果构造子参数列表太长，通常标志着对象太过繁忙，理应将其拆分成几个对象，但有些时候也确实需要那么多的参数。

If you have multiple ways to construct a valid object, it can be hard to show this through constructors, since constructors can only vary on the number and type of parameters. This is when Factory Methods come into play, these can use a combination of private constructors and setters to implement their work. The problem with classic Factory Methods for components assembly is that they are usually seen as static methods, and you can’t have those on interfaces. You can make a factory class, but then that just becomes another service instance. A factory service is often a good tactic, but you still have to instantiate the factory using one of the techniques here.

如果有不止一种的方式可以构造一个合法的对象，也很难通过构造子描述这一信息，因为构造子之间只能通过参数的个数和类型加以区分。这就是 Factory Method 模式适用的场合了，工厂方法可以借助多个私有构造子和设值方法的组合来完成自己的任务。经典 Factory Method 模式的问题在于：它们往往以静态方法的形式出现，你无法在接口中声明它们。你可以创建一个工厂类，但那又变成另一个服务实体了。“工厂服务”是一种不错的技巧，但你仍然需要以某种方式实例化这个工厂对象，问题仍然没有解决。

Constructors also suffer if you have simple parameters such as strings. With setter injection you can give each setter a name to indicate what the string is supposed to do. With constructors you are just relying on the position, which is harder to follow.

如果要传入的参数是像字符串这样的简单类型，构造子注入也会带来一些麻烦。使用设值方法注入时，你可以在每个设值方法的名字中说明参数的用途；而使用构造子注入时，你只能靠参数的位置来决定每个参数的作用，而记住参数的正确位置显然要困难得多。

If you have multiple constructors and inheritance, then things can get particularly awkward. In order to initialize everything you have to provide constructors to forward to each superclass constructor, while also adding you own arguments. This can lead to an even bigger explosion of constructors.

如果对象有多个构造子，对象之间又存在继承关系，事情就会变得特别讨厌。为了让所有东西都正确地初始化，你必须将对子类构造子的调用转发给超类的构造子，然后处理自己的参数。这可能造成构造子规模的进一步膨胀。

Despite the disadvantages my preference is to start with constructor injection, but be ready to switch to setter injection as soon as the problems I’ve outlined above start to become a problem.

尽管有这些缺陷，但我仍然建议你首先考虑构造子注入。不过，一旦前面提到的问题真的成了问题，你就应该准备转为使用设值方法注入。

This issue has led to a lot of debate between the various teams who provide dependency injectors as part of their frameworks. However it seems that most people who build these frameworks have realized that it’s important to support both mechanisms, even if there’s a preference for one of them.

在将 Dependecy Injection 模式作为框架的核心部分的几支团队之间，“构造子注入还是设值方法注入”引发了很多的争论。不过，现在看来，开发这些框架的大多数人都已经意识到：不管更喜欢哪种注入机制，同时为两者提供支持都是有必要的。

代码配置 vs. 配置文件

A separate but often conflated issue is whether to use configuration files or code on an API to wire up services. For most applications that are likely to be deployed in many places, a separate configuration file usually makes most sense. Almost all the time this will be an XML file, and this makes sense. However there are cases where it’s easier to use program code to do the assembly. One case is where you have a simple application that’s not got a lot of deployment variation. In this case a bit of code can be clearer than a separate XML file.

另一个问题相对独立，但也经常与其他问题牵涉在一起：如何配置服务的组装，通过配置文件还是直接编码组装？对于大多数需要在多处部署的应用程序来说，一个单独的配置文件会更合适。配置文件几乎都是 XML 文件，XML 也的确很适合这一用途。不过，有些时候直接在程序代码中实现装配会更简单。譬如一个简单的应用程序，也没有很多部署上的变化，这时用几句代码来配置就比 XML 文件要清晰得多。

A contrasting case is where the assembly is quite complex, involving conditional steps. Once you start getting close to programming language then XML starts breaking down and it’s better to use a real language that has all the syntax to write a clear program. You then write a builder class that does the assembly. If you have distinct builder scenarios you can provide several builder classes and use a simple configuration file to select between them.

与之相对的，有时应用程序的组装非常复杂，涉及大量的条件步骤。一旦编程语言中的配置逻辑开始变得复杂，你就应该用一种合适的语言来描述配置信息，使程序逻辑变得更清晰。然后，你可以编写一个构造器（builder）类来完成装配工作。如果使用构造器的情景不止一种，你可以提供多个构造器类，然后通过一个简单的配置文件在它们之间选择。

I often think that people are over-eager to define configuration files. Often a programming language makes a straightforward and powerful configuration mechanism. Modern languages can easily compile small assemblers that can be used to assemble plugins for larger systems. If compilation is a pain, then there are scripting languages that can work well also.

我常常发现，人们太急于定义配置文件。编程语言通常会提供简捷而强大的配置管理机制，现代编程语言也可以将程序编译成小的模块，并将其插入大型系统中。如果编译过程会很费力，脚本语言也可以在这方面提供帮助。

It’s often said that configuration files shouldn’t use a programing language because they need to be edited by non-programmers. But how often is this the case? Do people really expect non-programmers to alter the transaction isolation levels of a complex server-side application? Non-language configuration files work well only to the extent they are simple. If they become complex then it’s time to think about using a proper programming language.

通常认为，配置文件不应该用编程语言来编写，因为它们需要能够被不懂编程的系统管理人员编辑。但是，这种情况出现的几率有多大呢？我们真的希望不懂编程的系统管理人员来改变一个复杂的服务器端应用程序的事务隔离等级吗？只有在非常简单的时候，非编程语言的配置文件才有最好的效果。如果配置信息开始变得复杂，就应该考虑选择一种合适的编程语言来编写配置文件。

One thing we’re seeing in the Java world at the moment is a cacophony of configuration files, where every component has its own configuration files which are different to everyone else’s. If you use a dozen of these components, you can easily end up with a dozen configuration files to keep in sync.

在 Java 世界里，我们听到了来自配置文件的不和谐音——每个组件都有它自己的配置文件，而且格式还各各不同。如果你要使用一打这样的组件，你就得维护一打的配置文件，那会很快让你烦死。

My advice here is to always provide a way to do all configuration easily with a programmatic interface, and then treat a separate configuration file as an optional feature. You can easily build configuration file handling to use the programmatic interface. If you are writing a component you then leave it up to your user whether to use the programmatic interface, your configuration file format, or to write their own custom configuration file format and tie it into the programmatic interface

在这里，我的建议是：始终提供一种标准的配置方式，使程序员能够通过同一个编程接口轻松地完成配置工作。至于其他的配置文件，仅仅把它们当作一种可选的功能。借助这个编程接口，开发者可以轻松地管理配置文件。如果你编写了一个组件，则可以由组件的使用者来选择如何管理配置信息：使用你的编程接口、直接操作配置文件格式，或者定义他们自己的配置文件格式，并将其与你的编程接口相结合。

分离配置与使用

The important issue in all of this is to ensure that the configuration of services is separated from their use. Indeed this is a fundamental design principle that sits with the separation of interfaces from implementation. It’s something we see within an object-oriented program when conditional logic decides which class to instantiate, and then future evaluations of that conditional are done through polymorphism rather than through duplicated conditional code.

所有这一切的关键在于：服务的配置应该与使用分开。实际上，这是一个基本的设计原则——分离接口与实现。在面向对象程序里，我们在一个地方用条件逻辑来决定具体实例化哪一个类，以后的条件分支都由多态来实现，而不是继续重复前面的条件逻辑，这就是“分离接口与实现”的原则。

If this separation is useful within a single code base, it’s especially vital when you’re using foreign elements such as components and services. The first question is whether you wish to defer the choice of implementation class to particular deployments. If so you need to use some implementation of plugin. Once you are using plugins then it’s essential that the assembly of the plugins is done separately from the rest of the application so that you can substitute different configurations easily for different deployments. How you achieve this is secondary. This configuration mechanism can either configure a service locator, or use injection to configure objects directly.

如果对于一段代码而言，接口与实现的分离还只是“有用”的话，那么当你需要使用外部元素（例如组件和服务）时，它就是生死攸关的大事。这里的第一个问题是：你是否希望将“选择具体实现类”的决策推迟到部署阶段。如果是，那么你需要使用插入技术。使用了插入技术之后，插件的装配原则上是与应用程序的其余部分分开的，这样你就可以轻松地针对不同的部署替换不同的配置。这种配置机制可以通过服务定位器来实现（Service Locator 模式），也可以借助依赖注入直接完成（Dependency Injection 模式）。

更多的问题 Some further issues

In this article, I’ve concentrated on the basic issues of service configuration using Dependency Injection and Service Locator. There are some more topics that play into this which also deserve attention, but I haven’t had time yet to dig into. In particular there is the issue of life-cycle behavior. Some components have distinct life-cycle events: stop and starts for instance. Another issue is the growing interest in using aspect oriented ideas with these containers. Although I haven’t considered this material in the article at the moment, I do hope to write more about this either by extending this article or by writing another.

在本文中，我关注的焦点是使用 Dependency Injection 模式和 Service Locator 模式进行服务配置的基本问题。还有一些与之相关的话题值得关注，但我已经没有时间继续申发下去了。特别值得注意的是生命周期行为的问题：某些组件具有特定的生命周期事件，例如“停止”、“开始”等等。另一个值得注意的问题是：越来越多的人对“如何在这些容器中运用面向方面（aspect oriented）的思想”产生了兴趣。尽管目前还没有认真准备过这方面的材料，但我也很希望以后能在这个话题上写一些东西。

You can find out a lot more about these ideas by looking at the web sites devoted to the lightweight containers. Surfing from the picocontainer and spring web sites will lead to you into much more discussion of these issues and a start on some of the further issues.

关于这些问题，你在专注于轻量级容器的网站上可以找到很多资料。浏览 PicoContainer（http://www.picocontainer.org）或者Spring（http://www.springframework.org）的网站，你可以找到大量相关的讨论，并由此引申出更多的话题。

结论和思考 Concluding Thoughts

The current rush of lightweight containers all have a common underlying pattern to how they do service assembly - the dependency injector pattern. Dependency Injection is a useful alternative to Service Locator. When building application classes the two are roughly equivalent, but I think Service Locator has a slight edge due to its more straightforward behavior. However if you are building classes to be used in multiple applications then Dependency Injection is a better choice.

在时下流行的轻量级容器都使用了一个共同的模式来组装应用程序所需的服务，我把这个模式称为 Dependency Injection，它可以有效地替代 Service Locator 模式。在开发应用程序时，两者不相上下，但我认为 Service Locator 模式略有优势，因为它的行为方式更为直观。但是，如果你开发的组件要交给多个应用程序去使用，那么 Dependency Injection 模式会是更好的选择。

If you use Dependency Injection there are a number of styles to choose between. I would suggest you follow constructor injection unless you run into one of the specific problems with that approach, in which case switch to setter injection. If you are choosing to build or obtain a container, look for one that supports both constructor and setter injection.

如果你决定使用 Dependency Injection 模式，这里还有几种不同的风格可供选择。我建议你首先考虑构造子注入；如果遇到了某些特定的问题，再改用设值方法注入。如果你要选择一个容器，在其之上进行开发，我建议你选择同时支持这两种注入方式的容器。

The choice between Service Locator and Dependency Injection is less important than the principle of separating service configuration from the use of services within an application.

Service Locator 模式和 Dependency Injection 模式之间的选择并是最重要的，更重要的是：应该将服务的配置和应用程序内部对服务的使用分离开。

致谢 Acknowledgments

My sincere thanks to the many people who’ve helped me with this article. Rod Johnson, Paul Hammant, Joe Walnes, Aslak Hellesøy, Jon Tirsén and Bill Caputo helped me get to grips with these concepts and commented on the early drafts of this article. Berin Loritsch and Hamilton Verissimo de Oliveira provided some very helpful advice on how Avalon fits in. Dave W Smith persisted in asking questions about my initial interface injection configuration code and thus made me confront the fact that it was stupid. Gerry Lowry sent me lots of typo fixes - enough to cross the thanks threshold.

在此，我要向帮助我理解本文中所提到的问题、并对本文提出宝贵意见的几个人表示感谢，他们是 Rod Johnson、Paul Hammant、Joe Walnes、Aslak Hellesoy、Jon Tirsen 和 Bill Caputo。另外，Berin Loritsch 和 Hamilton Verissimo de Oliveira 在 Avalon 方面给了我非常有用的建议，一并向他们表示感谢。

引言

League Director is a tool for staging and recording videos from League of Legends replays.

Install

Github 下载

最正统的官方下载渠道，下载链接：https://github.com/RiotGames/leaguedirector/releases/tag/v0.1.4。

服务器下载

我自己的云存储服务器上也做了一个备份方便大家下载，下载链接：

• 联盟导演
• 联盟导演-汉化版

汉化版的版本比较低，但原版在国服会有一些莫名奇妙的问题，所以还是推荐下载第二个链接。

Feature

• Control replay playback and speed
• First person camera controls
• Attach camera to champion or minion
• Toggle interface elements including HUD, health bars and notifications
• Graphical Options
  • Field of view
    Near and far clipping
    Custom skyboxes
    Shadow direction
    Depth and height fog
    Depth of field
• Sequencer
  • Record and playback keyframed camera position + graphical options
  • Timeline for viewing and editing keyframe values
  • Undo / Redo
  • Save and load pre saved sequences
  • Adjustable keyframe blending
• Video capture in webm or png format
• Customizable key bindings

How To Use

Note: Windows Only

1. Download League Director from the releases page and install.
2. Start League Director and make sure the checkbox next to your install is checked.
3. Start League of Legends and launch a replay. League Director will automatically connect.
4. Open the options menu (ESC key) in game and ensure your Video Graphics settings are set to Very High. If you did need to change your Video Graphics settings, you’ll need to restart the replay to enable the additional rendering features like the skybox.
5. Select FPS Camera from the Camera Modes drop down in game.
6. Using the numpad keys (4, 5, 6, 8) and the mouse you can free camera move around. Key bindings for free camera can also be changed inside the game options.

安装一下 SetUp.exe，一路点确定即可。打开程序首先会弹出游戏的安装路径确认窗口：

选择好之后启动游戏并打开录像，就会有如下界面：

引言

奇瑞万达需要实现快速选择、对比、修改端子功能端子查询功能，做一下项目的总结。

为实体添加扩展数据

删除端子实体时需要一个识别标记，我选择加入扩展数据作为标识符：

1. 注册一个不会重名的 appName
2. 创建你所需要的 xData 缓冲区链表
3. 把这个数据放到实体中

const CString appName = L"SelectXDataApp";

acdbRegApp(appName);
struct resbuf* rb = acutBuildList(AcDb::kDxfRegAppName, appName,
    AcDb::kDxfXdAsciiString, TEXT("xxxxxxx"),
    RTNONE);

pPline->setXData(rb);
acutRelRb(rb);

acutBuildList() 创建链表时前两个默认为 APP 类型和 APP 名称，后面也是以 type-value 的形式两两创建链表数据。

模态对话框中实现用户和 CAD 的交互操作

问题描述

现在的业务场景需要在弹出模态对话框之后再返回 CAD 选择实体（也就是端子），再重新显示对话框。

最开始我的处理办法是将模态对话框改为非模态对话框，但在对话框的生命周期控制上很难把控，问题比较多，所以目光又重新回到如何使用模态对话框处理这类场景。

文档查阅

在模态对话框中实现用户和AutoCAD 的交互操作 这篇文章提到使用 BeginEditorCommand() 这个方法去从模态对话框切换到 CAD 应用程序，下面是 官方文档 的描述：

Call this method to indicate an AutoCAd interactive command is starting.

还贴心的给了一个使用示例：

BeginEditorCommand();
if (DoMyInteractiveCommand())
    CompleteEditorCommand();
else
    CancelEditorCommand();

• BeginEditorCommand 函数用于将控制权（焦点）交给 CAD，一般用于开始一个交
  互操作
• CompleteEditorCommand 函数用于从一个在 CAD 中完成的交互命令返回到应用
  程序
• CancelEditorCommand 函数用于从一个在 CAD 中被取消的交互命令返回到应用程
  序

这三个函数组合使用，能够在模态对话框中实现用户和 CAD 的交互操作。

解决方案

ads_point point{ 0 };
ads_name selectUnit { 0, 0 };

BeginEditorCommand();
auto res = acedEntSel(L"\n请选择需要提取的端子：\n", selectUnit, point);
CompleteEditorCommand();

实体高亮显示

问题描述

奇瑞万达方面需要在选择所有端子后所有都高亮显示，并且能够显示出各自的夹点。

一开始不知道高显这个效果该如何实现，尝试直接调用实体的 highlight() 方法高亮。这种方式没有夹点，在缩放后也没有虚化边框那样明显的视觉效果，客户方面不接受这样的高显只能另寻他法。后面在网上查阅到 ARX亮显问题，里面提到了使用 acedSSSetFirst 这个方法。

文档查阅

由于之前从来没用过这个方法，本着严谨的态度去 官方文档 上又查了一下如何使用。

int acedSSSetFirst(
    const ads_name pset, 
    const ads_name unused
);

• pset：Set of entities to be added to the pickfirst selection set and on which grips will be displayed
• unused：Ignored

This function sets which objects are selected and gripped.

The parameters have the following data type definition:

typedef long ads_name[2];

The selection set of objects specified by the gset argument are gripped, and the selection set of objects specified by pset are both gripped and selected. If any objects are common to both selection sets, acedSSSetFirst() grips and selects the selection set specified by pset only (it does not grip the gset set).

If gset is NULL and pset is specified, acedSSSetFirst() grips and selects pset. If gset and pset are NULL, acedSSSetFirst() turns off any existing grips and selections.

You are responsible for creating a valid selection set. For example, you may need to verify that a background paper space viewport (DXF group code 69) is not included in the selection set. You may also need to ensure that selected objects belong to the current layout.

Note The addCommand() optional flags ACRX_CMD_USEPICKSET and ACRX_CMD_REDRAW must be used in order for acedSSSetFirst() to work.

Do not call acedSSSetFirst() when AutoCAD is in the middle of executing a command.

解决方案

照着人家给的示例代码照猫画虎，也算达到效果了：

ads_name ssName, ssTemp;
acedSSAdd(NULL, NULL, ssTemp);

acedSSGet(NULL, NULL, NULL, NULL, ssName);
Adesk::Int32 len = 0;
acedSSLength(ssName, &len);

for (auto i = 0; i < len; i++)
{
    ads_name ent = {0, 0};
    if (acedSSName(ssName, i, ent) != RTNORM) continue;

    AcDbObjectId idEnt = AcDbObjectId::kNull;
    acdbGetObjectId(idEnt, ent);
    
    AcDbEntity *pEnt = NULL;
    if (acdbOpenAcDbEntity(pEnt, idEnt, AcDb::kForRead) != eOk) continue;
    acedSSAdd(ent, ssTemp, ssTemp);

    pEnt->close();
}
acedSSFree(ssName);
acedSSSetFirst(ssTemp, NULL);

acedSSFree(ssTemp);

注意启动命令要设置为 ACRX_CMD_REDRAW | ACRX_CMD_USEPICKSET，acedSSSetFirst 可以控制加点或者选择的显示，但要注意注册命令的参数。

acedRegCmds->addCommand(_T("xxxxxx"), _T("xxx"), _T("xxx"), ACRX_CMD_TRANSPARENT | ACRX_CMD_USEPICKSET | ACRX_CMD_REDRAW, function);

基于LRU的缓存算法实现

奇瑞万达业务上需要下拉框有记忆功能（即下拉框顺序需要以 最近最少使用 的原则去缓存），在 LeetCode 中也有类似的题目（146. LRU 缓存）。

题目描述

请你设计并实现一个满足 LRU (最近最少使用) 缓存 约束的数据结构。

实现 LRUCache 类：

• LRUCache(int capacity) 以 正整数 作为容量 capacity 初始化 LRU 缓存
• int get(int key) 如果关键字 key 存在于缓存中，则返回关键字的值，否则返回 -1 。
• void put(int key, int value) 如果关键字 key 已经存在，则变更其数据值 value ；如果不存在，则向缓存中插入该组 key-value 。如果插入操作导致关键字数量超过 capacity ，则应该 逐出 最久未使用的关键字。

函数 get 和 put 必须以 O(1) 的平均时间复杂度运行。

示例：

输入
["LRUCache", "put", "put", "get", "put", "get", "put", "get", "get", "get"]
[[2], [1, 1], [2, 2], [1], [3, 3], [2], [4, 4], [1], [3], [4]]
输出
[null, null, null, 1, null, -1, null, -1, 3, 4]

解释
LRUCache lRUCache = new LRUCache(2);
lRUCache.put(1, 1); // 缓存是 {1=1}
lRUCache.put(2, 2); // 缓存是 {1=1, 2=2}
lRUCache.get(1);    // 返回 1
lRUCache.put(3, 3); // 该操作会使得关键字 2 作废，缓存是 {1=1, 3=3}
lRUCache.get(2);    // 返回 -1 (未找到)
lRUCache.put(4, 4); // 该操作会使得关键字 1 作废，缓存是 {4=4, 3=3}
lRUCache.get(1);    // 返回 -1 (未找到)
lRUCache.get(3);    // 返回 3
lRUCache.get(4);    // 返回 4

提示：

• 1 <= capacity <= 3000
• 0 <= key <= 10000
• 0 <= value <= 10^5
• 最多调用 2 * 10^5 次 get 和 put

class LRUCache {
public:
    LRUCache(int capacity) {

    }
    
    int get(int key) {

    }
    
    void put(int key, int value) {

    }
};

/**
 * Your LRUCache object will be instantiated and called as such:
 * LRUCache* obj = new LRUCache(capacity);
 * int param_1 = obj->get(key);
 * obj->put(key,value);
 */

解决方案

思路：

1. 保持把新鲜数据往链表头移动。新鲜的定义：刚被修改(put)，或者访问过(get)，就算新鲜，就需要 splice 到链表头
2. 过期键直接 pop_back()，链表节点越往后，越陈旧

class LRUCache {
public:
    LRUCache(int capacity) : _capacity(capacity) {

    }
    
    int get(int key) {
        auto it = _table.find(key);
        if (it != _table.end()) {
            _lru.splice(_lru.begin(), _lru, it->second);
            return it->second->second;
        }
        return -1;
    }
    
    void put(int key, int value) {
        auto it = _table.find(key);
        if (it != _table.end()) {
            _lru.splice(_lru.begin(), _lru, it->second);
            it->second->second = value;
            return;
        }
        
        _lru.emplace_front(key, value);
        _table[key] = _lru.begin();
        
        if (_table.size() > _capacity) {
            _table.erase(_lru.back().first);
            _lru.pop_back();
        }
    }
private:
    unordered_map<int, std::list<std::pair<int, int>>::iterator> _table;
    std::list<std::pair<int, int>> _lru;
    int _capacity;
};

代码要领：

1. map 中保存的是 <key, 链表节点的指针>，这样查找的时候就不用需要去遍历链表了，使用 unordered_map 就能很快找到链表节点指针
2. 判断容量的时候，最好不使用 std::list::size() 方法，在 c++ 里，这个方法可能不是 O(1) 的。

引言

奇瑞万达端子查询功能开发的项目总结。

实体高亮显示

问题描述

奇瑞万达方面需要在选择所有端子后所有都高亮显示，并且能够显示出各自的夹点。

一开始不知道高显这个效果该如何实现，尝试直接调用实体的 highlight() 方法高亮。这种方式没有夹点，在缩放后也没有虚化边框那样明显的视觉效果，客户方面不接受这样的高显只能另寻他法。后面在网上查阅到 ARX亮显问题，里面提到了使用 acedSSSetFirst 这个方法。

文档查阅

由于之前从来没用过这个方法，本着严谨的态度去 官方文档 上又查了一下如何使用。

int acedSSSetFirst(
    const ads_name pset, 
    const ads_name unused
);

• pset：Set of entities to be added to the pickfirst selection set and on which grips will be displayed
• unused：Ignored

This function sets which objects are selected and gripped.

The parameters have the following data type definition:

typedef long ads_name[2];

The selection set of objects specified by the gset argument are gripped, and the selection set of objects specified by pset are both gripped and selected. If any objects are common to both selection sets, acedSSSetFirst() grips and selects the selection set specified by pset only (it does not grip the gset set).

If gset is NULL and pset is specified, acedSSSetFirst() grips and selects pset. If gset and pset are NULL, acedSSSetFirst() turns off any existing grips and selections.

You are responsible for creating a valid selection set. For example, you may need to verify that a background paper space viewport (DXF group code 69) is not included in the selection set. You may also need to ensure that selected objects belong to the current layout.

Note The addCommand() optional flags ACRX_CMD_USEPICKSET and ACRX_CMD_REDRAW must be used in order for acedSSSetFirst() to work.

Do not call acedSSSetFirst() when AutoCAD is in the middle of executing a command.

解决方案

照着人家给的示例代码照猫画虎，也算达到效果了：

ads_name ssName, ssTemp;
acedSSAdd(NULL, NULL, ssTemp);

acedSSGet(NULL, NULL, NULL, NULL, ssName);
Adesk::Int32 len = 0;
acedSSLength(ssName, &len);

for (auto i = 0; i < len; i++)
{
    ads_name ent = {0, 0};
    if (acedSSName(ssName, i, ent) != RTNORM) continue;

    AcDbObjectId idEnt = AcDbObjectId::kNull;
    acdbGetObjectId(idEnt, ent);
    
    AcDbEntity *pEnt = NULL;
    if (acdbOpenAcDbEntity(pEnt, idEnt, AcDb::kForRead) != eOk) continue;
    acedSSAdd(ent, ssTemp, ssTemp);

    pEnt->close();
}
acedSSFree(ssName);
acedSSSetFirst(ssTemp, NULL);

acedSSFree(ssTemp);

注意启动命令要设置为 ACRX_CMD_REDRAW | ACRX_CMD_USEPICKSET，acedSSSetFirst 可以控制加点或者选择的显示，但要注意注册命令的参数。

acedRegCmds->addCommand(_T("xxxxxx"), _T("xxx"), _T("xxx"), ACRX_CMD_TRANSPARENT | ACRX_CMD_USEPICKSET | ACRX_CMD_REDRAW, function);

基于LRU的缓存算法实现

奇瑞万达业务上需要下拉框有记忆功能（即下拉框顺序需要以 最近最少使用 的原则去缓存），在 LeetCode 中也有类似的题目（146. LRU 缓存）。

题目描述

请你设计并实现一个满足 LRU (最近最少使用) 缓存 约束的数据结构。

实现 LRUCache 类：

• LRUCache(int capacity) 以 正整数 作为容量 capacity 初始化 LRU 缓存
• int get(int key) 如果关键字 key 存在于缓存中，则返回关键字的值，否则返回 -1 。
• void put(int key, int value) 如果关键字 key 已经存在，则变更其数据值 value ；如果不存在，则向缓存中插入该组 key-value 。如果插入操作导致关键字数量超过 capacity ，则应该 逐出 最久未使用的关键字。

函数 get 和 put 必须以 O(1) 的平均时间复杂度运行。

示例：

输入
["LRUCache", "put", "put", "get", "put", "get", "put", "get", "get", "get"]
[[2], [1, 1], [2, 2], [1], [3, 3], [2], [4, 4], [1], [3], [4]]
输出
[null, null, null, 1, null, -1, null, -1, 3, 4]

解释
LRUCache lRUCache = new LRUCache(2);
lRUCache.put(1, 1); // 缓存是 {1=1}
lRUCache.put(2, 2); // 缓存是 {1=1, 2=2}
lRUCache.get(1);    // 返回 1
lRUCache.put(3, 3); // 该操作会使得关键字 2 作废，缓存是 {1=1, 3=3}
lRUCache.get(2);    // 返回 -1 (未找到)
lRUCache.put(4, 4); // 该操作会使得关键字 1 作废，缓存是 {4=4, 3=3}
lRUCache.get(1);    // 返回 -1 (未找到)
lRUCache.get(3);    // 返回 3
lRUCache.get(4);    // 返回 4

提示：

• 1 <= capacity <= 3000
• 0 <= key <= 10000
• 0 <= value <= 105
• 最多调用 2 * 10^5 次 get 和 put

class LRUCache {
public:
    LRUCache(int capacity) {

    }
    
    int get(int key) {

    }
    
    void put(int key, int value) {

    }
};

/**
 * Your LRUCache object will be instantiated and called as such:
 * LRUCache* obj = new LRUCache(capacity);
 * int param_1 = obj->get(key);
 * obj->put(key,value);
 */

实体高亮显示

问题描述

奇瑞万达方面需要在选择所有端子后所有都高亮显示，并且能够显示出各自的夹点。

一开始不知道高显这个效果该如何实现，尝试直接调用实体的 highlight() 方法高亮。这种方式没有夹点，在缩放后也没有虚化边框那样明显的视觉效果，客户方面不接受这样的高显只能另寻他法。后面在网上查阅到 ARX亮显问题，里面提到了使用 acedSSSetFirst 这个方法。

文档查阅

由于之前从来没用过这个方法，本着严谨的态度去 官方文档 上又查了一下如何使用。

int acedSSSetFirst(
    const ads_name pset, 
    const ads_name unused
);

• pset：Set of entities to be added to the pickfirst selection set and on which grips will be displayed
• unused：Ignored

This function sets which objects are selected and gripped.

The parameters have the following data type definition:

typedef long ads_name[2];

The selection set of objects specified by the gset argument are gripped, and the selection set of objects specified by pset are both gripped and selected. If any objects are common to both selection sets, acedSSSetFirst() grips and selects the selection set specified by pset only (it does not grip the gset set).

If gset is NULL and pset is specified, acedSSSetFirst() grips and selects pset. If gset and pset are NULL, acedSSSetFirst() turns off any existing grips and selections.

You are responsible for creating a valid selection set. For example, you may need to verify that a background paper space viewport (DXF group code 69) is not included in the selection set. You may also need to ensure that selected objects belong to the current layout.

Note The addCommand() optional flags ACRX_CMD_USEPICKSET and ACRX_CMD_REDRAW must be used in order for acedSSSetFirst() to work.

Do not call acedSSSetFirst() when AutoCAD is in the middle of executing a command.

解决方案

照着人家给的示例代码照猫画虎，也算达到效果了：

ads_name ssName, ssTemp;
acedSSAdd(NULL, NULL, ssTemp);

acedSSGet(NULL, NULL, NULL, NULL, ssName);
Adesk::Int32 len = 0;
acedSSLength(ssName, &len);

for (auto i = 0; i < len; i++)
{
    ads_name ent = {0, 0};
    if (acedSSName(ssName, i, ent) != RTNORM) continue;

    AcDbObjectId idEnt = AcDbObjectId::kNull;
    acdbGetObjectId(idEnt, ent);
    
    AcDbEntity *pEnt = NULL;
    if (acdbOpenAcDbEntity(pEnt, idEnt, AcDb::kForRead) != eOk) continue;
    acedSSAdd(ent, ssTemp, ssTemp);

    pEnt->close();
}
acedSSFree(ssName);
acedSSSetFirst(ssTemp, NULL);

acedSSFree(ssTemp);

注意启动命令要设置为 ACRX_CMD_REDRAW | ACRX_CMD_USEPICKSET，acedSSSetFirst 可以控制加点或者选择的显示，但要注意注册命令的参数。

acedRegCmds->addCommand(_T("xxxxxx"), _T("xxx"), _T("xxx"), ACRX_CMD_TRANSPARENT | ACRX_CMD_USEPICKSET | ACRX_CMD_REDRAW, function);

基于LRU的缓存算法实现

奇瑞万达业务上需要下拉框有记忆功能（即下拉框顺序需要以 最近最少使用 的原则去缓存），在 LeetCode 中也有类似的题目（146. LRU 缓存）。

题目描述

请你设计并实现一个满足 LRU (最近最少使用) 缓存 约束的数据结构。

实现 LRUCache 类：

• LRUCache(int capacity) 以 正整数 作为容量 capacity 初始化 LRU 缓存
• int get(int key) 如果关键字 key 存在于缓存中，则返回关键字的值，否则返回 -1 。
• void put(int key, int value) 如果关键字 key 已经存在，则变更其数据值 value ；如果不存在，则向缓存中插入该组 key-value 。如果插入操作导致关键字数量超过 capacity ，则应该 逐出 最久未使用的关键字。

函数 get 和 put 必须以 O(1) 的平均时间复杂度运行。

示例：

输入
["LRUCache", "put", "put", "get", "put", "get", "put", "get", "get", "get"]
[[2], [1, 1], [2, 2], [1], [3, 3], [2], [4, 4], [1], [3], [4]]
输出
[null, null, null, 1, null, -1, null, -1, 3, 4]

解释
LRUCache lRUCache = new LRUCache(2);
lRUCache.put(1, 1); // 缓存是 {1=1}
lRUCache.put(2, 2); // 缓存是 {1=1, 2=2}
lRUCache.get(1);    // 返回 1
lRUCache.put(3, 3); // 该操作会使得关键字 2 作废，缓存是 {1=1, 3=3}
lRUCache.get(2);    // 返回 -1 (未找到)
lRUCache.put(4, 4); // 该操作会使得关键字 1 作废，缓存是 {4=4, 3=3}
lRUCache.get(1);    // 返回 -1 (未找到)
lRUCache.get(3);    // 返回 3
lRUCache.get(4);    // 返回 4

提示：

• 1 <= capacity <= 3000
• 0 <= key <= 10000
• 0 <= value <= 105
• 最多调用 2 * 10^5 次 get 和 put

class LRUCache {
public:
    LRUCache(int capacity) {

    }
    
    int get(int key) {

    }
    
    void put(int key, int value) {

    }
};

/**
 * Your LRUCache object will be instantiated and called as such:
 * LRUCache* obj = new LRUCache(capacity);
 * int param_1 = obj->get(key);
 * obj->put(key,value);
 */

引言

记录博主个人使用 OBS Studio 直播的心得体会。

软件简介

截取一段维基百科的概述：

OBS 是一个用于录制和进行网络直播的自由开源软件包。OBS 使用 C 和 C++ 语言编写，提供实时源和设备捕获、场景组成、编码、录制和广播。数据传输主要通过实时消息协议 RTMP 完成，可以发送到任何支持RTMP的软件，包括 YouTube、Twitch、Instagram 和 Facebook 等流媒体网站。

OBS 相比各大平台自己的直播软件功能更强大，也能在几乎所有平台上直播，很多全职主播的直播画面都是通过 OBS 精心调配的

对于我们使用者来讲，需要着重关注它的 开源 特性：

• 开源意味着我们可以免费获取该软件，无需额外投入付出（那些让你付费获取的都是骗子和坏蛋！）
• 这种体量的开源软件通常会有比较稳定的生态，遇到问题可以上论坛提问，也可以根据自己的需求搭配各种第三方插件

基本使用

OBS 下载

万事开头难，OBS 有四种不同的下载途径。

官网下载

从官方网站下载软件虽然很简单，但是我认为这是现代人类上网冲浪的基本修养，请不要在从莫名其妙还带着色情赌博诈骗广告的网站上下载东西了！

进入 OBS官网，选择自己的平台下载即可，这里我也是直接给出下载链接：

steam 下载

前段时间 OBS 登陆了 steam，没听错，你甚至可以在 steam 上下载 OBS Studio：

在 steam 上直接搜索 OBS Studio ，进入页面点击获取即可：

github 下载

作为开源软件怎么能没有大名鼎鼎的 github 呢？github 搜索 OBS Studio 进入 Release 界面，选择自己需要的平台和版本下载最原汁原味的软件安装包：

需要注意的是如果没有魔法，下载速度应该比较慢，如果只是普通使用者不推荐这种下载方式。

清华镜像源下载(推荐)

既然 OBS 是开源软件，但没有魔法下载又很慢，那为什么不问问神奇的 清华大学开源软件镜像站 呢？

搜索 OBS 选择并下载：

画面推流

直播间优化

第三方插件推荐

模糊/Blur

• 插件地址：
• 官方文档：

输入叠加/Input Overlay

• 插件地址：https://obsproject.com/forum/resources/input-overlay.552/
• 官方文档：https://github.com/univrsal/input-overlay/wiki

简易时钟挂件/Mc-Clock

• 插件地址：https://stock.mooncape.net/others/268/

ダウンロードせずに使える「OBS用デジタル時計」をオンライン上に設置しました。

htmlの書き換えが不要な場合は以下のURLをOBSで読み込んでご利用ください。

ダウンロード版はこちら

• clock01 ： [https://stock.mooncape.net/mc-clock/clock01](https://stock.mooncape.net/mc-clock/clock01)
• clock02 ： [https://stock.mooncape.net/mc-clock/clock02](https://stock.mooncape.net/mc-clock/clock02)
• clock03 ： [https://stock.mooncape.net/mc-clock/clock03](https://stock.mooncape.net/mc-clock/clock03)
• clock04 ： [https://stock.mooncape.net/mc-clock/clock04](https://stock.mooncape.net/mc-clock/clock04)
• clock05 ： [https://stock.mooncape.net/mc-clock/clock05](https://stock.mooncape.net/mc-clock/clock05)

英雄联盟直营服账号数据展示/LoboBot

• 插件地址：https://lobobot.com/
• 官方文档：https://lobobot.com/help

Creating a League of Legends box

1. Go to /lol
2. Add your League Of Legends account. You must change your profile icon with the one provided by LoboBot.

1. 进入游戏 /lol
2. 把游戏头像换成这个狼人模样以完成 LoboBot 对你账户拥有权的验证

3. If all goes well, you will see a message saying that your account has been added successfully.
4. Click on the account and you will see a both queues (Ranked Solo and Ranked Flex). Select the queue you want to show.

3. 如果一切顺利，你会看到一条账户添加成功的信息
4. 点击账户你会看到 单/双排位 和 灵活组排 的战绩，选择你想展示的战绩

5. Click on the desired box, customize it and finally click on the Create Box button.
6. Use the link to add the box to your stream.

5. 选择你喜欢的 box，客制化后点击 Create Box
6. 通过链接推流到直播间

Adding the box in OBS

1. Once you have created the box, you will see a link to add the box to your stream.
2. Copy the link and create a Browser Source in OBS sources.
3. Paste the link in the URL field. Keep default settings and click on OK.

1. 当你创建 box 之后，你会得到一个用于推流到直播间的链接
2. 在 OBS 中创建一个浏览器源
3. 把刚才 LoboBot 的链接拷贝过来（长度、宽度和位置自己调整）点击确定

后面两种方式我自己没有尝试过，应该都是通过插入浏览器源的方式，故不做翻译了。

Creating a Spotify box

1. Go to lobobot.com/spotify
2. Click on the Connect Spotify button.
3. You will be redirected to Spotify to login and authorize LoboBot to access your account.
4. Once you have authorized LoboBot, you will be redirected back.
5. In options, you can customize the box and finally click on the Save Options button.
6. Use the link to add the box to your stream.

Adding the box in Streamlabs Desktop

1. Once you have created the box, you will see a link to add the box to your stream.
2. Copy the link and create a Browser Source in Streamlabs Desktop sources.
3. Paste the link in the URL field. Keep default settings and click on OK.

自定义 Spotify 音乐播放器

之前在看瓦的pov时候很多主播都用了这个，苦苦查了很久终于在油管上找到了定制教程 The BEST Now Playing Music Widget For Your Stream! (Spotify & YouTube Music)：

注册 6klabs

• 网站链接：https://6klabs.com/

选择 Twitch 或者 Google 账号进行登录：

选择 Accounts & Apps 链接 Soptify。

链接 Soptify

Create Your App

This is a step-by-step tutorial on how to create your Spotify app and link it to 6K Labs.

1. Visit the Spotify Developer Dashboard
2. Click on Log in in the top right

这是手把手教你如何创建自己的 Spotify 应用并链接到 6K Labs。

1. 访问 Spotify 的 Developer Dashboard

2. 点击右上角的 Log in 登录自己的 Spotify 账号

3. Once logged in, click on your name. A dropdown appears. Click on Dashboard.

3. 登陆后点击自己的用户名，选择 Dashboard

4. Create a new app by clicking on Create app

4. 点击 Create app 创建一个新的应用程序

5. Enter this information, then click on Save

• App Name: Amuse Widget
• App description: This is an app for the 6K Labs Amuse widget.
• Redirect URI: https://api.6klabs.com/api/spotify/callback

5. 输入以下信息并点击保存：
   • App Name：随便填一点
   • App description：随便填一点
   • Redirect URI: https://api.6klabs.com/api/spotify/callback

前面两个可以随便填，第三个 URL 必须填上面 6klabs 的这个链接

6. Click on Settings

6. 点击设置 Settings

7. Click on View client secret

7. 点击 View client secret

8. Copy and paste the Client ID and Client Secret into the Amuse Spotify App form

8. 复制粘贴 Client ID 和 Client Secret 到之前的 6KLabs 链接界面

9. Click on “Connect” and approve the app.

10. Enjoy! ✨

9. 点击 Connect 链接应用程序
10. ok了 ✨

Troubleshooting

1. INVALID_CLIENT: Invalid client

   In the event that you click on Connect and receive the INVALID_CLIENT: Invalid client error, this could indicate an incorrect Client ID. Please ensure to verify the correctness of your Client ID.

2. INVALID_SECRET: Invalid client_secret

   In the event that you click on Connect and receive the INVALID_SECRET: Invalid client_secret error, it suggests that your Client Secret may be incorrect. Please ensure to verify the correctness of your Client Secret.

3. INVALID_CLIENT: Invalid redirect URI

   In the event that you click on Connect and receive the INVALID_CLIENT: Invalid redirect URI error, it implies that the Redirect URL you entered in step 3 may be incorrect. Please ensure to verify the correctness of your Redirect URL.

自定义 Widgets

心率展示

Garmin

心率显示对于佳明设备来说比较简单，在 ConnectIQ 中下载应用程序 HypeRate，之后打开手表就会广播一个你设备心率的网站地址：app.hyperate.io/xxxxx。

把这个网址放到 OBS 的浏览器源自己调整即可。

Xiaomi

小米我没有相应设备，网上搜到一篇文章仅供参考：直播实时显示心率（OBS-HeartRate）

常见问题整理

黑屏无法捕获

部分笔记本使用了混合输出技术，需要把 OBS 设置为核显输出才能正确捕获内容。

引言

记录博主个人使用 OBS Studio 直播的心得体会。

软件简介

截取一段维基百科的概述：

OBS 是一个用于录制和进行网络直播的自由开源软件包。OBS 使用 C 和 C++ 语言编写，提供实时源和设备捕获、场景组成、编码、录制和广播。数据传输主要通过实时消息协议 RTMP 完成，可以发送到任何支持RTMP的软件，包括 YouTube、Twitch、Instagram 和 Facebook 等流媒体网站。

对于我们使用者来讲，只需要关注其中三个关键词：开源、录制 和 直播。

基本使用

OBS 下载

直播间美化

常见问题整理

引言

R3nzskin 这个项目我关注了小半年，也算是见证了这个开源项目的兴衰。深夜有感，决定写一篇博文来记录一下我的所见所闻，也希望能给其他开源项目和开发者一些启发和经验。

与 R3 的邂逅

我本人是游戏《英雄联盟》(League of Legends) 的狂热玩家，从大学开始就很喜欢玩这个游戏，也从中收获了很多快乐。

然而秉持着 “差生文具多” 的原则，我在腾讯代理的国服和拳头公司的直营服都为英雄买了很多皮肤，但我并没有足够的经济能力去购买所有我想要和喜欢的皮肤，恰好听闻现在有许多 “换肤” 软件可以使用（老玩家的话可能知道以前的多玩盒子），便踏上了使用换肤软件的道路。

最开始我找到的是大名鼎鼎的 LOLskin：

坦诚来说，它的使用并不方便，但是有如此海量的皮肤选择对于我而言已经足够了，更何况这个换肤软件本身就是免费的，我的钱包也终于能松一口气。

然而 LOLSkin 有一个问题：每次游戏版本更新它都必须重新从官网去下载，国服玩家还必须在更新后去等官网的 .1 版本，还是比较繁琐的。作为懒人代表，我把目光放到了淘宝，寄希望于消费获取比较稳定不需要每个游戏版本都要重新折腾的换肤软件。

淘宝网上这类换肤盒子软件眼花缭乱，我尝试了两个买量比较多的店铺，使用上还是比较复杂。共性上两款软件都需要通过远程服务器验证后才可以使用，付费模式就是购买体验卡包月、季、年这样，换肤模式仍是游戏开始前提前手动选择好需要的皮肤。 这种模式我也不是很喜欢，所以还是换回了 LOLskin 使用，同时也逛逛相关的帖子看看有什么比较好的换肤软件。

转机在有一天某位吧友提到了 R3nzskin 换肤效果不错，我就去搜索了一下：

居然还是开源项目，作为程序员那必须上手体验一番了。

从使用者到布道者

C++ 大师侯捷在《Effective C++》中曾经提到，许多新技术得以推广应用，除了发明者的辛劳付出，也离不开许多布道者用通俗易懂的方式去教授讲解。

本着开源共享的精神，我找到了 R3nzskin 的贴吧，发了一篇手把手教如何使用 R3nzskin 的教学帖：

截止到写这篇博文为止，这个教学贴拥有 21w 阅读量、658 条回帖以及 227 个点赞，可以肯定的是这个帖子帮助了很多和我一样的人，并且让这个开源项目能够被更多人所熟知。

不仅如此，事实上我也花了一个下午去做了详细的使用教学视频投稿到 bilibili，然而不到半个小时审核就把我的视频下架了，理由是破坏计算机安全：

不过吧主制作了类似的视频用以教学，只是我的视频第一次下架的理由是涉及宣传和广告还是令人啼笑皆非，一个开源软件又哪里有广告呢？

更多的信徒

随着许多朋友的共同努力，R3 在换肤已经小有名气，我有时间也会解答许多朋友遇到的常见问题例如缺失 dll、版本不匹配等等。有人在吧里收集皮肤 bug 提 issue，也有开发直接提交 pr 帮助完善这个项目，我自己也抽时间看了一些项目的源码，但逆向这块技术栈确实不太了解而且工作比较忙，所以后面就没再研究了。

项目中也加入了国人开发者 rainzee 支持国服版本，总之似乎一切都在向好的方向去发展。

与此同时淘宝店家自然不能放过这种赚钱的机会，他们把 R3 免费开源的软件套壳成之前那种需要服务器远程验证付费的样子去倒卖给那些无知的人，吧里也出现了一些倒狗。

大洪水

R3 很快被腾讯盯上了，也可以理解，毕竟断人财路如杀人父母，皮肤可以说占这个游戏 95%+ 的收入都不为过，在国服换肤自然不可能放过（使用 LOLSkin 也有一定概率受到处罚）。 很多人开始抱怨不能在国服使用，但也只是埋怨腾讯，而且恰逢当时拳头直营的台服刚开服，所以许多人跑去外服接着用，也没什么大问题。

大洪水源自 R3 项目原作者需要服兵役，可能未来不会频繁更新项目。

许多朋友感到惋惜，这么好用的软件以后没有人维护，我也给作者发了一封邮件去交流这个项目关于技术上的一些问题，看能不能接手下来继续维护，但是作者一直没有回复我，只好作罢。

一部分开发者开始自救，在 R3 的基础上创建仓库开始自己维护这个项目，其中不乏上面的淘宝店家混入其中推广自己套壳的付费换肤。

最后一根稻草

压死骆驼的最后一根稻草是拳头的一次更新（v13.5），这次更新让之前用旧版本的 R3 玩家在角色死亡后换肤失效：

无数质疑涌向了 R3，倒狗们宣传着 “自己开发 稳定维护” 的套壳 R3，许多人转而投向这些倒狗的怀抱，同时控诉着 R3 不作为。

农夫与蛇

R3 后续还是更新了，但是存在使用时严重掉帧的问题，不能像之前一样正常使用。

R3 的国服开发者 rainzee 加入了 R3 贴吧，决定把自己改过的不掉帧稳定的修改版本分享给大家，但出于对套壳奸商的警惕决定也采用服务器发放许可的方式，虽然许可获取是免费的，但这恰恰成为了许多人攻击的源头。

他们认为 rainzee 就是没赚到钱所以不维护 R3 项目的后续，将开源分享的精神理念和和心怀感恩体谅的情感抛之脑后，对参与 R3 项目的开发者当作倒狗肆意谩骂，更有甚者对着那些主动无偿维护、自愿汉化的贡献者谩骂侮辱，这可能是我自参与开源社区以来见到的最荒谬的事情了。

理想主义之死

他们赢了，他们也输了。

rainzee 发了声明，选择离开了这里，又一位理想主义者离我们而去，也让我想起之前看到的 开源人宣言：

开源人宣言 - Open Source Fans Manifesto

我们是一群开源的爱好者与信仰者，我们相信：开源代表着一种向善的力量！作为一场席卷全球的世界性运动，20 多年来的历史证明，开源不仅仅能够孕育最新的技术、创造更好的软件，更能够帮助这个世界变得更好。

开源精神

剖析开源的内涵，理解开源的精神，能够让我们理解，为何开源能够让世界变得更好。在我们看来，开源的精神体现在以下一些方面：

分享（Sharing）

当一个软件工程师写出一个不错的软件，他不会敝帚自珍，不会故步自封。他乐于分享，是因为他相信：这个软件可能会对别人也有帮助，更会有人帮助他，一起做出更好的软件。西谚有云：赠人玫瑰，手留余香。我们都相信：乐于分享是一切善举的开端。

开放（openness）

在很多方面，开放都非常重要。不仅仅是开放源代码，更包括公开透明的社区。这样的社区能够吸引更多的朋友加入。也能够帮助新来者，理解并认同社区规则。还能够促进监督以提升社区运行的程序正义。开放还包括欢迎一切的可能性，开源是世界的，也欢迎来自世界任何一个角落的使用者、参与者和贡献者。中国谚语有云：海纳百川，有容乃大。我们都相信：公开透明是一切良好协作的基石。

平等（Equality）

我们欢迎任何人的任何贡献，我们以统一的标准平等地评审每一次代码或文档提交，我们评审的仅仅是代码或文档本身的质量与价值，而不是以贡献者的学历、年龄、种族、性别或职位等标准来判断。人皆生而平等，所以我们都相信：对于平等的追求是社区健康的保障。

协作（Collaboration）

开源社区的协作，正是从接纳点滴贡献开始的，一个开放的社区，崇尚开放式的协作。这样的协作，不会在整个群体达成所有共识之后再开始，而是欢迎来自每一个人的一点一滴的改进。中国古语有云：不积小流，无以成江海。我们都相信：开放式协作，逐步凝聚共识是社区繁荣的秘诀。

创造美好世界（Build a better world）

每一位投身开源的朋友，都或多或少是理想主义者。我们都相信：这个并不完美的世界，理应变得更好。我们都相信：通过自己掌握的技术，借助开源的方法，能够把这个世界变得更好。我们更加相信：开源的精神内涵，应该被推广到更多的领域。因为：创造更加美好的世界，是开源的终极追求。

行动倡议

开源社区的朋友都相信从我做起的力量，因此，我们发出如下行动倡议：

推而广之（Advocate widely）

我们应该更加努力的向大众传播开源的理念与精神，让更多的人接受开源的理念，成为开源的同道中人。我们还应该在开源软件、开源硬件之外的领域，推广开源的实践，不仅仅是开放源代码，还应该开放数据、开放知识、开放一切可以帮助这个世界变得更好的知识与经验，让更多的行业、更多的群体，都接纳开源，成为开放式协作的受益者。

互帮互助（Help each other）

我们应该帮助更多的开源项目，不断发展成长。帮助各个开源社区，把社区的力量团结起来，共同协作。我们还应该防止开源的含义被滥用或曲解。我们要阻止割裂，反对人为设置的障碍，反对任何附加歧视条款的“伪开源”，确保开源始终是一项惠及全球的事业。

立即行动（Just do it）

每一个人都可以参与开源，而不是只有大咖才能做到。我们可以从翻译或撰写文档，纠正拼写做起，为代码除错，审核代码，提交代码，志愿支持开源活动，我们还可以布道演讲，吸引更多的朋友加入。

我不知道这样的环境之后还会有多少开源项目会因此毁掉，我只知道拥抱开源共享的理念和心怀感恩体谅的情感目前还为时尚早。

引言

最近一段时间，AI 技术的进步则让代码补全有了更上一层楼的机会。接下来，我们为大家介绍的 Github Copilot 就是这样一款基于 AI 的代码补全工具。

我们编程时写出的代码，在未编译前通常以纯文本格式存在。因此，实际上我们能使用任何文本编辑器来编写代码，包括系统自带的记事本。但是，好的工具能够让我们事半功倍。面对复杂的工作任务，我们需要 IDE（集成开发环境）这样的生产力工具。IDE 本质上就是更高级的文本编辑器，集成了许多人性化功能来提升效率，比如：自动补全变量，提示可能会用到的函数列表，语法高亮，显示语法错误等等。

IDE 本身也在不断进化。我的第一门使用 IDE 的编程语言是 Java，使用的是 Eclipse，当时自动补全功能还比较简陋，局限于符号的提示与选单，我也没有对 IDE 究竟有多强大建立起概念。后来，开始学习开发框架后，我慢慢接触到 JetBrains 出品的 IDEA。IDEA 的提示更智能，例如：可以在数组后输入「.for」自动构成 foreach 循环，也可以使用快捷键自动生成 Getter/Setter、构造函数、重载函数等等。毫无疑问，JetBrains 系列产品为编码工作带来了更高的效率，提供了更加全面、智能的补全功能。

GitHub Copilot 是什么

Github Copilot 是 GitHub 和 OpenAI 合作开发的人工智能工具，可以在编辑代码时帮助你自动生成可能会需要的代码。

GitHub Copilot 能够提取代码上下文，给出整行代码或整个函数的补全建议。它可以帮助我们完成下列任务：

• 将注释转化为代码；
• 自动填充重复代码；
• 编写测试；
• 快速发现解决问题的替代方法；
• 无需网络搜索即可快速探索新的 API；
• 适应用户编写代码的方式，帮助用户更快地完成工作。

原理是什么？

我们先介绍一下 GPT-3。GPT-3（Generative Pre-trained Transformer 3）是一个用于处理自然语言的 AI 模型，由 OpenAI 训练开发。GPT-3 通过阅读几乎一切人类可阅读的内容来进行训练，理论上，它能够完成一切通过语言完成的工作，而且完成效果还非常接近人类。已经有实验证明 GPT-3 可用于撰写文章、回答问题、编写代码生成应用程序、设计表格、开发游戏、将文字描述便携为成型的网页等等。

而 OpenAI Codex 则是基于 GPT-3 开发的一款针对编程所设计的 AI 模型。Codex 从公共代码仓库学习人类编写的代码，其代码来源包括 Github 上的公共代码仓库。官网原文如下：

OpenAI Codex is a descendant of GPT-3; its training data contains both natural language and billions of lines of source code from publicly available sources, including code in public GitHub repositories. （OpenAI Codex 是 GPT-3 的衍生项目；它的训练数据包括自然语言和数以亿计来自公开可用来源的源代码，其中包括 Github 公开仓库的代码。）

最后，GitHub Copilot 则是使用了 Codex 进行研发的一款商业产品。Github 将算法进行包装，做成了插件和网页，进行应用分发。现在 GitHub Copilot 支持在 Visual Studio Code、Visual Studio、JetBrains Rider 上通过插件形式集成进 IDE，以便我们使用。

使用 & 体验

要想使用 GitHub Copilot，首先需要注册一个 Github 账号。有了帐号后，按下面的步骤可以找到并启用 GitHub Copilot：

1. 找到设置页面：在任何页面的右上角，单击个人资料照片，然后单击“设置”。

2. 找到 GitHub Copilot 设置页面：在边栏的「代码、规划和自动化」部分，单击「GitHub Copilot」。

3. 启用 GitHub Copilot：在 GitHub Copilot 设置页面上，单击「启用 GitHub Copilot」。

4. 选择付费方式（月付/年付）：GitHub Copilot 可以免费试用 60 个自然日，随后需要以 $10/月 的价格订阅。如果你是学生的话，可享受教育优惠，免费使用 GitHub Copilot。

在 Rider IDE 进行设置

1. 在偏好设置里安装 Github Copilot Plugin；
2. 重启 IDE；
3. 登陆 Github 完成验证。

设置完成后，IDE 提示可以使用「Tab」来自动补全代码，使用「⌥ + ]」或者「⌥ + [」来选择其他候选的补全选项。

体验如何

在编写代码的过程中，Github Copilot 会自动提示可能的补全方案，此时按下「Tab」即可完成补全。

有时，AI 并不会一次给出完整的提示代码，例如，图示的代码就并非一次性生成的，而是逐行自动补全，最终生成了一个可以实际使用的函数（甚至包括注释）。下图的例子在 Unity3D 中绘制了一条射线用于检测前方是否有物品，只有第一行注释是我写下的。

下面的例子很有趣：当我尝试把乐谱的音高编写成数组时，Github Copilot 也给出了他所理解的音乐：

在这样的例子中，对重复的流行乐片段，Github Copilot 有时可以给出不错的答案。比如预先输入《卡农》的重复性模进片段，Github Copilot 往往可以完全正确地补全乐谱。可见，在面临重复性较高的功能开发，或是使用一些常用的算法时，依靠 AI 补全是一个称得上非常可靠的选择。不过，如果需求非常复杂，大部分情况下，它并不能独立地给出完美的解决方案。GitHub 团队在对一组 Python 函数进行基准性测试后发现尝试十次后，大约 57% 情况下可以给出正确的答案。部分情况下，Github Copilot 也会给出无法通过编译的代码。

Github Copilot 的不足之处

使用 Github Copilot 很久后，Reddit 大佬 Colin Eberhardt 指出了几点不足：

1. Github Copilot 很多时候响应得不够快。虽然它已经快到秒出答案，但这对快速输出状态的程序员来说仍然是不够的。要么它的提示还没出现你就继续输入了，要么你会因为等它而暂时停下思路。
2. Github Copilot 总是会自动提示。这种提示和输入存在冲突：有时，当你需要等等看提示怎么说另一些时，会不断有内容弹出，接着消失。或许，自动模式并不是 Github Copilot 的「最佳打开方式」？
3. Github Copilot 生成代码质量不足。它生成的代码可以满足大部分简单且重复的功能需求，但对于熟练的程序员，可能会额外浪费很多精力来校验它自动生成的代码是否正确。

Github Copilot 版权问题

许多人指出 Github Copilot 会使用有版权的代码作为提示内容（参见 Jacob Crume 的文章“GitHub Copilot is Now Available for All and Not Everyone Likes It”）。少数派作者 100gle 在《GitHub Copilot：革命未竟，未来可期》中更是举出了很多例子。最为出名的莫过于，如果你在编辑器中输入 Fast inverse square root，便会得到一段代码，它和当年《雷神之锤》使用的算法完全一致。

现代开源软件多使用 GPL （GNU General Public License）协议，这个协议要求你也将代码开源，且使用 GPL 协议。而通过 Github Copilot 补全时我们并不确定这段代码的作者为它指定的协议。开源许可证的主要作用是对软件的使用、复制、修改和再发布等进行限制。而显然使用 AI 补全显然会破坏这一点。

可以预见的是，同当今各种 AI 作画工具面对的种种争议一样，Github Copilot 也一定会因为版权问题，难以被大型企业所用，至少短期内如此。

使用建议

• Github Copilot 能帮助初学者面对不那么熟悉的编程语言或开发框架时，快速学习常用的接口调用方式和简单的实现方案。这意味着我们可以不用为了某些基础问题反复翻找 API 手册，或体验 CSDN 这样的技术博客网站的层层传送门。
• Github Copilot 可以帮助我们在不熟悉的领域快速上手，只需要一些注释便可快速生成部分业务逻辑，然后进行测试。当然，最终代码的可靠性还是需要开发者人为辨别和控制。
• Github Copilot 可以在重复性劳动时显著提升效率。比如你需要写一大堆单元测试，它们无法靠复制/粘贴批量生成，同时有一些细微的逻辑变化需要处理。又或是你需要开发一些重复性功能，比如批量声明一些数据类型好几十次。这时 Github Copilot 补全的代码往往很可靠。

总结

Github Copilot 或许并不能承载类似“AI 即将取代程序员”的想象，但在当下，它无疑是程序员的好帮手。作为辅助，它提供的补全并没有智能到让完全不会编程的用户完成开发，但也并不只是简单的提示工具。合理运用 Github Copilot 能够为开发者的学习成长带来很大帮助。

与此同时，它不可避免地存在一些缺陷，代码的版权问题也限制了它商业化的应用前景。不够熟练的程序员可能也会对它失望——就像它名字中的 Copilot 一样，Github Copilot 更接近优秀的副驾驶角色，但工作总归还是需要一位优秀的主驾驶领导。

最好的旅行靴已经送到我们手中，走出什么样的路还需要开发者自己去定夺。

引言

Jetbrains 全家桶开发还是比较顺手的，但工作之后学生认证到期了，所以需要重新激活，特此写一篇博文记录自己使用 Jetbrains 产品的各种激活方式。

需要提前声明，Jetbrains 也提供了社区版供学生和初学者使用，本文仅作激活操作记录，使用激活的软件请勿用作商业用途，如有条件请务必支持正版购买许可证。

学生认证

Github 的学生认证可以通过上传学校信息的方式获取正规免费的许可，在 Unity Student Plan 申请指南 这篇文章有详细操作。

如果是在读学生，完全可以用这种方式激活 Jetbrains 相关产品。

注册机激活

不推荐这种激活方式。

之前我使用这种方式激活，因为之前有一些相关文件未删除，会导致整个软件闪退无法使用，在 Mac 上折腾了很长一段时间。

服务器激活

先打开这个网站：https://search.censys.io/

然后搜索框输入：

services.http.response.headers.location: account.jetbrains.com/fls-auth

选择第一个搜索结果，右击进去：

将网址到 Jetbrains，选择许可证服务器 /License server，粘贴刚刚复制的网址 http://134.53.225.196，激活。

大功告成，顺带一提，这个好像是迈阿密大学的服务器……