6.1 Scenario Problems

6.1.1 Application Framework for Exporting Data

Consider a practical application: implementing an application framework for exporting data that lets customers choose how to export data and actually perform the data export.

In some practical enterprise applications, a company’s system is often scattered in many different places, such as branches or stores. The company does not have the strength to establish the whole company private network, but it is not willing to let the business data transfer in real time on the WAN, one is to consider the data security, the other is the problem of running speed.

Such systems usually have a compromise, that is, each branch of the system is independent, is run in their own branch of the LOCAL area network. At the end of every day, each branch company will export its own business data, and then package the business data and send it to the head office over the network, or send the data to the head office by special personnel, and then the head office will conduct data import and accounting.

Usually such systems have some conventions for exporting data, such as text format, database backup format, Excel format, Xml format, etc.

Now consider implementing such an application framework. Before we continue, let’s learn a little bit about frameworks.

6.1.2 Framework basics

1. What is a frame

Simply put, a framework is a piece of half-finished software that performs certain functions.

By its very nature, a framework is software, and a half-finished piece of software at that. The so-called semi-finished product is not fully realized the user needs the function. The framework is only a part of the functions that users need, and it needs further processing to become a complete software that meets users’ needs. So frame-level software, its primary customers are developers, not end users.

extension

Some friends will think, since the framework is only a semi-finished product, why to learn and use the framework, the cost of learning is not small? It is because the framework can do certain things that the “framework has done certain things” attract developers to learn and use the framework.

2. What a framework can do

  • Can complete certain functions, speed up the application development progress.

Because the framework performs certain functions, usually basic, difficult, and generic, it avoids the need to completely start from scratch when developing an application. Instead, it builds on the existing functions of the framework. In other words, it reuses the functions of the framework, thus speeding up the development of the application.

  • Give us a good program architecture.

The framework defines the overall structure of the application, including the division of classes and objects, the main responsibilities of each part, how classes and objects work together, and the control flow.

Popular frameworks in the Java world, mostly written by great masters, are well-designed. Development based on such a framework generally follows the structure already laid out by the framework, making the structure of developing applications relatively refined.

3. Understanding the framework

  • Developing based on frameworks, things are still the same things, it’s just a matter of who does them.

The relationship between the application and the framework can be briefly depicted in a diagram, as shown in Figure 6.1.

Figure 6.1 shows a simple relationship between the application and the framework

If there is no framework, then all the functions required by the customer are developed by the developers themselves. No problem, the same functions required by the user can be implemented, but the developers work more.

If there is a framework, the framework itself to complete a certain function, then the framework of the existing function developers can not do, developers only need to complete the framework does not have the function, the last is also to complete the customer requirements of all functions, but the developer’s work will be reduced.

In other words, based on the framework, the software does not change the function, the customer requested all functions, that is, “things are still those things” meaning. But with the framework, the framework completes part of the function, and then the developer completes part of the function, and finally the framework and the developer combine to complete the function of the whole software, that is, to see who do these functions “.

■ Framework based development, you don’t have to do what frameworks do, but you should understand what frameworks do and how they do it (wen: for example, you need to know how AFN and SDWebImage do it).

In fact, in real development, the relationship between the application and the framework is usually not as clear-cut as described above, and is more interactive. So the application does part of the work, the framework does another part of the work, and then the application does another part of the work, and the framework does another part of the work.

Interleaved, the application and framework are finally assembled to fulfill the user’s functional requirements.

Also illustrated with a schematic diagram, as shown in Figure 6.2.

Figure 6.2 Shows the relationship between the application and the framework

Consider this rectangle of applications and frameworks as the final piece of software. If you don’t know what the frame is doing, it’s like a black box to you, like removing two pieces of the frame in Figure 6.2. What do you find? True, the rest of the applications are fragmented and isolated from each other.

extension

This can lead to a fatal problem where you have no idea how the application works, which means the project is out of control for you, which is dangerous from a project management perspective.

Therefore, at the time of development based on the framework, although you can not do do framework, but should understand doing framework, if conditions permit, it should also be clear is how to realize the corresponding function framework, should at least make roughly the implementation approach and the implementation steps of the clear, so that we can control the whole project, whole In order to minimize the situation that the project gets out of control.

4. The relationship between framework and design patterns

1) Design patterns are more abstract than frameworks

The framework is already implemented software, even though it is only half-finished software, but it is already implemented; However, the focus of design mode still lies in the solution to the problem, that is, it still stays at the level of ideas. Design patterns are therefore more abstract than frameworks.

2) Design patterns are smaller architectural elements than frameworks

As mentioned above, a framework is software that has been implemented and implements a range of functions, so a framework often contains applications of multiple design patterns.

3) Frameworks are more specialized than design patterns

Framework is semi-finished software to complete a certain function, that is to say, the purpose of the framework is very clear, is to solve some problems in a certain field, that is a very specific function. Different domains implement different frameworks.

But the design pattern still stays at the level of thought, as long as the corresponding problem is suitable for a design pattern to solve, it can be applied in different fields.

Therefore, the framework is always specific to the domain, while the design pattern is more focused on the idea, method to solve the problem, more universal.

6.1.3 What Are the problems

Analysis of the application framework to be implemented above, no matter what format the user chooses to export, the final export is a file, and the system does not know what kind of file to export, so there should be a unified interface to describe the system finally generated objects, and operate the output file.

First, define the interface of the exported file object. Example code is as follows:

For a business function object that implements exported data, it should create an implementation object of the corresponding ExportFileApi as needed, since the implementation of a particular ExportFileApi is business-specific. But for the business function object that implements the exported data, it does not know which implementation object of the ExportFileApi should be created, nor how.

That is, what if it needs to create a concrete instance of the ExportFileApi for the business function object that implements the exported data, but it only knows the ExportFileApi interface, not its implementation?

6.2 Solution

6.2.1 Use the factory method pattern to solve problems

A reasonable solution to these problems is the Factory Method pattern. So what is the factory method pattern? 1. Definition of the Factory Method pattern Factory Method

Define an interface for creating objects and let subclasses decide which class to instantiate, deferring the instantiation of a class to its subclasses.

2. Applying factory method pattern to solve the problem

A careful analysis of the above problem, in fact, in the realization of business functions of derived data object, don’t know how to use what kind of the export file format, so this object doesn’t should with specific export file object coupling, it only need to export the file object oriented interface.

This, however, creates a new problem: the interface cannot be used directly. You need to use a concrete interface to implement an instance of an object.

Isn’t that a contradiction? Requirements are interface oriented, not coupled to a concrete implementation, but need to create instances of concrete implementation objects of the interface. How to solve this contradiction?

The factory method pattern is an interesting solution, that is, do not solve, take a hands-off approach: don’t need interface objects, then define a method to create; But it doesn’t really know how to create the interface object itself, so it doesn’t matter, it can be defined as an abstract method, so it can be implemented by subclasses, so that the object itself can be programmed to the interface, and it doesn’t care how to create the interface object.

6.2.2 Structure and description of the factory method pattern

The structure of the factory method pattern is shown in Figure 6.3.

Figure 6.3 Schematic diagram of factory method pattern structure

  • Product: Defines the interface of the object created by the factory method, that is, the interface of the object that you actually need to use.

  • ConcreteProduct: an implementation object for the ConcreteProduct interface.

  • Creator: declares factory methods. Factory methods usually return an instance object of type Product and are usually abstract methods. You can also provide a default implementation of the factory method in Creator that returns an instance object of the default Product type.

  • ConcreteCreator: ConcreteCreator object that overrides the factory method defined by Creator and returns a concrete Product instance.

6.2.3 Factory method pattern sample code

(1) The sample code for Product definition is as follows:

(2) The sample code of the Product implementation object is as follows:

(3) Example code for the creator definition is as follows:

(4) Example code for the creator implementation object is as follows:

6.2.4 Use the factory method pattern to implement the example

To implement the example using the factory method pattern, follow the structure of the factory method pattern to figure out which products are created and which Creator is created. Analyzing the required functions, the exported file object interface ExportFileApi is equivalent to Product, and the business function object used to realize the exported data is equivalent to Creator. After separating Product and Creator, you can implement them separately.

The program structure for implementing the example using the factory pattern is shown in Figure 6.4:

Figure 6.4 illustrates the program structure of the example using the factory method pattern

Let’s look at the code implementation.

(1) The implementation of the exported file object interface ExportFileApi has not changed, so I won’t repeat it here.

(2) implementation of ExportFileApi. To simplify the example, only export text file format and database backup file are implemented.

Implement export text file format. Example code is as follows:

Example code for exporting an object as a database backup file is as follows:

Example code for implementing ExportOperate is as follows:

(4) Two Creator implementations were added.

Example code for creating an object exported as a text file is as follows:

Example code for creating an object exported as a database backup file is as follows:

(5) The client directly creates the Creator object to be used, and then invokes the corresponding function method. Example code is as follows:

The running results are as follows:

Export data test data to database backup files

You can also modify the object of client New to switch to another implementation object and see what happens. It seems simple to apply the factory method pattern.

6.3 Mode Description

6.3.1 Understand the factory method pattern

1. The main function of the factory method pattern is to let the parent class complete its own function calls without knowing the implementation. The implementation is deferred to subclasses.

In this way, when designing, you don’t need to worry about the implementation, you need an object, you just need to return it through the factory method, and you still need to use the interface to implement functions using these objects. This is similar to the IoC/DI idea, which will be explained in more detail later.

2. Implemented as an abstract class

In an implementation of a factory method, the parent class is usually an abstract class that contains abstract methods for creating the desired object. These abstract methods are called factory methods.

Pay attention to

One thing to note here is that when a subclass implements these abstract methods, it usually doesn’t actually implement the specific functionality of the subclass. Instead, it chooses the specific product implementation object within the subclass’s methods.

There are usually methods in the parent class that use these product objects to implement certain functions, and the functions implemented by these methods are usually common functions that will always perform correctly regardless of the specific product implementation chosen by the subclass.

3. Implement into concrete classes

You can also implement a parent class as a concrete class. In this case, the default implementation method to get the desired object is usually provided in the parent class, so that it can run even if there is no concrete subclass.

In this case, the specific subclasses are often required to determine how to create objects required by the parent class. Also called factory methods provide hooks for subclasses. With the factory approach, you can have subclass objects override the implementation of the parent class, providing greater flexibility.

4. Factory method parameters and returns

In the implementation of a factory method, parameters may be required to determine which particular implementation to choose. That is, by passing parameters in an abstract method, the subclass implementation selects which concrete implementation object to create based on the parameters.

The factory method returns the interface object of the object being created, but it can also be an abstract class or an instance of a concrete class.

5. Who uses the factory method to create the object

The first thing to figure out here is who is using the factory method to create objects?

In fact, inside the factory method pattern, should be the Creator of other methods in the use of the factory method to create objects, although also can put the factory method to create the object directly used outside a Creator, but the intent of the factory method pattern, is by the Creator object internal method to use the factory method to create objects, that is to say, Factory methods are not generally available for external use to Creator.

The client should use the Creator object, or the object created by Creator. For clients using the Creator object, the factory method creates an object that is used by some Creator method. For objects created using Creator, the objects created by the factory method are part of the objects that the client needs. I’ll give you an example.

1) The client uses the Creator object

For example, for the “business function object that implements exported data” class ExportOperate, it has an export method that uses the concrete “exported file object interface object” ExportFileApi, ExportOperate does not know the ExportFileApi implementation, so how does that work? You define a factory method that returns objects from the ExportFileApi. The export method then uses this factory method to retrieve the objects it needs and perform the function.

What does the client do at this point? In this case, the client mainly uses an instance of ExportOperate to do what it wants to do, in the case of the Creator object. A brief description of the code structure in this case is as follows:

2) The client uses objects created by Creator

The other is when Creator returns to the client the object created by the factory method, which is part of the object that the client needs. A brief description of the code structure in this case is as follows:

prompt

To summarize: In the factory method pattern, the client uses either the Creator object or an object created by Creator. Generally, the client does not use factory methods directly. It is possible to expose the factory methods directly to the client, but this is generally not the case.

6. A diagram of the invocation sequence of the factory method pattern

Because there are two typical cases of a client using the Creator object, the sequence diagram of the calls is also divided into two cases.

Take a look at the sequence diagram for clients using objects created by Creator, as shown in Figure 6.5

Figure 6.5 Client invocation sequence using objects created by Creator

Let’s take a look at the sequence of calls when the Creator object is used by the client, as shown in Figure 6.6.

Figure 6.6 The invocation sequence of the Creator object used by the client

6.3.2 Factory method pattern and IoC/DI

IoC — InversionofControl, InversionofControl. DI — DependencyInjection.

1. How to understand IoC/DI

To understand the above two concepts, it is necessary to understand the following questions:

■ Who are the participants?

■ Dependence: Who depends on whom? Why dependency?

■ Infuse: Who infuses whom? What exactly is injected?

■ Inversion of control: Who controls whom? Control what? Why is it called a reversal?

■ Are DI and INVERSION of control the same concept?

Here are some brief answers to these questions, so that you can understand IoC/DI.

(1) Who are the participants: Generally, there are three participants, one is an object; Another is the IoC/DI container; another is an external resource for an object.

explain

To explain the noun, an object is an arbitrary, ordinary Java object; The IoC/DI container simply refers to a framework used to implement IoC/DI functions; The external resources of an object refer to the resources needed by the object, but obtained from the outside of the object. They are all called resources, such as other objects needed by the object, or file resources needed by the object.

(2) Who depends on whom: Of course some object depends on IoC/DI container.

(3) Why they need dependencies: Objects need IoC/DI containers to provide external resources needed by objects.

(4) Who injects whom: It is obvious that the IoC/DI container injects an object.

(5) Exactly what to inject: it is to inject the external resources needed by an object.

(6) Who controls whom: The IoC/DI container controls objects, of course.

(7) Control what: mainly control the creation of object instances.

(8) Why is it called a reverse: a reverse is relative to a forward, so what is a forward? If you were to use C in A regular application, what would you do? It is, of course, directly creating objects of C, that is, actively obtaining the external resource C needed in class A, which is called positive. So what is the reverse? Instead of actively fetching C, class A passively waits for the IoC/DI container to fetch an instance of C, which is then injected back into Class A.

Let me illustrate this with a legend.

Take A look at the schematic diagram of C for A regular class A without IoC/DI, as shown in Figure 6.7.

Figure 6.7 schematic diagram of A regular class A using C

When an IoC/DI container is in place, class A no longer actively creates C, as shown in Figure 6.8.

Figure 6.8 Class A no longer actively creates C

Instead, it waits passively for the IoC/DI container to acquire an instance of C and then inject it backwards into class A, as shown in Figure 6.9.

FIG. 6.9 Application structure with IoC/DI container (9) Are dependency injection and inversion of control the same concept?

It should be obvious from the above that DI and INVERSION of control are two different descriptions of the same thing. In a way, they describe things differently. Dependency injection (DI) is described from the perspective of an application program. It can be described as a complete point: an application program relies on the container to create and inject the external resources it needs; Inversion of control is described from the perspective of the container. The complete description is that the container controls the application, and the container inversely injects the external resources it needs into the application.

extension

Summary: In fact, the biggest change IoC/DI brings to programming is not in the code, but in the thinking, the “master and slave” change. The application used to be the boss, taking the initiative to acquire whatever resources it wanted, but in IoC/DI thinking, the application became passive, waiting for the IoC/DI container to create and inject the resources it needed.

Such a small change is actually a big step forward in programming, effectively separating the object from the external resources it needs, making them loosely coupled, facilitating functional reuse, and more importantly, making the overall architecture of the program very flexible.

2. Relationship between the factory method pattern and IoC/DI

In a way, the factory method pattern is similar to the idea of IoC/DI.

As mentioned above, with IoC/DI, the application is no longer active, but passively waiting for resources to be injected by the container. When writing code that uses an external resource, it opens a window for the container to inject in, which is the injection method provided to the container. This is not our focus, so we won’t go into detail.

Example code for interface C is as follows:

As can be seen from the above example code, now when writing code in A, whenever there is A need for external resources, then provide the way to inject from the external injection, their own use of these objects.

Take a look at the factory method pattern, which implements the same functionality above. To distinguish them, they are named A1 and C1. Instead of A1 fetching the C1 object, it creates a factory method, similar to an injection method. Then the subclass, let’s say A2, gets the C1 object, and when it calls it, it replaces the corresponding method on A1, which is equivalent to injecting back into A1. Example code is as follows:

Example code for subclasses is as follows:

The C1 interface is the same as the previous C interface, and the C2 implementation class is also empty for demonstration purposes, so I won’t show their code.

prompt

Looking closely at the above examples and comparing their implementations, especially at the ideological level, the factory approach pattern is similar to IoC/DI in that both are “active to passive”, with “master-slave transposition”, resulting in a more flexible program structure.

6.3.3 Parallel class hierarchies

1. Implications for parallel class hierarchies

To put it simply, if there are two class hierarchies in which each class in one class hierarchy has a corresponding class structure in the other class hierarchy, it is called a parallel class hierarchy.

For example, there are many kinds of hard disk objects, such as divided into desktop hard disk and notebook hard disk. In the concrete implementation of desktop hard disk, there are Seagate, Western digital and other different brands, and in the notebook hard disk, there are Seagate, Hitachi, IBM and other different brands. A hard disk object has its own behavior. For example, a hard disk can store or obtain data from a hard disk. Different hard disks have different behavior objects because different hard disks implement different behaviors. If the hard disk object and the behavior of the hard disk object are described separately, the structure shown in Figure 6.10 is formed.

Figure 6.10 Parallel class hierarchies A hard disk object is a class hierarchy, the behavior of a hard disk is a class hierarchy, and the classes in the two class hierarchies are corresponding. The desktop Seagate hard drive object corresponds to the desktop Seagate hard drive behavior in the hard drive behavior; The notebook IBM disk corresponds to the behavior of the notebook IBM disk, which is a typical parallel class hierarchy.

What is this parallel class hierarchy for? It is mainly used to separate some behaviors in a class hierarchy, so that the classes in the class hierarchy entrust their own responsibilities to the separated classes to achieve, so that the class hierarchy itself becomes simpler, easier to expand and reuse.

Generally speaking, the behavior of these separated classes will be organized according to the class hierarchy, thus forming a new class hierarchy, which is equivalent to the class hierarchy of the original object behavior, and this hierarchy has a corresponding relationship with the original class hierarchy, so it is called parallel class hierarchy.

2. Relationship between factory method patterns and parallel class hierarchies

You can use the factory method pattern to connect parallel class hierarchies.

As shown in Figure 6.10, within each hard disk object, there is a factory method createHDOperate, with which the client obtains an action object corresponding to the hard disk object. In a subclass of hard disk objects, the factory method createHDOperate of the parent class is overridden to provide its own corresponding behavior object, thus naturally connecting two parallel class hierarchies.

6.3.4 Parametric chemical plant method

The so-called parametric chemical plant method refers to: by passing parameters to the factory method, let the factory method according to the different parameters to create different product objects, this situation is called parametric chemical plant method. Of course, the different products created by the factory method must be of the same Product type. To modify the previous example, a factory method is now used to create the ExportFileApi product object. However, there are many implementations of the ExportFileApi interface. To facilitate the creation option, pass a parameter directly from the client, so that when the ExportFileApi object needs to be created, We pass this parameter to the factory method, which instantiates the concrete ExportFileApi implementation object.

It’s better to look at code examples.

(1) Let’s first look at the interface of Product, namely ExportFileApi. There is no change compared with the previous example. It’s just for your convenience. Example code is as follows:

(2) The implementation of saving as a text file and as a database backup file is also provided, unchanged from the previous example. Example code is as follows:

(3) It’s time to look at the ExportOperate class, where the changes are roughly as follows.

  • The factory method of creating a product in the ExportOperate class, which usually needs to provide a default implementation, is no longer abstract, that is, normal.

  • The ExportOperate class is also no longer defined as an abstract class, because with the default implementation, the client may need to use the object directly.

  • Set an export type parameter passed from the client using the export method.

Take a look at the sample code below:

(4) At this point, the client is very simple and uses the ExportOperate class directly. Example code is as follows:

Test it out, and then modify the client’s parameters to see how those parameters can be used to select a specific export implementation.

prompt

This is a very common way to implement parameterized chemical methods, but it is also possible to implement parameterized chemical methods as abstract. Note that this does not mean that parameterized chemical methods cannot be implemented as abstract classes. It’s just that in general, parametric chemical methods are provided with a default implementation in the parent class.

(5) Extend the new implementation.

Using the parametric chemical plant approach, it’s easy to extend and leave the existing code unchanged, just add a new subclass to provide the new factory method implementation and use that new subclass on the client side.

Another interesting feature of this implementation is that subclasses can optionally override, and if they don’t want to override, they can go back to the parent class to implement it, which is interesting.

Example code for extending an exported XML file is as follows:

The ExportOperate class is then extended to include the new implementation. Example code is as follows:

If you look at the client at this point, it’s very simple, just converting the parameters passed in. Example code is as follows:

The corresponding test results are as follows:

Through the above example, you can enjoy the implementation and benefits of the parametric chemical plant approach.

6.3.5 Advantages and disadvantages of the factory method pattern

Advantages of the factory method pattern

  • You can program without knowing the implementation

The factory method pattern allows you to implement functionality that requires a product object using the product’s interface, regardless of the implementation. Select implementation-specific tasks to defer to subclasses.

  • New versions of objects that are easier to extend

The factory method provides a hook to subclasses, making it easy to extend new versions of objects. For example, in the example above, extending a new implementation of the exported XML file format does not change the existing code, as long as you add a new subclass to provide the new factory method implementation, and then use the new subclass on the client side.

prompt

In addition, the hook mentioned here is often referred to as the hook method, which will be explained in more detail later when we talk about the template method pattern.

  • Connect parallel class hierarchies

In addition to creating product objects, the factory approach is also great at connecting parallel class hierarchies. This has been dealt with in detail above.

Disadvantages of the factory method pattern

  • Coupling between concrete product objects and factory methods.

In the factory method pattern, the factory method needs to create product objects, that is, it needs to select specific product objects and create instances of them, so the concrete product objects and the factory method are coupled.

6.3.6 Think about the factory method mode

1. Nature of the Factory Method Pattern Nature of the factory method pattern: Defer implementation selection to subclasses.

If you look closely at the previous examples, you can see that the factory method in the factory method pattern, when actually implemented, usually selects which specific product implementation object to use, then creates an example of that specific product object, and then returns. That is, the factory method itself does not implement the product interface, the specific product implementation is already written, the factory method just chooses the implementation.

Some friends might say, isn’t this just like a simple factory?

They are indeed very similar in nature, and both are “choice implementations” in their concrete implementations. But there are differences, simple factory is directly in the factory class “select implementation”; Factory methods defer this work to subclasses. The use of factory methods in factory classes relies on abstract rather than concrete implementations, making the system more flexible, maintainable, and extensible.

In fact, if the factory mode of Creator is degenerated, only factory methods, and these factory methods also provide the default implementation, would not become a simple factory? For example, if you take the example code that demonstrates the parametric chemical plant method and simplify it, you can see that it is similar to the simple factory. Example code is as follows:

After looking at the above code, you can see that the simple factory and the factory method pattern are very similar. In some ways, you can think of the simple factory as a special case of the factory method pattern, so it is not surprising that they are similar in nature.

2. The embodiment of design principles

The factory method model embodies the dependency inversion principle well.

The dependency inversion principle tells us to “rely on abstractions, not concrete classes.” To put it simply: you can’t make high-level components depend on low-level components, and both high-level and low-level components should depend on abstractions.

For example, in the previous example, ExportOperate, which implements client request operations, is a high-level component; The object of data export is low-level components, such as ExportTxtFile and ExportDB. The ExportFileApi interface is just that abstraction.

For ExportOperate, it doesn’t care about the implementation, it’s just “programming to the interface”; For a concrete implementation, it is only concerned with its “how to implement the interface” required functionality.

So what’s the upside down? What is inverted is the “ownership” of the interface. In fact, the functions defined in the ExportFileApi interface are required by the higher-level component ExportOperate, that is, the functions in the interface are required by the higher-level component. But the higher-level components just make requirements and don’t care how to implement them, while the lower-level components actually implement the interface functions required by the higher-level components. Therefore, it appears that ownership of the interface implemented at the lower level is not in the hands of the lower level component, but is inverted to the higher level component.

3. When to choose the factory method pattern

The factory method pattern is recommended for the following situations.

  • If a class needs to create objects for an interface but does not know the implementation, the factory method pattern can be used to defer object creation to subclasses.

  • The factory method pattern should be used when a class itself wants its subclasses to create the desired objects.

6.3.7 Related modes

  • Factory method pattern and Abstract factory pattern

These two patterns can be used together in the abstract factory pattern.

  • Factory method pattern and template method pattern

Both patterns look similar in that they have an abstract class and then subclasses provide some implementation, but the factory method pattern subclass focuses on creating product objects, while the template method pattern subclass focuses on providing some implementation of steps for a fixed algorithm skeleton.

The two patterns can be used together, usually in the template method pattern, using factory methods to create objects needed by the template method.