Evolutionary architecture and emergent design: Using reusable code, part 2nd

Introduction: After using the evolutionary architecture and emergent design in the technical discovery code described in the prior installments of the emergency design, you need a way to get and take advantage of these design elements next. This article describes two ways to get idiomatic patterns: Capturing patterns as APIs, and using meta programming methods.

The previous installments of this series focused on the obvious first step in emergent design: discovering idiomatic patterns. After discovering idiomatic patterns, what do you want to do with it? The answer to this question is the focus of this issue, which is part of the second installment of a series of articles composed of several parts. Part 1th-discussion of the relationship between code and design-introduces the theoretical basis of an idea that the design of software really refers to the entire source code of the solution. Once you have translated all your code as a practical design, you can begin to consider consolidating design elements at the language level, not just in the chart scope and other design-assisted projects. Here I want to talk about what to do after discovering reusable designs in your code, and describe the methods used to get these patterns. I first get them as simple APIs, and then describe a way to get these elements to differentiate them from other code.

To get patterns as APIs

The easiest way to capture idiomatic patterns is to extract them as their own APIs or frameworks. Most of the open source frameworks that you use are set of idiomatic patterns that are related to resolving specific problems. For example, the Web framework contains all the API elements that you need to build a Web application, which are available in advance from other running Web applications. For example, Spring is a collection of technical idiomatic patterns for handling dependency injection and construction, Hibernate for object-relational mapping encapsulation patterns.

Of course, you can do the same work in your code. This is the easiest way to date, because you are only changing the structure of the code (usually by refactoring the support in the IDE you choose). A number of examples of this approach are shown in part 1th and "language, expressiveness and Design: Part 2nd", which explores design patterns.

Avoid structural duplication

APIs occasionally facilitate structural duplication. Using APIs can be annoying because you have to use host objects frequently to invoke the API. Here's a look at the example in Listing 1, which calls an API related to trams:

Listing 1. Access the car API

Car2　car　=　new　CarImpl();
MarketingDescription　desc　=　new　MarketingDescriptionImpl();
desc.setType("Box");
desc.setSubType("Insulated");
desc.setAttribute("length",　"50.5");
desc.setAttribute("ladder",　"yes");
desc.setAttribute("lining　type",　"cork");
car.setDescription(desc);

Forcing a user to enter a host object (DESC) adds unnecessary interference to the code. Most APIs include host objects and use them as entry points for APIs that you must carry to access the API.

There are several ways to mitigate this problem in APIs. One approach uses a little-known Java syntax that allows you to define "carry" host objects through the scope of an anonymous inner class, as shown in Listing 2:

Listing 2. Use an anonymous inner class to carry host objects

MarketingDescription　desc　=　new　MarketingDescriptionImpl()　{{
　　 setType("Box");
　　 setSubType("Insulated");
　　 setAttribute("length",　"50.5");
　　 setAttribute("ladder",　"yes");
　　 setAttribute("lining　type",　"cork");

}};