Sự khác biệt cơ bản giữa các mô hình nhà máy và nhà máy trừu tượng là gì?

Với mô hình Nhà máy, bạn tạo ra các trường hợp triển khai ( Apple, Banana, Cherry, vv) của một giao diện cụ thể - chẳng hạn, IFruit.

Với mẫu Tóm tắt của Nhà máy, bạn cung cấp một cách cho bất kỳ ai cung cấp nhà máy của riêng họ. Điều này cho phép kho của bạn là một IFruitFactoryhoặc một IJuiceFactory, mà không yêu cầu kho của bạn biết bất cứ điều gì về trái cây hoặc nước ép.

Nguồn cho thông tin này được lấy từ: http://java.dzone.com/news/intro-design-potypes-abab

Tóm tắt Nhà máy so với Phương pháp Nhà máy

Các phương thức của một Nhà máy Trừu tượng được triển khai như Phương thức của Nhà máy. Cả Mẫu nhà máy trừu tượng và Mẫu phương thức nhà máy đều tách hệ thống máy khách khỏi các lớp triển khai thực tế thông qua các loại và nhà máy trừu tượng. Phương thức Factory tạo các đối tượng thông qua sự kế thừa trong đó Nhà máy Trừu tượng tạo ra các đối tượng thông qua thành phần.

Mẫu nhà máy trừu tượng bao gồm một mẫu trừu tượng, cụ thể, cụ thể, sản phẩm trừu tượng, sản phẩm cụ thể và khách hàng.

Cách thực hiện

Mẫu nhà máy trừu tượng có thể được triển khai bằng cách sử dụng mẫu Phương thức nhà máy, mẫu thử nghiệm hoặc mẫu đơn. Đối tượng ConcreteFactory có thể được triển khai như một Singleton vì chỉ cần một thể hiện của đối tượng ConcreteFactory.

Mẫu Phương thức Factory là phiên bản đơn giản hóa của mẫu Tóm tắt Factory. Mẫu Phương thức nhà máy chịu trách nhiệm tạo ra các sản phẩm thuộc về một gia đình, trong khi mẫu Tóm tắt của Nhà máy xử lý nhiều gia đình sản phẩm.

Phương thức Factory sử dụng các giao diện và các lớp trừu tượng để tách rời máy khách khỏi lớp trình tạo và các sản phẩm kết quả. Tóm tắt Factory có một trình tạo là một thùng chứa cho một số phương thức của nhà máy, cùng với các giao diện tách rời máy khách khỏi máy phát và các sản phẩm.

Khi nào nên sử dụng mẫu Phương thức nhà máy

Sử dụng mẫu Phương thức nhà máy khi có nhu cầu tách khách hàng khỏi một sản phẩm cụ thể mà họ sử dụng. Sử dụng Phương thức xuất xưởng để giảm bớt trách nhiệm của khách hàng trong việc tạo và định cấu hình phiên bản của sản phẩm.

Khi nào nên sử dụng mô hình nhà máy trừu tượng

Sử dụng mẫu Tóm tắt Factory khi khách hàng phải được tách rời khỏi các lớp sản phẩm. Đặc biệt hữu ích cho cấu hình chương trình và sửa đổi. Mẫu Tóm tắt Factory cũng có thể thực thi các ràng buộc về các lớp phải được sử dụng với các lớp khác. Nó có thể là rất nhiều công việc để làm cho các nhà máy bê tông mới.

Ví dụ:

Tóm tắt nhà máy Ví dụ 1

Thông số kỹ thuật này cho các đĩa để chuẩn bị các loại mì ống khác nhau trong nhà sản xuất mì ống là Nhà máy Trừu tượng và mỗi đĩa cụ thể là Nhà máy. tất cả các nhà máy (đĩa nhà sản xuất mì ống) thừa hưởng các thuộc tính của họ từ Nhà máy trừu tượng. Mỗi đĩa riêng lẻ chứa thông tin về cách tạo mì ống và nhà sản xuất mì ống thì không.

Nhà máy trừu tượng Ví dụ 2:

Thiết bị dập tương ứng với Nhà máy trừu tượng, vì đây là giao diện cho các hoạt động tạo ra các đối tượng sản phẩm trừu tượng. Các khuôn tương ứng với Nhà máy bê tông, vì chúng tạo ra một sản phẩm bê tông. Mỗi loại phần (Hood, Cửa, v.v.) tương ứng với sản phẩm trừu tượng. Các bộ phận cụ thể (ví dụ, cửa phía người lái cho 99 camry) tương ứng với các sản phẩm bê tông.

Phương pháp nhà máy Ví dụ:

Công ty đồ chơi tương ứng với Người tạo, vì nó có thể sử dụng nhà máy để tạo ra các đối tượng sản phẩm. Bộ phận của công ty đồ chơi sản xuất một loại đồ chơi cụ thể (ngựa hoặc xe hơi) tương ứng với ConcreteCreator.

Mẫu nhà máy: Nhà máy sản xuất triển khai IP sinh sản

Mô hình nhà máy trừu tượng: Một nhà máy-nhà máy sản xuất IFactories, từ đó tạo ra các sản phẩm IP :)

[Cập nhật theo các bình luận]
Những gì tôi viết trước đó không đúng theo Wikipedia . Một nhà máy trừu tượng chỉ đơn giản là một giao diện nhà máy. Với nó, bạn có thể chuyển đổi các nhà máy của mình trong thời gian chạy, để cho phép các nhà máy khác nhau trong các bối cảnh khác nhau. Ví dụ có thể là các nhà máy khác nhau cho các hệ điều hành khác nhau, nhà cung cấp SQL, trình điều khiển phần mềm trung gian, v.v.

Mô hình nhà máy trừu tượng

• Cung cấp một giao diện để tạo các họ của các đối tượng liên quan hoặc phụ thuộc mà không chỉ định các lớp cụ thể của chúng.

• Mẫu Tóm tắt của Nhà máy rất giống với mẫu Phương thức của Nhà máy. Một điểm khác biệt giữa hai loại đó là với mẫu Tóm tắt Factory, một lớp ủy thác trách nhiệm khởi tạo đối tượng cho đối tượng khác thông qua thành phần trong khi mẫu Phương thức Factory sử dụng tính kế thừa và dựa vào một lớp con để xử lý việc khởi tạo đối tượng mong muốn.

• Trên thực tế, đối tượng được ủy nhiệm thường xuyên sử dụng các phương thức của nhà máy để thực hiện khởi tạo!

Mô hình nhà máy

• Các mẫu nhà máy là ví dụ về các mẫu sáng tạo

• Các mẫu sáng tạo trừu tượng quá trình khởi tạo đối tượng. Chúng ẩn cách các đối tượng được tạo và giúp làm cho toàn bộ hệ thống độc lập với cách các đối tượng được tạo và sáng tác.

• Các mẫu tạo lớp tập trung vào việc sử dụng tính kế thừa để quyết định đối tượng được khởi tạo Phương thức xuất xưởng

• Các mẫu đối tượng tạo tập trung vào việc ủy ​​quyền khởi tạo cho đối tượng khác Tóm tắt Factory

Tham khảo: Nhà máy vs Nhà máy trừu tượng

Phương thức nhà máy: Bạn có một nhà máy tạo các đối tượng xuất phát từ một lớp cơ sở cụ thể

Nhà máy trừu tượng: Bạn có một nhà máy tạo ra các nhà máy khác , và các nhà máy này lần lượt tạo ra các đối tượng có nguồn gốc từ các lớp cơ sở. Bạn làm điều này bởi vì bạn thường không chỉ muốn tạo một đối tượng (như với phương thức Factory) - thay vào đó, bạn muốn tạo một bộ sưu tập các đối tượng liên quan.

Tóm tắt Factory là một giao diện để tạo các đối tượng liên quan nhưng phương thức Factory là một phương thức. Nhà máy trừu tượng được thực hiện theo phương pháp nhà máy.

Sự khác biệt cơ bản:

Factory: Tạo các đối tượng mà không để lộ logic khởi tạo cho máy khách.

Phương thức Factory : Xác định một giao diện để tạo một đối tượng, nhưng hãy để các lớp con quyết định lớp nào sẽ khởi tạo. Phương thức Factory cho phép khởi tạo lớp trì hoãn cho các lớp con

Nhà máy trừu tượng : Cung cấp giao diện để tạo các họ của các đối tượng liên quan hoặc phụ thuộc mà không chỉ định các lớp cụ thể của chúng.

Mẫu AbstractFactory sử dụng thành phần để ủy thác trách nhiệm tạo đối tượng cho lớp khác trong khi mẫu phương thức Factory sử dụng tính kế thừa và dựa vào lớp dẫn xuất hoặc lớp con để tạo đối tượng

Từ các bài báo oodesign :

Sơ đồ lớp nhà máy :

Ví dụ: TĩnhFactory

 public class ShapeFactory {

   //use getShape method to get object of type shape 
   public static Shape getShape(String shapeType){
      if(shapeType == null){
         return null;
      }     
      if(shapeType.equalsIgnoreCase("CIRCLE")){
         return new Circle();

      } else if(shapeType.equalsIgnoreCase("RECTANGLE")){
         return new Rectangle();

      } else if(shapeType.equalsIgnoreCase("SQUARE")){
         return new Square();
      }

      return null;
   }
}

Nhà máy không tĩnh triển khai ví dụ FactoryMethod có sẵn trong bài này:

Mẫu thiết kế: Phương pháp Factory vs Factory vs Tóm tắt Factory

Khi nào nên sử dụng: Khách hàng chỉ cần một lớp và không quan tâm đến việc triển khai cụ thể.

Phương pháp nhà máy lớp digaram:

Khi nào nên sử dụng: Khách hàng không biết những lớp cụ thể nào sẽ được yêu cầu tạo trong thời gian chạy, nhưng chỉ muốn có một lớp sẽ thực hiện công việc.

Sơ đồ lớp nhà máy trừu tượng từ dzone

Khi nào nên sử dụng: Khi hệ thống của bạn phải tạo nhiều họ sản phẩm hoặc bạn muốn cung cấp một thư viện sản phẩm mà không để lộ chi tiết triển khai.

Các ví dụ mã nguồn trong các bài viết trên là rất tốt để hiểu các khái niệm rõ ràng.

Câu hỏi SE liên quan với ví dụ mã:

Mô hình nhà máy. Khi nào nên sử dụng phương pháp nhà máy?

Sự khác biệt:

1. Các lớp Factory trừu tượng thường được triển khai với Phương thức Factory, nhưng chúng cũng có thể được thực hiện bằng Prototype
2. Các thiết kế bắt đầu sử dụng Phương thức nhà máy (ít phức tạp hơn, tùy biến hơn, các lớp con tăng sinh) và phát triển theo các mẫu sáng tạo khác (linh hoạt hơn, phức tạp hơn) khi cần linh hoạt hơn.
3. Phương thức xuất xưởng thường được gọi trong Phương thức mẫu.

Các bài viết hữu ích khác:

Factory_method từ nguồn cung cấp

tóm tắt_factory từ nguồn cung cấp

trừu tượng-nhà máy-thiết kế-mô hình từ journaldev

Ví dụ / Kịch bản cho nhà máy trừu tượng

Tôi sống ở một nơi trời mưa vào mùa mưa, tuyết rơi vào mùa đông và nắng nóng vào mùa hè. Tôi cần các loại quần áo khác nhau để bảo vệ bản thân khỏi các yếu tố. Để làm như vậy tôi đến cửa hàng gần nhà và yêu cầu quần áo / vật dụng để tự bảo vệ mình. Thủ kho cho tôi món đồ thích hợp theo môi trường và độ sâu của túi. Các mặt hàng anh ấy cho tôi có cùng mức độ chất lượng và giá cả. Vì anh ấy nhận thức được các tiêu chuẩn của tôi nên anh ấy dễ dàng làm như vậy. Nhưng khi một anh chàng giàu có từ bên kia đường đưa ra những yêu cầu tương tự, anh ta nhận được một món đồ đắt tiền, có thương hiệu. Một điều đáng chú ý là tất cả các mặt hàng anh ấy cung cấp cho tôi bổ sung cho nhau về chất lượng, tiêu chuẩn và chi phí. Người ta có thể nói họ đi với nhau. Tương tự là trường hợp với những món đồ mà anh chàng giàu có này nhận được.

Vì vậy, bằng cách nhìn vào kịch bản trên, bây giờ tôi đánh giá cao hiệu quả của người giữ cửa hàng. Tôi có thể thay thế người bán hàng này bằng một cửa hàng trừu tượng. Các mục chúng tôi nhận được với các mục trừu tượng và tôi và người giàu là khách hàng quan điểm. Tất cả chúng ta cần là sản phẩm / mặt hàng phù hợp với nhu cầu của chúng ta.

Bây giờ tôi có thể dễ dàng thấy mình đang xem xét một cửa hàng trực tuyến cung cấp một bộ dịch vụ cho nhiều khách hàng của mình. Mỗi khách hàng thuộc một trong ba nhóm. Khi một người dùng nhóm cao cấp mở trang web, anh ta nhận được giao diện người dùng tuyệt vời, khung quảng cáo được tùy chỉnh cao, nhiều tùy chọn hơn trong các menu, v.v. và UI hơi ít egronomic. Cuối cùng là loại người dùng của tôi, một người dùng 'nhóm miễn phí'. Tôi chỉ được phục vụ đủ để tôi không bị xúc phạm. Giao diện người dùng ở mức tối thiểu, các quảng cáo không được theo dõi nhiều đến mức tôi không biết những gì có trong đó, cuối cùng, menu chỉ đăng xuất.

Nếu tôi có cơ hội xây dựng một cái gì đó giống như trang web này, tôi chắc chắn sẽ xem xét Tóm tắt Mô hình Nhà máy.

Sản phẩm trừu tượng: Ngăn quảng cáo, Menu, họa sĩ UI.
Nhà máy trừu tượng: Trải nghiệm người dùng trên cửa hàng trực tuyến
Nhà máy đồng thời: Trải nghiệm người dùng cao cấp, Trải nghiệm người dùng vàng, Trải nghiệm người dùng chung.

Nhiều người sẽ cảm thấy ngạc nhiên có thể, nhưng câu hỏi này không chính xác . Nếu bạn nghe câu hỏi này trong một cuộc phỏng vấn, bạn cần giúp người phỏng vấn hiểu được sự nhầm lẫn ở đâu.

Hãy bắt đầu từ thực tế là không có mẫu cụ thể đó được gọi là chỉ là "Nhà máy". Có một mẫu được gọi là "Nhà máy trừu tượng", và có mẫu được gọi là "Phương pháp nhà máy".

Vì vậy, những gì hiện "Nhà máy" có nghĩa là sau đó? một trong những điều sau đây (tất cả có thể được coi là chính xác, tùy thuộc vào phạm vi của tài liệu tham khảo):

• Một số người sử dụng nó như một bí danh (phím tắt) cho " Nhà máy trừu tượng ".
• Một số người sử dụng nó như một bí danh (phím tắt) cho " Phương thức xuất xưởng ".
• Một số người sử dụng nó như một tên chung hơn cho tất cả các mẫu nhà máy / sáng tạo. Ví dụ: cả "Nhà máy trừu tượng" và "Phương pháp nhà máy" là các nhà máy.

Và, thật không may , nhiều người sử dụng "Nhà máy" để biểu thị một loại nhà máy, tạo ra nhà máy hoặc nhà máy (hoặc giao diện của họ). Dựa trên lý thuyết của họ:

dụng cụ sản phẩm IProduct, được tạo ra bởi nhà máy, mà thực hiện IFactory, được tạo ra bởi AbstractFactory.

Để hiểu điều này thật ngớ ngẩn, hãy tiếp tục phương trình của chúng tôi:

AbstractFactory thực hiện I AbTHERFactory, được tạo bởi ... Tóm tắt.

Tôi hy vọng bạn nhìn thấy điểm. Không bị lẫn lộn, và xin đừng phát minh ra những thứ không tồn tại vì lý do.

-

PS : Factory for Products là AbstractFactory và Factory for Trừu tượng cũng sẽ là một ví dụ khác về AbstractFactory.

//Abstract factory - Provides interface to create factory of related products
interface PizzaIngredientsFactory{    
   public Dough createDough(); //Will return you family of Dough
   public Clam createClam();   //Will return you family of Clam
   public Sauce createSauce(); //Will return you family of Sauce
}

class NYPizzaIngredientsFactory implements PizzaIngredientsFactory{

   @Override
   public Dough createDough(){
      //create the concrete dough instance that NY uses
      return doughInstance;
   }

   //override other methods
} 

Các định nghĩa cuốn sách văn bản đã được cung cấp bởi câu trả lời khác. Tôi nghĩ tôi sẽ cung cấp một ví dụ về nó quá.

Vì vậy, ở đây PizzaIngredientsFactorylà một nhà máy trừu tượng vì nó cung cấp các phương pháp để tạo ra dòng sản phẩm liên quan.

Lưu ý rằng mỗi phương pháp trong nhà máy trừu tượng là một phương pháp Nhà máy của riêng mình. Giống như createDough()bản thân nó là một phương thức nhà máy mà việc triển khai cụ thể sẽ được cung cấp bởi các lớp con như thế nào NYPizzaIngredientsFactory. Vì vậy, sử dụng mỗi vị trí khác nhau này có thể tạo ra các trường hợp của các thành phần bê tông thuộc về vị trí của họ.

Phương pháp nhà máy

Cung cấp thể hiện của thực hiện cụ thể

Trong ví dụ:
- createDough()- cung cấp thực hiện cụ thể cho bột. Vì vậy, đây là một phương pháp nhà máy

abstract Factory

Cung cấp giao diện để tạo họ các đối tượng liên quan

Trong ví dụ này:
- PizzaIngredientsFactorylà một nhà máy trừu tượng vì nó cho phép để tạo ra một bộ có liên quan của các đối tượng như Dough, Clams, Sauce. Để tạo từng họ đối tượng, nó cung cấp một phương thức xuất xưởng.

Ví dụ từ các mẫu thiết kế Head First

Tôi có một số điểm để đóng góp với câu trả lời của John như sau:

nhà máy trừu tượng là một nhà máy của nhà máy!

Với sự "Factory Method" (vì chỉ là "Nhà máy" là mơ hồ), bạn tạo ra hiện thực ( Lemon, Orange, vv) của một giao diện cụ thể - chẳng hạn, IFruit. Nhà máy này có thể được gọi CitricFruitFactory.

Nhưng bây giờ bạn muốn tạo ra một loại trái cây khác mà CitricF fruitFactory không thể tạo ra. Có lẽ quy tắc CitricFruitFactorysẽ không có ý nghĩa nếu bạn tạo ra một thứ Strawberrytrong đó (dâu tây không phải là một loại trái cây có múi!).

Vì vậy, bạn có thể tạo ra một nhà máy mới được gọi là RedFruitFactorysản xuất Strawberry, Raspberryvv

Giống như John Women'sella đã nói: "Với mô hình Nhà máy Trừu tượng, bạn tạo ra các triển khai của một giao diện Nhà máy cụ thể - ví dụ: IFruitFactoryMỗi người đều biết cách tạo ra các loại trái cây khác nhau."

Đó implementatios của IFruitFactorylà CitricFruitFactoryvà RedFruitFactory!

Nguồn của tôi là: StackOverflow, tutorialspoint.com, programmers.stackexchange.comvà CodeProject.com.

Factory Method(còn được gọi là Factory) dành cho khách hàng tách rời của Interfaceviệc thực hiện. Đối với mẫu chúng tôi có một Shapegiao diện với hai Circlevà Squaretriển khai. Chúng tôi đã định nghĩa một lớp nhà máy với một phương thức nhà máy với một tham số xác định, chẳng hạn như Typevà triển khai Shapegiao diện liên quan mới .

Abstract Factorychứa một số phương thức nhà máy hoặc giao diện nhà máy bởi một số triển khai của nhà máy. Đối với mẫu tiếp theo ở trên, chúng tôi có một Colorgiao diện với hai Redvà Yellowtriển khai. Chúng tôi đã xác định một ShapeColorFactorygiao diện với hai RedCircleFactoryvà YellowSquareFactory. Sau mã cho giải thích khái niệm này:

interface ShapeColorFactory
{
    public Shape getShape();
    public Color getColor();
}

class RedCircleFactory implements ShapeColorFactory
{
    @Override
    public Shape getShape() {
        return new Circle();
    }

    @Override
    public Color getColor() {
        return new Red();
    }
}
class YellowSquareFactory implements ShapeColorFactory
{
    @Override
    public Shape getShape() {
        return new Square();
    }

    @Override
    public Color getColor() {
        return new Yellow();
    }
} 

Ở đây sự khác biệt giữa FactoryMethodvà AbstractFactory. Factory Methodnhư chỉ đơn giản là trả lại một lớp bê tông của một giao diện nhưng Abstract Factorylợi nhuận factory of factory. Nói cách khác, Abstract Factorytrả về sự kết hợp khác nhau của một loạt các giao diện.

Tôi hy vọng lời giải thích của tôi hữu ích.

Sự khác biệt chính trong các nhà máy đó là khi bạn muốn làm gì với các nhà máy và khi bạn muốn sử dụng nó.

Đôi khi, khi bạn đang thực hiện IOC (đảo ngược điều khiển, ví dụ như hàm tạo của hàm tạo), bạn biết rằng bạn có thể tạo các đối tượng rắn. Như đã đề cập trong ví dụ trên về trái cây, nếu bạn đã sẵn sàng tạo đối tượng của trái cây, bạn có thể sử dụng mô hình nhà máy đơn giản .

Nhưng nhiều lần, bạn không muốn tạo các vật thể rắn, chúng sẽ đến sau trong luồng chương trình. Nhưng cấu hình cho bạn biết những gì loại máy bạn muốn sử dụng khi khởi động, thay vì tạo đối tượng, bạn có thể vượt qua trên các nhà máy mà có nguồn gốc từ một lớp nhà máy chung cho các nhà xây dựng trong IOC.

Vì vậy, tôi nghĩ rằng nó cũng là về cuộc đời và sáng tạo của đối tượng.

Cả hai Factory Methodvà Abstract Factorygiữ khách hàng tách rời khỏi các loại bê tông. Cả hai đều tạo đối tượng, nhưng Factoryphương thức sử dụng sự kế thừa trong khiAbstract Factory thành phần sử dụng.

Cái Factory Methodđược kế thừa trong các lớp con để tạo ra các đối tượng cụ thể (sản phẩm) trong khiAbstract Factory cung cấp giao diện cho việc tạo các sản phẩm gia đình có liên quan và phân lớp của những giao diện xác định làm thế nào để tạo ra sản phẩm có liên quan.

Sau đó, các lớp con này khi được khởi tạo được chuyển vào các lớp sản phẩm nơi nó được sử dụng làm kiểu trừu tượng. Các sản phẩm liên quan trong một Abstract Factorythường được thực hiện bằng cách sử dụng Factory Method.

Mở rộng câu trả lời của John Women'sella:

Apple, Banana, CherryDụng cụ FruitFactoryvà có một phương pháp gọi Createlà tự chịu trách nhiệm của việc tạo ra Apple hoặc chuối hoặc Cherry. Bạn đã hoàn thành, với Factoryphương pháp của bạn .

Bây giờ, bạn muốn có Createmột món salad đặc biệt từ trái cây của bạn và có Nhà máy trừu tượng của bạn . Tóm tắt Factory biết cách tạo Salad đặc biệt của bạn từ Apple, Banana và Cherry.

public class Apple implements Fruit, FruitFactory {
    public Fruit Create() {
        // Apple creation logic goes here
    }
}

public class Banana implements Fruit, FruitFactory {
    public Fruit Create() {
        // Banana creation logic goes here
    }
}

public class Cherry implements Fruit, FruitFactory {
    public Fruit Create() {
        // Cherry creation logic goes here
    }
}

public class SpecialSalad implements Salad, SaladFactory {
    public static Salad Create(FruitFactory[] fruits) {
        // loop through the factory and create the fruits.
        // then you're ready to cut and slice your fruits 
        // to create your special salad.
    }
}

Theo định nghĩa, chúng ta có thể kéo ra sự khác biệt của hai:

Factory: Một giao diện được sử dụng để tạo một đối tượng, nhưng lớp con quyết định lớp nào sẽ khởi tạo. Việc tạo đối tượng được thực hiện khi cần thiết.

Nhà máy trừu tượng: Mô hình nhà máy trừu tượng hoạt động như một siêu nhà máy tạo ra các nhà máy khác. Trong mẫu Tóm tắt Factory, một giao diện chịu trách nhiệm tạo ra một tập hợp các đối tượng liên quan hoặc các đối tượng phụ thuộc mà không chỉ định các lớp cụ thể của chúng.

Vì vậy, trong các định nghĩa ở trên, chúng ta có thể nhấn mạnh vào một sự khác biệt cụ thể. nghĩa là, mẫu Factory chịu trách nhiệm tạo các đối tượng và Tóm tắt Factory chịu trách nhiệm tạo ra một tập hợp các đối tượng liên quan; rõ ràng cả hai thông qua một giao diện.

Mẫu nhà máy:

public interface IFactory{
  void VehicleType(string n);
 }

 public class Scooter : IFactory{
  public void VehicleType(string n){
   Console.WriteLine("Vehicle type: " + n);
  }
 }

 public class Bike : IFactory{
  public void VehicleType(string n) {
  Console.WriteLine("Vehicle type: " + n);
  }
 }

 public interface IVehicleFactory{
  IFactory GetVehicleType(string Vehicle);
 }

 public class ConcreteVehicleFactory : IVehicleFactory{
 public IFactory GetVehicleType(string Vehicle){
   switch (Vehicle){
    case "Scooter":
     return new Scooter();
    case "Bike":
     return new Bike();
    default:
    return new Scooter();
  }
 }

 class Program{
  static void Main(string[] args){
   IVehicleFactory factory = new ConcreteVehicleFactory();
   IFactory scooter = factory.GetVehicleType("Scooter");
   scooter.VehicleType("Scooter");

   IFactory bike = factory.GetVehicleType("Bike");
   bike.VehicleType("Bike");

   Console.ReadKey();
 }
}

Mô hình nhà máy trừu tượng:

interface IVehicleFactory{
 IBike GetBike();
 IScooter GetScooter();
}

class HondaFactory : IVehicleFactory{
     public IBike GetBike(){
            return new FZS();
     }
     public IScooter GetScooter(){
            return new FZscooter();
     }
 }
class HeroFactory: IVehicleFactory{
      public IBike GetBike(){
            return new Pulsur();
     }
      public IScooter GetScooter(){
            return new PulsurScooter();
     }
}

interface IBike
    {
        string Name();
    }
interface IScooter
    {
        string Name();
    }

class FZS:IBike{
   public string Name(){
     return "FZS";
   }
}
class Pulsur:IBike{
   public string Name(){
     return "Pulsur";
   }
}

class FZscooter:IScooter {
  public string Name(){
     return "FZscooter";
   }
}

class PulsurScooter:IScooter{
  public string Name(){
     return "PulsurScooter";
   }
}

enum MANUFACTURERS
{
    HONDA,
    HERO
}

class VehicleTypeCheck{
        IBike bike;
        IScooter scooter;
        IVehicleFactory factory;
        MANUFACTURERS manu;

        public VehicleTypeCheck(MANUFACTURERS m){
            manu = m;
        }

        public void CheckProducts()
        {
            switch (manu){
                case MANUFACTURERS.HONDA:
                    factory = new HondaFactory();
                    break;
                case MANUFACTURERS.HERO:
                    factory = new HeroFactory();
                    break;
            }

      Console.WriteLine("Bike: " + factory.GetBike().Name() + "\nScooter: " +      factory.GetScooter().Name());
        }
  }

class Program
    {
        static void Main(string[] args)
        {
            VehicleTypeCheck chk = new VehicleTypeCheck(MANUFACTURERS.HONDA);
            chk.CheckProducts();

            chk= new VehicleTypeCheck(MANUFACTURERS.HERO);
            chk.CheckProducts();

            Console.Read();
        }
    }

Kiểm tra ở đây: http://www.allapplabs.com/java_design_patterns/abstract_factory_pattern.htm có vẻ như phương thức Factory sử dụng một lớp cụ thể (không trừu tượng) làm lớp cơ sở trong khi nhà máy Trừu tượng sử dụng lớp trừu tượng cho việc này. Ngoài ra, nếu sử dụng một giao diện thay vì lớp trừu tượng, kết quả sẽ là một triển khai khác của mẫu Tóm tắt Factory.

: D

Tóm tắt Factory là khuôn mẫu để tạo các loại giao diện khác nhau. Giả sử bạn có dự án yêu cầu bạn phân tích các loại tệp csv khác nhau chứa thông tin cụ thể về số lượng, giá cả và mặt hàng như một số chứa dữ liệu về các loại trái cây khác về sôcôla và sau đó phân tích cú pháp, bạn cần cập nhật thông tin này trong cơ sở dữ liệu tương ứng của họ để bây giờ bạn có thể có một nhà máy trừu tượng trả lại cho bạn trình phân tích cú pháp và trình sửa đổi và sau đó nhà máy phân tích cú pháp này có thể trả về cho bạn đối tượng Trình phân tích cú pháp sô cô la, Đối tượng phân tích cú pháp trái cây, và tương tự Nhà máy sửa đổi có thể trả về đối tượng Trình sửa đổi sô cô la, đối tượng Trình sửa đổi trái cây, v.v.

Tôi nghĩ rằng chúng ta có thể hiểu sự khác biệt giữa hai cái này bằng cách xem mã ví dụ Java8:

  interface Something{}

  interface OneWhoCanProvideSomething {
     Something getSomething();
  }

  interface OneWhoCanProvideCreatorsOfSomething{
     OneWhoCanProvideSomething getCreator();
  }


public class AbstractFactoryExample {

    public static void main(String[] args) {
        //I need something
        //Let's create one
        Something something = new Something() {};

        //Or ask someone (FACTORY pattern)
        OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeA = () -> null;
        OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeB = () -> null;

        //Or ask someone who knows soemone who can create something (ABSTRACT FACTORY pattern)
        OneWhoCanProvideCreatorsOfSomething oneWhoCanProvideCreatorsOfSomething = () -> null;

        //Same thing, but you don't need to write you own interfaces
        Supplier<Something> supplierOfSomething = () -> null;
        Supplier<Supplier<Something>> supplierOfSupplier = () -> null;
    }

}

Bây giờ câu hỏi là bạn nên sử dụng cách sáng tạo nào và tại sao: Cách thứ nhất (không có mẫu, chỉ là hàm tạo đơn giản): tự tạo không phải là ý tưởng hay, bạn phải thực hiện tất cả công việc và mã khách hàng của bạn được gắn với việc thực hiện cụ thể.

Cách thứ hai (sử dụng mẫu Factory): cung cấp cho bạn lợi ích mà bạn có thể vượt qua bất kỳ loại triển khai nào, có thể cung cấp loại khác nhau dựa trên một số điều kiện (có thể là một tham số được truyền cho phương thức tạo).

Cách thứ ba (sử dụng mẫu Tóm tắt Factory): Điều này cho phép bạn linh hoạt hơn. Bạn có thể tìm thấy các loại người tạo khác nhau dựa trên một số điều kiện (có thể là một tham số được thông qua).

Lưu ý rằng bạn luôn có thể thoát khỏi mẫu Factory bằng cách kết hợp hai điều kiện với nhau (làm tăng nhẹ độ phức tạp của mã và khớp nối), tôi đoán đó là lý do tại sao chúng ta hiếm khi thấy các trường hợp sử dụng thực tế của mẫu Tóm tắt Factory.