這裏有什麼設計模式嗎？這個java代碼有沒有可能的缺陷？

Question

在Java API的設計，我想出了下面的模式來滿足這裏列出

• 實際的公共API類應實現爲final類有一定的要求，以防止繼承和可能濫用
• 實際的公共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; 
    } 
} 

Althoug它工作正常，並且具有適當的訪問級別，但是我只具有設計模式或API設計的初級水平技能，所以我很難用它來發現可能的故障。那麼這有什麼問題嗎？或者它是否已經實行了一些模式？

Answer 1

爲什麼要這樣做？

protected AbstractProduct(){ 
    impl = null; 
} 

當調用result()時，這將導致NullPointerException。

我也沒有看到AbstractProduct和ProductImpl的觀點。只需將代碼放入Product即可。

我也會質疑爲什麼你需要一個ProductFactory如果只有一個實現，但如果你打算有未來的實現，那麼它會好的。

Answer 2

您嘗試實施的唯一設計模式是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相同。

---

正如我在其他直接評論你的問題指出，如果你解釋的功能要求收到你的設計更好，更準確的幫助會很大。

---

IMO爲了瞭解設計模式，它會更好地去現實世界的例子，而不是繼續閱讀關於他們越來越多在​​網上，然後開始練習。我強烈建議從BalusC（Java和Java EE專家）這個Q/A：Examples of GoF Design Patterns in Java's core libraries

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包依賴於接口。