父类是否应该引用子类？
早上好，
我在工作中继承了一些遗留代码，它使用了一种相当不寻常的设计模式。我在论坛上找到的类似模式的唯一参考是这里。情况是原始设计者有一个通用父类（不是抽象），它有一个直接引用子类的静态工厂方法。
下面是这种编码风格的示例，可以在遗留代码中的多个位置找到：
public static LoggerFactory getLoggerFactory(LogType type) {
switch (type) {
case LOG4J:
return Log4JLoggerFactory.getInstance();
case LOGBACK:
return LogBackLoggerFactory.getInstance();
default:
throw new RuntimeException("No logger factory defined for type " + type);
}
}
其中 Log4JLoggerFactory 和 LogBackLoggerFactory 扩展了 LoggerFactory。
这对我来说似乎很陌生，但在我对代码进行重大重构之前，这种设计模式有什么目的或好处吗（甚至有一个正式的名称吗）？
任何想法或建议表示赞赏。谢谢！
编辑：阅读 Yishai 的回复后，我想我应该添加一个指向 关于策略模式的维基百科文章的链接，方便参考。感谢大家的回复！
Good morning,
I inherited some legacy code at work and it is using a rather unusual design pattern. The only reference I could find on the forums to a similar pattern was here. The situation is that the original designer has a generic parent class (not abstract) that has a static factory method which directly references children classes.
Here is a sample of that style of coding, found in several places in the legacy code:
public static LoggerFactory getLoggerFactory(LogType type) {
switch (type) {
case LOG4J:
return Log4JLoggerFactory.getInstance();
case LOGBACK:
return LogBackLoggerFactory.getInstance();
default:
throw new RuntimeException("No logger factory defined for type " + type);
}
}
Where Log4JLoggerFactory and LogBackLoggerFactory extend LoggerFactory.
This seems really foreign to me but before I re-factor the code significantly, is there any purpose or benefit to this design pattern (is there even a formal name for it)?
Any thoughts or advice is appreciated. Thanks!
EDIT: After reading Yishai's response, I thought I would include a link to the Wikipedia article on the Strategy pattern, for easy reference. Thanks to everyone for your responses!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
它是 Java 中非常标准的模式，也是实现策略模式的常用方法。您一直在标准 API 中看到它（Calendar 与 GregorianCalendar、NumberFormat 与 DecimalFormat 等）。
话虽这么说，随着依赖注入风靡一时，这种模式确实可能会被具有专用 Factory 接口的专用 Factory 类所取代，但在没有更大的设计原因的情况下，我认为您给出的示例是完全合理的设计选择。
It's a very standard pattern in Java, and a common way to implement a Strategy pattern. You see it in the standard API all the time (Calendar vs. GregorianCalendar, NumberFormat vs. DecimalFormat and more).
That being said, with Dependency Injection being all the rage, such a pattern might indeed be replaced by a dedicated Factory class with a dedicate Factory interface, but in the absence of a larger design reason, I think the example you give is a perfectly reasonable design choice.
这是一种很好的做法，称为工厂方法。
好处是您返回一些具体的实现，但通过公共接口或基类隐藏它。因此，客户端不会被实现细节所困扰，而是使用最基本的类。
It is a good practise and called Factory Method.
The benefit is that you return some concrete implementation but hide it via common interface or base class. Thus client isn't bothered by implementation details, but works with a most basic class.
也许他们以这种方式设置在一种环境中使用 Log4J，而在另一种环境中使用 Logback？我知道有时开发人员在进行本地开发时更喜欢使用工具，但在部署时必须使用公司认可/批准的任何工具。
Maybe they have it setup that way to use Log4J in one environment, and Logback in another? I know sometimes developers prefer a tool when doing local development, but when it comes time to deploy have to use whatever the company endorses/approves.
这是好还是坏做法取决于具体情况。例如，当“父母”知道如何创建所有孩子时，这可能是一个很好的做法。当家长不知道的时候，这种解决办法只会带来麻烦。
另一个问题是可测试性：如果父级有很多子级，则可能很难创建与子级隔离的父级，但这又取决于。
Whether this is a good or bad practice it depends on situation. Eg when the 'parent' knows how to create all the children, it may be a good practice. When the parent doesn't know it, this solution will only cause trouble.
Another problem is testability: if parent has lots of children, it may be hard to create parent in isolation from the children, but again it depends.