这有什么设计模式吗？这个java代码有什么可能的缺陷吗？

Question

为了在 java 中设计 API，我想出了以下模式来满足此处列出的某些要求

• 实际的公共 API 类应作为最终类实现，以防止继承和可能的误用
• 实际的公共 API 类不应公开任何超出所需方法的内容。
• 将 API 类和内部实现分离到不同的包中
• 公共类和内部类的可扩展性或演变范围

示例代码如下：

package external;

import internal.AbstractProduct;

public final class Product extends AbstractProduct{

    protected Product(int a, int b){
        super(a,b);
    }

    @Override
    public int result(){
        return super.result();
    }
}

public class ProductFactory {
    public static Product createProudct(int a, int b){
        return new Product(a, b);
    }
}

和内部类如下：

package internal;

public abstract class AbstractProduct {

    private final AbstractProduct impl;

    protected AbstractProduct(int a, int b){
        impl = new ProductImpl(a, b);
    }

    protected AbstractProduct(){
        impl = null;
    }

    protected int result(){
        return impl.result();
    }
}

class ProductImpl extends AbstractProduct{

    private int a;
    private int b;

    ProductImpl(int a, int b){
        this.a = a;
        this.b = b;
    }

    @Override
    protected int result(){
        return a*b;
    }
}

虽然它工作正常并且也有适当的访问级别，但我只有设计模式或 API 设计的初学者水平技能，所以我似乎很难发现可能的故障。那么这有什么问题吗？或者它是一些已经实践过的模式？

Answer 1

您尝试实现的唯一设计模式是Factory Method 在ProductFactory 类中。这是唯一想要的设计模式。

由于您当前的代码非常不灵活，因此整体甚至可以视为anti-pattern，更具体地说：

• Poltergeist，因为 Product 只是为了执行 ProductImpl#result 而存在。
• Call super，因为Product 只使用super 调用。
• Accidental complexity，即使过程不仅仅是简单的int 乘法。
• Cargo cult，因为您仍然没有意识到为什么以及何时使用设计模式。

（可能还有更多……）

说明：您的工厂方法模式非常不灵活。请注意，Product 类是 public，但有一个 protected 构造函数（甚至标记为 final 类，这是奇怪：为什么要在一个类上拥有 protected 方法可以从不被继承？），这意味着ProductFactory 至少应该与Product 在同一个包中。

---

正如我在其他 cmets 中直接针对您的问题所指出的那样，如果您能解释功能要求以获得更好、更准确的设计帮助，那就太好了。

---

IMO 为了学习设计模式，最好去看看现实世界的例子，而不是在网上阅读更多关于它们的内容，然后开始练习。我强烈推荐 BalusC（Java 和 Java EE 专家）的这个问答：Examples of GoF Design Patterns in Java's core libraries

Answer 2

为什么要这样做？

protected AbstractProduct(){
    impl = null;
}

这会在调用result()时引发NullPointerException。

我也看不出AbstractProduct 和ProductImpl 的意义。只需将代码放入Product即可。

如果只有一个实现，我也会质疑为什么您需要ProductFactory，但如果您计划在未来进行实现，那么就可以了。

Answer 3

如果是我，我会这样分解：

package external;

import internal.InternalProduct;
import internal.ProductImpl;

public final class Product {

    private final InternalProduct internalProduct;

    Product(final InternalProduct internalProduct) {
        this.internalProduct = internalProduct;
        assert this.internalProduct != null;
    }

    public int result() {
        return this.internalProduct.result();
    }
}

public class ProductFactory {
    public static Product createProduct(final int a, final int b) {
        return new Product(new ProductImpl(a, b));
    }
}

面向内部的包内容为：

package internal;

public interface InternalProduct {
    int result();
}

public final class ProductImpl implements InternalProduct {

    private final int a;
    private final int b;

    public ProductImpl(final int a, final int b) {
        this.a = a;
        this.b = b;
    }

    @Override
    protected int result() {
        return a * b;
    }
}

您不需要抽象类，并且您绝对不希望Product 扩展它。您应该在这里使用封装。这可以保护您的 Product 类免受内部接口的更改 - 可以添加方法而不需要 Product 获取它们，除非您选择它。

如果你有更多的实现并且你想要一个抽象的父类，你可以选择每个实现是否扩展它，因为你的external 包依赖于接口。