blocks|key|350973|text|默认情况下，构造函数应该是首选的，因为它们更容易理解和编写。但是，如果您特别需要将对象的构造细节与其客户端代码所理解的语义含义解耦，则最好使用工厂。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|350974|构造函数和工厂之间的区别类似于变量和指向变量的指针。还有另一个级别的间接性，这是一个缺点；但还有另一个级别的灵活性，这是一个优势。因此，在做出选择时，建议您进行此成本与收益分析。|350975|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

By default, constructors should be preferred, because they are simpler to understand and write. However, if you specifically need to decouple the construction niceties of an object from its semantic meaning as understood by the client code, you'd be better off using factories.

The difference between constructors and factories is analogous to, say, a variable and a pointer to a variable. There's another level of indirection, which is a disadvantage; but there's another level of flexibility too, which is an advantage. So while making a choice, you'd be well advised to do this cost versus benefit analysis.

blocks|key|3337791|text|来自Design+Patterns:+Elements+of+Reusable+Object-Oriented+Software+by+Gamma,+Helm,+Johnson,+and+Vlissides.的第108页|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3337792|在以下情况下使用Factory+Method模式|3337793|3337794|a+class不能预期它必须创建的对象类|unordered-list-item|3337795|一个类希望它的子类指定它将责任委派给几个帮助器子类之一的对象，并且您希望本地化哪个帮助器子类是|3337796|3337797|3337798|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0201633612^0|2|2U|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|10|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|11|8|@]|9|@]|C|$]]|$1|J|3|K|5|I|7|12|8|@]|9|@]|C|$]]|$1|L|3|-4|5|I|7|13|8|@]|9|@]|C|$]]|$1|M|3|-4|5|6|7|14|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|15|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

From page 108 of <a href="https://rads.stackoverflow.com/amzn/click/com/0201633612" rel="noreferrer" rel="nofollow noreferrer">Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides.</a>

Use the Factory Method pattern when

<ul>
<li>a class can't anticipate the class of objects it must create</li>
<li>a class wants its subclasses to specify the objects it creates</li>
<li>classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate</li>
</ul>

blocks|key|3124924|text|问问你自己，它们是什么，为什么我们要有它们。它们都是用来创建对象实例的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3124925|ElementarySchool+school+=+new+ElementarySchool();
ElementarySchool+school+=+SchoolFactory.Construct();+//+new+ElementarySchool()+inside|code-block|syntax|javascript|3124926|到目前为止没有什么不同。现在假设我们有不同的学校类型，并且我们想要从使用ElementarySchool切换到HighSchool+(它派生自ElementarySchool或实现与ElementarySchool相同的接口ISchool+)。代码更改将为：|3124927|HighSchool+school+=+new+HighSchool();
HighSchool+school+=+SchoolFactory.Construct();+//+new+HighSchool()+inside|3124928|在接口的情况下，我们将具有：|3124929|ISchool+school+=+new+HighSchool();
ISchool+school+=+SchoolFactory.Construct();+//+new+HighSchool()+inside|3124930|现在，如果你在多个地方都有这段代码，你会发现使用工厂方法可能非常便宜，因为一旦你改变了工厂方法，你就完成了(如果我们使用第二个接口的例子)。|3124931|这就是它的主要区别和优势。当您开始处理复杂的类层次结构，并且想要从这样的层次结构动态创建一个类的实例时，您会得到以下代码。然后工厂方法可能会接受一个参数，该参数告诉该方法实例化哪个具体实例。假设您有一个MyStudent类，并且需要实例化相应的ISchool对象，以便您的学生成为该学校的成员。|3124932|ISchool+school+=+SchoolFactory.ConstructForStudent(myStudent);|3124933|现在，您的应用程序中有一个地方包含业务逻辑，该业务逻辑确定要为不同的IStudent对象实例化什么ISchool对象。|3124934|So+-对于简单的类(值对象等)构造函数很好(您不想过度设计您的应用程序)，但对于复杂的类层次结构，工厂方法是首选方法。|3124935|这样，您就遵循了gang+of+four+book的第一个设计原则：“程序是接口，而不是实现”。|offset|length|3124936|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0201633612^0|0|0|0|0|0|0|0|0|0|0|0|8|H|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1B|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1C|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|1D|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|1E|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1F|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1H|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|1I|8|@]|9|@]|A|$E|F]]|$1|U|3|V|5|6|7|1J|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1L|8|@]|9|@$10|1M|11|1N|1|1O]]|A|$]]|$1|12|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]]|13|$14|$5|15|16|17|A|$18|19]]]]

Ask yourself what they are and why do we have them. They both are there to create instance of an object.

<pre><code>ElementarySchool school = new ElementarySchool();
ElementarySchool school = SchoolFactory.Construct(); // new ElementarySchool() inside
</code></pre>

No difference so far. Now imagine that we have various school types and we want to switch from using ElementarySchool to HighSchool (which is derived from an ElementarySchool or implements the same interface ISchool as the ElementarySchool). The code change would be:

<pre><code>HighSchool school = new HighSchool();
HighSchool school = SchoolFactory.Construct(); // new HighSchool() inside
</code></pre>

In case of an interface we would have:

<pre><code>ISchool school = new HighSchool();
ISchool school = SchoolFactory.Construct(); // new HighSchool() inside
</code></pre>

Now if you have this code in multiple places you can see that using factory method might be pretty cheap because once you change the factory method you are done (if we use the second example with interfaces).

And this is the main difference and advantage. When you start dealing with a complex class hierarchies and you want to dynamically create an instance of a class from such a hierarchy you get the following code. Factory methods might then take a parameter that tells the method what concrete instance to instantiate. Let's say you have a MyStudent class and you need to instantiate corresponding ISchool object so that your student is a member of that school. 

<pre><code>ISchool school = SchoolFactory.ConstructForStudent(myStudent);
</code></pre>

Now you have one place in your app that contains business logic that determines what ISchool object to instantiate for different IStudent objects.

So - for simple classes (value objects, etc.) constructor is just fine (you don't want to overengineer your application) but for complex class hierarchies factory method is a preferred way. 

This way you follow the first design principle from the <a href="https://rads.stackoverflow.com/amzn/click/com/0201633612" rel="noreferrer" rel="nofollow noreferrer">gang of four book</a> "Program to an interface, not an implementation".

blocks|key|348411|text|只有在需要额外控制对象创建时才使用工厂，这是通过构造函数无法完成的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|348412|例如，工厂有缓存的可能性。|348413|另一种使用工厂的方法是在您不知道要构造的类型的场景中。通常你会在插件工厂场景中看到这种用法，其中每个插件都必须派生自一个基类或实现某种接口。工厂创建从基类派生或实现接口的类的实例。|348414|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Use a factory only when you need extra control with object creation, in a way that couldn't be done with constructors.

Factories have the possibility of caching for example.

Another way to use factories is in a scenario where you do not know the type you want to construct. Often you see this type of usage in plugin factory scenarios, where each plugin must derive from a baseclass or implement some kind of interface. The factory creates instances of classes that derive from the baseclass or that implement the interface.

blocks|key|3337871|text|您需要阅读(如果您有权阅读)+Effective+Java+2+第1项:考虑使用静态工厂方法而不是构造函数。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3337872|静态工厂方法的优点：|3337873|3337874|它们有名称。|ordered-list-item|3337875|它们不需要在每次调用时创建新对象。|3337876|它们可以返回其返回类型的任何子类型的对象。|3337877|它们减少了创建参数化类型实例的繁琐。|3337878|<>G212>|3337879|静态工厂方法的缺点：|3337880|3337881|当只提供静态工厂方法时，没有公共或受保护构造函数的类不能是subclassed.|3337882|They的，因此很难与其他静态方法区分|3337883|3337884|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0321356683^0|W|L|F|G|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@$9|1A|A|1B|B|C]]|D|@$9|1C|A|1D|1|1E]]|E|$]]|$1|F|3|G|5|6|7|1F|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|1G|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|1H|8|@]|D|@]|E|$]]|$1|L|3|M|5|K|7|1I|8|@]|D|@]|E|$]]|$1|N|3|O|5|K|7|1J|8|@]|D|@]|E|$]]|$1|P|3|Q|5|K|7|1K|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|1L|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|1M|8|@]|D|@]|E|$]]|$1|V|3|-4|5|6|7|1N|8|@]|D|@]|E|$]]|$1|W|3|X|5|K|7|1O|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|K|7|1P|8|@]|D|@]|E|$]]|$1|10|3|-4|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|11|3|-4|5|6|7|1R|8|@]|D|@]|E|$]]]|12|$13|$5|14|15|16|E|$17|18]]]]

You need to read (if you have access to) <a href="https://rads.stackoverflow.com/amzn/click/com/0321356683" rel="noreferrer" rel="nofollow noreferrer">Effective Java 2</a> Item 1: Consider static factory methods instead of constructors.

Static factory methods advantages:

<ol>
<li>They have names.</li>
<li>They are not required to create a new object each time they are invoked.</li>
<li>They can return an object of any subtype of their return type.</li>
<li>They reduce verbosity of creating parameterized type instances.</li>
</ol>

Static factory methods disadvantages:

<ol>
<li>When providing only static factory methods, classes without public or protected constructors cannot be subclassed.</li>
<li>They are not readily distinguishable from other static methods</li>
</ol>

blocks|key|346116|text|来自CAD/CAM应用程序的具体示例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346117|切割路径将通过使用构造函数来创建。它是定义要剪切的路径的一系列直线和圆弧。虽然一系列的直线和圆弧可以是不同的，并且具有不同的坐标，但是可以通过将一个列表传递到构造函数来轻松地处理它。|346118|一个形状将是由工厂制造的。因为虽然有一个形状类，但根据形状的类型，每个形状的设置会有所不同。在用户做出选择之前，我们不知道要初始化的形状是什么。|346119|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

A concrete example from a CAD/CAM application.

A cutting path would be made by using a constructor. It is a series of lines and arcs defining a path to cut. While the series of lines and arcs can be different and have different coordinates it easily handled by passing a list into a constructor.

A shape would be would be made by using a factory. Because while there is a shape class each shape would be setup differently depending on what type of shape it is. We don't know what shape we are going to be initializing until the user makes a selection.

blocks|key|351116|text|引用自"Effective“，第二版，第1项:考虑静态工厂方法而不是构造函数，第5页：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351117|请注意，静态工厂方法与设计模式+Gamma95中的工厂方法模式不同，第107页。本项目中描述的静态工厂方法在设计模式中没有直接等效方法。|offset|length|style|BOLD|351118|entityMap^0|0|4|B|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

A cite from "Effective Java", 2nd ed., Item 1: Consider static factory methods instead of constructors, p. 5:

"Note that a static factory method is not the same as the Factory Method pattern
from Design Patterns [Gamma95, p. 107]. The static factory method described in
this item has no direct equivalent in Design Patterns."

blocks|key|347623|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|347624|说，我在一个类上有一个构造函数，它需要一个id值。构造函数使用此值填充数据库中的类。|blockquote|347625|347626|347627|这个过程绝对应该在构造函数之外。|347628|347629|构造函数不应访问数据库。|ordered-list-item|347630|构造函数的任务和原因是初始化数据成员，并使用传入的值建立类不变量。其他更好的方法是使用静态工厂方法，或者在更复杂的情况下使用单独的工厂或生成器类。|347631|347632|Some+constructor+guide+lines+from+Microsoft|offset|length|347633|347634|在构造函数中只做最少的工作。除了捕获构造函数参数之外，构造函数不应该做太多的工作。任何其他处理的成本都应该推迟到需要的时候。|347635|347636|347637|和|347638|347639|如果所需操作的语义没有直接映射到新实例的构造，请考虑使用静态工厂方法而不是构造函数。|347640|347641|entityMap|0|LINK|mutability|MUTABLE|url|https://msdn.microsoft.com/en-us/library/vstudio/ms229060%2528v=vs.100%2529.aspx^0|0|0|0|0|0|0|0|0|0|0|17|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|1B|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1C|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1D|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|1E|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|1F|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|1G|7|@]|8|@]|9|$]]|$1|I|3|J|4|K|6|1H|7|@]|8|@]|9|$]]|$1|L|3|M|4|K|6|1I|7|@]|8|@]|9|$]]|$1|N|3|-4|4|5|6|1J|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|1K|7|@]|8|@$Q|1L|R|1M|1|1N]]|9|$]]|$1|S|3|-4|4|5|6|1O|7|@]|8|@]|9|$]]|$1|T|3|U|4|C|6|1P|7|@]|8|@]|9|$]]|$1|V|3|-4|4|5|6|1Q|7|@]|8|@]|9|$]]|$1|W|3|-4|4|5|6|1R|7|@]|8|@]|9|$]]|$1|X|3|Y|4|5|6|1S|7|@]|8|@]|9|$]]|$1|Z|3|-4|4|5|6|1T|7|@]|8|@]|9|$]]|$1|10|3|11|4|C|6|1U|7|@]|8|@]|9|$]]|$1|12|3|-4|4|5|6|1V|7|@]|8|@]|9|$]]|$1|13|3|-4|4|5|6|1W|7|@]|8|@]|9|$]]]|14|$15|$4|16|17|18|9|$19|1A]]]]

<blockquote>
 Say, I have a constructor on a class which expects an id value. The constructor uses this value to populate the class from the database.
</blockquote>

This process should definitely be outside a constructor.

<ol>
<li>Constructor should not access database.</li>
<li>The task and the reason for a constructor is to initialize data members and to establish class invariant using values passed into constructor.</li>
<li>For everything else a better approach is to use static factory method or in more complex cases a separate factory or builder class.</li>
</ol>

<a href="https://msdn.microsoft.com/en-us/library/vstudio/ms229060%28v=vs.100%29.aspx" rel="noreferrer">Some constructor guide lines from Microsoft</a>:

<blockquote>
 Do minimal work in the constructor. Constructors should not do much work other than to capture the constructor parameters. The cost of any other processing should be delayed until required.
</blockquote>

And

<blockquote>
 Consider using a static factory method instead of a constructor if the semantics of the desired operation do not map directly to the construction of a new instance.
</blockquote>

blocks|key|3338071|text|有时，在创建对象时，您必须检查/计算某些值/条件。如果它能抛出一个异常--构造是非常糟糕的方式。所以你需要这样做：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3338072|var+value+=+new+Instance(1,+2).init()
public+function+init()+{
++++try+{
++++++++doSome()
++++}
++++catch+(e)+{
++++++++soAnotherSome()
++++}
}|code-block|syntax|javascript|3338073|其中所有额外的计算都在init()中。但只有你作为开发人员才真正知道这个init()。当然，几个月后你就会忘记这件事。但是如果你有一个工厂-只需在一个方法中做你需要的所有事情，隐藏这个init()，使其不被直接调用-所以没有问题。使用这种方法不会出现创建失败和内存泄漏的问题。|3338074|有人跟你说过缓存。好。但你也必须记住Flyweight模式，它在Factory+way中使用起来很好。|3338075|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Sometimes you have to check/calculate some values/conditions while creating an object. And if it can throw an Exception - constructro is very bad way. So you need to do something like this:

<pre><code>var value = new Instance(1, 2).init()
public function init() {
 try {
 doSome()
 }
 catch (e) {
 soAnotherSome()
 }
}
</code></pre>

Where all additional calculations are in init(). But only you as developer realy know about this init(). And of course, after months you just forget about it.
But if you have a factory - just do all you need in one method with hiding this init() from direct call - so no problems. With this approach is no problems with falling on creation and memory leaking.

Someone told you about caching. It's good. But you also have to remember about Flyweight pattern which is nice to use with Factory way.

blocks|key|347675|text|除了"effective“(如另一个答案中提到的)，another+classic+book还建议：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|347676|347677|更喜欢静态工厂方法(带有描述参数的名称)而不是重载的构造函数。|blockquote|347678|347679|347680|例如：不要写|347681|Complex+complex+=+new+Complex(23.0);|code-block|syntax|javascript|347682|而是改写|347683|Complex+complex+=+Complex.fromRealNumber(23.0);|347684|这本书甚至建议将Complex(float)构造函数设为私有，以强制用户调用静态工厂方法。|style|CODE|347685|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0132350882^0|Q|K|0|0|0|0|0|0|0|0|0|0|8|E|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@$A|17|B|18|1|19]]|C|$]]|$1|D|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1B|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1C|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1E|8|@]|9|@]|C|$]]|$1|L|3|M|5|N|7|1F|8|@]|9|@]|C|$O|P]]|$1|Q|3|R|5|6|7|1G|8|@]|9|@]|C|$]]|$1|S|3|T|5|N|7|1H|8|@]|9|@]|C|$O|P]]|$1|U|3|V|5|6|7|1I|8|@$A|1J|B|1K|W|X]]|9|@]|C|$]]|$1|Y|3|-4|5|6|7|1L|8|@]|9|@]|C|$]]]|Z|$10|$5|11|12|13|C|$14|15]]]]

In addition to "effective java" (as mentioned in another answer), <a href="https://rads.stackoverflow.com/amzn/click/com/0132350882" rel="noreferrer" rel="nofollow noreferrer">another classic book</a> also suggests: 

<blockquote>
 Prefer static factory methods (with names that describe the arguments) to overloaded constructors. 
</blockquote>

Eg. don't write

<pre><code>Complex complex = new Complex(23.0);
</code></pre>

but instead write

<pre><code>Complex complex = Complex.fromRealNumber(23.0);
</code></pre>

The book goes as far as to suggest making the <code>Complex(float)</code> constructor private, to force the user to call the static factory method.

When modelling classes, what is the preferred way of initializing:

<ol>
<li>Constructors, or</li>
<li>Factory Methods</li>
</ol>

And what would be the considerations for using either of them?

In certain situations, I prefer having a factory method which returns null if the object cannot be constructed. This makes the code neat. I can simply check if the returned value is not null before taking alternative action, in contrast with throwing an exception from the constructor. (I personally don't like exceptions)

Say, I have a constructor on a class which expects an id value. The constructor uses this value to populate the class from the database. In the case where a record with the specified id does not exist, the constructor throws a RecordNotFoundException. In this case I will have to enclose the construction of all such classes within a try..catch block.

In contrast to this I can have a static factory method on those classes which will return null if the record is not found.

Which approach is better in this case, constructor or factory method?

Constructors vs Factory Methods

在对类建模时，首选的初始化方式是什么：工厂构造函数，或 Methods使用这两种方法的考虑因素是什么？在某些情况下，我更喜欢有一个工厂方法，如果对象不能构造，它会返回null。这使得代码很整洁。在采取替代操作之前，我可以简单地检查返回值是否不为null，而不是从构造函数抛出异常。(我个人不喜欢例外)比方说，我在一个类上...

问构造函数与工厂方法
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问构造函数与工厂方法EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问构造函数与工厂方法
EN