关于原型模式的问题 [英] Questions about the Prototype Pattern

问题描述

我正在了解不同的设计模式，我有强烈的感觉，我在理解这种特定模式时缺少一个重要的部分（或几件）。

我看过的网站，在GoF书中，我看到了克隆方法。根据我的理解，当我们需要不同版本的对象时，我们可以克隆一些类型的对象，但是我们不需要使用new命令手动创建每个对象（如在Java中）。这可以隐藏其具体实现。所以当我们克隆时，我们可以调整克隆只是一点点，并使其成为我们需要的，而不必知道如何最初创建该对象的困难的方式。这是我的想法正确吗？

我也被告知，这可以减少子类化，从而减少你需要做的类的数量。我不太明白这部分。有人可以帮我把握吗？

我的最后一个问题是关于抽象工厂（甚至工厂方法）的模式。这些工厂模式和原型模式感觉就像在创建新对象时试图隐藏具体的实现。什么时候选择其中一个好主意？

谢谢大家！

解决方案原型模式

原型结果与原始对象不同的克隆对象。在克隆时，原始状态与克隆相同。此后，每个物体可能经历状态改变。您可以将其视为类似的复印原件，然后在几个地方修改复印件。

示例

• DVD复制：复制主dvd以创建多个副本


• 报告对象：考虑包含处理信息的报表对象传递给GUI。原始报告按升序包含数据。现在，使用这种模式可以创建一个类似的报告，但数据按降序排序。

优点

• 性能：克隆（使用 MemberwiseClone ）比重新创建一个新对象便宜得多（使用 new operator ）。请注意，需要覆盖 MemberwiseClose（）来执行深层复制。


• 对象可以非常动态地克隆，没有任何坚持在前台实例化。可以随时在应用程序执行中创建第一个创建的对象，并可以在任何时候进一步复制。

< b>何时使用它

• 当运行时指定要实例化的类时，例如，通过动态加载


• 当一个类的实例可以只有几个不同的状态组合之一。安装相应数量的原型并克隆它们可能更方便，而不是手动实例化类，每次都有适当的状态。

与工厂模式的比较

原型模式允许对象创建自定义对象，而不知道他们的类或任何有关如何创建它们的细节。所以，这个方面似乎和Factory Method（出厂方式）模式很像。在这两种模式中，客户端可以创建任何派生类对象，而不需要知道自己的结构。

但是，两种模式之间的区别是工厂方法集中于创建一个非现有对象类型的对象作为新创建（通过了解确切的子类型的创建者类）。 原型模式使用类本身，特别是自复制操作的派生类。

工厂方法模式

在这种模式中，客户端（或消费者）向类层次结构中的Creator（或工厂）请求特定类型的对象。工厂类的创建者方法将特定对象的创建委托给派生类，并返回由客户端请求的类型的类的对象。实质上，您有一个单一的联系人来创建类层次结构的几个对象。

您可以将此视为去机票柜台（控制员），并通过优先选择机票类型（一级，行政或经济） ）。用户不关心如何生成机票，即使在对象表示中，第一类和经济票据都是从基础票类派生的。

何时使用

• 灵活性很重要（低耦合）


• 对象可以在子类中扩展


• 有一个特定的原因为什么一个子类将被选择在另一个子类上 - 这个逻辑构成了Factory Method的一部分。


• 客户将责任委托给并行层次结构中的子类。

抽象工厂模式

抽象工厂走高一步（更抽象）比工厂方法模式。在这种情况下，可能不仅仅是一个单一的，而是具有轻微变化的多个工厂。它负责创建属于类层次结构属性的对象，而不仅仅是单个类层次结构。

一个特定的Factory类已经存在。但工厂的方法稍有不同。每个方法都可以生成一个实例。客户端可以选择适当的方法并获取实例。

如果您以 MVC 基于完美的建筑设计，客户将是业务控制器类，混凝土产品将全部成为业务实体。工厂是辅助（辅助）控制器。他们根据业务主管的要求工作。

何时使用

• 系统预计将独立于产品的创建方式。甚至可以期待产品如何组成和代表的独立性。产品适用于客户端开发人员需要通过调用其方法使用的最终产生的对象。


• 可以使用多个产品系列之一配置的系统。所以家庭的实际选择不会在编码时间，而是在稍后的配置时间。


• 产品系列旨在一起工作。


• 创作用于产品库。这里关心的是相关的界面而不是实现。

I am learning about the different design patterns and I have a strong feeling I am missing an essential piece (or pieces) in understanding this particular pattern.

In all the websites I have viewed and in the GoF book, I see the clone method. From what I understand, we have some type of object that we can clone when we need varying versions of that object, but we don't want to have to manually create each one using the "new" command (as in Java). This can hide its concrete implementation. So when we clone, we can tweak the clone just a little bit and make it what we need without having to knowing how to originally create that object the hard way. Is this my thinking correct?

I am also told that this can reduce subclassing and subsequently reduce the number of classes you need to make. I don't quite understand this part. Could someone help me grasp this?

My final question is about the abstract factory (or even the factory method) pattern. These factory patterns and the prototype pattern feel like they attempt to hide concrete implementations upon creation of new objects. When is it a good idea to choose one of the other?

Thank you all!

解决方案

Prototype pattern

Prototype results in a cloned object which is different from the original object. The state of the original is the same as the clone, at the time of cloning. Thereafter each object may undergo state change. You can think of this as something similar photocopying the original and then modifying the photocopy at a few places.

Example

• DVD duplication: Duplication of the master dvd to create several copies
• Reporting object: Consider a report object that contains processed information to be passed to the GUI. The original report contains the data in ascending order. Now, using this pattern one can create a similar report but with data sorted in descending order.

Benefits

• Performance: Cloning (using MemberwiseClone) is considerably less expensive than creating a new object afresh (with new operator). Note that one needs to override the MemberwiseClose() to perform a deep copy.
• Objects can be clone very dynamically, without any insistence on up-front instantiation. The first created object can be created at any time in the application execution, and further duplication can take place at any time ahead.

When to use it

• When the classes to instantiate are specified at run-time, for example, by dynamic loading.
• When instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.

Comparison with Factory Pattern

Prototype pattern allows an object to create customized objects without knowing their class or any details of how to create them. So, it is this aspect it appears to be a lot like the Factory Method pattern. In both these patterns, the client can create any of the derived class objects without knowing anything about their own structure.

But the difference between the two patterns is the fact that for the Factory Method concentrates on creating one object of a non existing object type as a fresh creation (by understanding the exact sub-type of the Creator class). The Prototype pattern uses the class itself, especially the derived class for self duplication action.

Factory Method pattern

In this pattern, the client (or consumer) asks the Creator (or factory) for a specific type of object from a class hierarchy. The Creator method of the factory class delegates the creation of the specific object to the derived classes and return the object of the class of the type asked by client. In essence, you have a single point of contact for the creation of several objects of a class hierarchy.

You can think of this as going to a airline ticket counter (controller) and asking for a ticket by giving your preference of the ticket type (first class, executive or economy). The user is not concerned with how the ticket is being generated, even though in an object representation the first class and the economy ticket are both derived from the base ticket class.

When to use

• Flexibility is important (low coupling)
• Objects can be extended in subclasses
• There is a specific reason why one subclass would be chosen over another—this logic forms part of the Factory Method.
• A client delegates responsibilities to subclasses in parallel hierarchies.

Abstract factory pattern

Abstract factory goes a step higher (more abstract) than the factory method pattern. In this case, one can have not just a single, but multiple factories with slight variations. It is responsible for creating objects belonging families of class hierarchies rather than just a single class hierarchy.

A specific Factory class already exists. But the Factory will have slightly varying methods. Each method can produce an instance. The client can choose appropriate method and get the instance.

If you take the example of MVC based perfect Architectural Design, the client will be a Business Controller Class while Concrete Products will all be Business Entities. The Factories are Auxiliary ( Helper) Controllers. They work in association with a request from the Business Controller.

When to use

• The system is expected be independent of how it is products are created. It may even expect independence on how the products are composed and represented. The term product applies to the finally resulting object that a client developer would need to make use of by invoking its methods.
• The system that should be configurable with one of multiple families of products. So the actual selection of the family will not be at coding time but at a later configuration time.
• The family of products is designed to work always together.
• The creation is for a library of products. What is cared more here is the relevant interface and not the implementation.

这篇关于关于原型模式的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！