Questions tagged «factory-method»

1
工厂模式和抽象工厂之间有什么区别？
终于开始认真尝试学习一些基本模式（在职业生涯的后期，但这是一个不同的故事），我试图弄清Factory Pattern和Abstract Factory之间的区别。 这两种模式之间的主要区别是什么？ 我知道Factory方法是通过继承创建对象的，而Abstract Factory是通过对象组合来创建的，但是从实际的角度来看，我仍然很难准确地看到它们各自的工作方式。
10
如果一个类属性创建并返回一个新的类实例，它是一种反模式吗？
我有一个叫做Heading一些事情的类，但它也应该能够返回当前标题值的反面，最后必须通过创建Heading类本身的新实例来使用它。 我可以使用一个简单的属性reciprocal来返回当前值的相反标题，然后手动创建Heading类的新实例，或者我可以创建一种方法createReciprocalHeading()来自动创建Heading类的新实例并将其返回给用户。 但是，我的一位同事建议我只创建一个名为的类属性reciprocal，该属性通过其getter方法返回该类本身的新实例。 我的问题是：类属性的行为不是一种反模式吗？ 我特别觉得这不太直观，因为： 在我看来，类的属性不应返回类的新实例，并且 如果reciprocal没有从IDE获得帮助或检查getter签名，该属性的名称为，将无法帮助开发人员完全理解其行为。 我是否对类属性应该做的事情过于严格？还是真正的顾虑？我一直试图通过类的字段和属性来管理类的状态，并通过其方法来管理类的行为，而我却看不出它如何适合于类属性的定义。
3
静态工厂vs单身工厂
在我的某些代码中，我有一个类似于以下内容的静态工厂： public class SomeFactory { // Static class private SomeFactory() {...} public static Foo createFoo() {...} public static Foo createFooerFoo() {...} } 在代码审查期间，建议将其作为一个单例并注入。因此，它应如下所示： public class SomeFactory { public SomeFactory() {} public Foo createFoo() {...} public Foo createFooerFoo() {...} } 需要强调的几件事： 两个工厂都是无状态的。 方法之间的唯一区别是它们的范围（实例与静态）。实现是相同的。 Foo是没有接口的bean。 我要静态化的参数是： 该类是无状态的，因此不需要实例化 能够调用静态方法比必须实例化工厂似乎更自然。 工厂作为单例的参数是： 注入一切都很好 尽管工厂是无状态的，但使用注入进行测试还是比较容易的（易于模拟） 测试消费者时应该嘲笑它 …
2
我应该使用工厂方法而不是构造函数。我可以更改它并且仍然向后兼容吗？
问题 假设我有一个名为的类DataSource，它提供了ReadData一种从.mdb文件中读取数据的方法（也许还有其他方法，但为了简单起见）： var source = new DataSource("myFile.mdb"); var data = source.ReadData(); 几年后，我决定.xml除了.mdb文件作为数据源之外，还希望能够支持文件。.xml和.mdb文件的“读取数据”实现完全不同。因此，如果我要从头开始设计系统，则可以这样定义： abstract class DataSource { abstract Data ReadData(); static DataSource OpenDataSource(string fileName) { // return MdbDataSource or XmlDataSource, as appropriate } } class MdbDataSource : DataSource { override Data ReadData() { /* implementation 1 */ } } class XmlDataSource …
3
大量构建一种实现。DI无望吗？使用服务定位器？
假设我们有1001个客户端，它们直接构造其依赖关系，而不接受注入。根据我们的老板，重构1001不是一个选择。实际上，甚至不允许我们访问其源代码，而只能访问类文件。 我们应该做的是“现代化”这1001个客户所经历的系统。我们可以重构自己喜欢的一切。依赖关系是该系统的一部分。还有一些依赖关系我们应该更改为具有新的实现。 我们想要做的是能够配置依赖关系的不同实现，以满足众多客户的需求。可悲的是，DI似乎不是一个选择，因为客户端不接受构造函数或setter的注入。 选项： 1）重构客户端使用的服务的实现，以使其执行客户端现在需要的功能。砰，我们完成了。不灵活。不复杂。 2）重构实现，以便将其工作委托给它通过工厂获取的另一个依赖项。现在，我们可以通过重构工厂来控制它们都使用哪种实现。 3）重构实现，以便将其工作委托给它通过服务定位器获取的另一个依赖项。现在，我们可以通过配置服务定位器来控制它们都使用哪种实现，该服务定位器可能只是hashmap对象的字符串，并且需要进行一些强制转换。 4）我什至没有想到的东西。 目标： 在不增加毫无意义的复杂性的情况下，将因设计欠佳的旧客户端代码拖到将来而导致的设计损失最小化。 客户不应该了解或控制其依赖项的实现，但是他们坚持使用来构建它们new。我们无法控制，new但可以控制他们正在构建的类。 我的问题： 我没有考虑什么？ Doc Brown的问题 您是否真的需要在不同的实现之间进行配置？出于什么目的？ 敏捷。很多未知数。管理层希望变革的潜力。只失去对外界的依赖。还测试。 您是否需要运行时机制或只是编译时机制来在不同的实现之间进行切换？为什么？ 编译时间机制可能就足够了。除测试外。 您需要在实现之间切换哪种粒度？一次全部？每个模块（每个模块包含一组类）？每堂课？ 在1001中，任何一次都只能运行一次。一次更改所有客户端使用的内容可能很好。但是，对依赖项的单独控制可能很重要。 谁需要控制开关？只有您/您的开发人员团队？管理员？每个客户自己吗？还是客户的代码的维护开发人员？那么，机械师需要多么容易/稳健/万无一失？ 开发测试。管理员随着外部硬件依赖性的变化而变化。它需要易于测试和配置。 我们的目标是证明该系统可以快速重建和现代化。 实施开关的实际用例？ 一种是，在硬件解决方案准备就绪之前，一些数据将由软件提供。
3
避免构造函数有很多参数
所以我有一个工厂，可以创建不同类的对象。可能的类都是从抽象祖先派生的。工厂具有配置文件（JSON语法），并根据用户的配置来决定要创建哪个类。 为此，工厂使用boost :: property_tree进行JSON解析。他遍历ptree并决定要创建哪个具体对象。 但是，产品对象具有许多字段（属性）。根据具体的类，对象具有大约5-10个属性，将来可能会更多。 因此，我不确定对象的构造函数应如何。我可以想到两种解决方案： 1）产品的构造函数希望将每个属性作为参数，因此构造函数最终将带有10个以上的参数。这将是丑陋的，并导致较长的，不可读的代码行。但是，优点是工厂可以解析JSON并使用正确的参数调用构造函数。产品类不需要知道由于JSON配置而已创建。不需要知道完全涉及JSON或配置。 2）产品的构造函数只需要一个参数property_tree对象。然后，它可以解析所需的信息。如果配置中的信息丢失或超出范围，则每个产品类别都可以正确响应。工厂不需要知道几种产品需要哪些参数。如果配置错误，工厂也不需要知道如何应对。而且构造函数的接口是统一的，很小的。但是，缺点是，该产品需要从JSON中提取所需的信息，因此，它知道如何构造它。 我倾向于选择解决方案2）。但是，我不确定这是否是好的工厂模式。让产品知道它是用JSON配置创建的，这感觉有点不对劲。另一方面，可以很简单地介绍新产品。 有什么意见吗？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.