Abstract Factory Pattern Là Gì

     

Pattern máy hai mà bạn muốn giới thiệu chính là Abstract Factory. Nó có thể được hình dung như một nhà máy lớn, bên phía trong có các nhà máy nhỏ tuổi hơn cung cấp ra hầu như loạt sản phẩm liên quan mang lại nhau.

Bạn đang xem: Abstract factory pattern là gì

Hãy mang một nhà phân phối ô tô làm cho ví dụ, chẳng hạn Hyundai. Họ có nhà máy, hoặc xưởng, sản xuất bánh xe: bánh của Azera, bánh của Sonata, bánh của Veloster, v.v… Đến lượt cửa xe, cũng có thể có nhà máy chế tạo cửa Azera, cửa Sonata, cửa ngõ Veloster. Thân xe, rượu cồn cơ, đèn, và các thành phần khác bao hàm nhà máy sản xuất chúng.

Vậy phải tổ chức việc thêm vào ấy như vậy nào? thuộc theo dõi tiếp nhé!

Nếu bắt đầu làm thân quen với kiến thiết Pattern, gồm thể bạn sẽ muốn đọc bài bác tổng quan của bản thân tại phía trên hoặc bài bác về Singleton trên đây.


ABSTRACT FACTORY


Giống như ở bài bác trước về Singleton, bài bác này bao gồm 5 phần:

Ý tưởng chínhVấn đề cần giải quyếtCấu trúcCode ví dụLưu ýVài lời bình luận

Ý tưởng chính

Khai báo một interface với các phương thức tạo các đối tượng người sử dụng abstract.Một hệ thống phân cấp với những “dòng xe” và các “bộ phận xe”.Tránh áp dụng từ khoá new.

Vấn đề cần giải quyết

Khi bạn có nhu cầu phần mềm của mình hoàn toàn có thể được thực hiện trên nhiều nền tảng khác nhau, bạn phải tìm bí quyết xử lý vấn đề khởi chế tạo các đối tượng người dùng trên những nền tảng đó. “Nền tảng” nghỉ ngơi đây có thể hiểu là hệ điều hành, các đại lý dữ liệu,… vào ví dụ ở chỗ mở đầu, Azera, Sonata và Veloster chính là các nền tảng.

Tuy nhiên, nếu bạn xử lý chuyện này bởi những câu if ... Else thì chẳng mấy chốc code của các bạn sẽ thành một mớ bòng bong vì ứng dụng sẽ dần dần nở to. Với đó là vì sao mà Abstract Factory ra đời.

Cấu trúc

Ta cần có năm thành phần, đó là:

Abstract Platform: interface hoặc abstract class với những phương thức tạo ra các “sản phẩm”Concrete Platforms: Khai báo rõ ràng các “nền tảng” (PlatformOne, PlatformTwo vào hình)Abstract Products: interface hoặc abstract class định nghĩa những loại “sản phẩm” (AbstractProductOne, AbstractProductTwo trong hình)Concrete Products: Khai báo cụ thể các “sản phẩm” (ProductOnePlatformOne, ProductOnePlatformTwo, ProductTwoPlatformOne, ProductTwoPlatformTwo trong hình)Client: Đối tượng thực hiện Abstract Platform và Abstract Product
*
*
*

Bạn cũng cần kiểm tra các tiêu chuẩn dưới đây.

Hãy chăm chú liệu việc tự do với các “nền tảng” và việc khởi chế tạo các đối tượng có buộc phải là sự việc của khối hệ thống hiện tại tuyệt không.Làm rõ đâu là “nền tảng”, đâu là “sản phẩm”, và mối quan hệ giữa chúng.Định nghĩa một factory (interface) với rất đầy đủ các cách làm khởi tạo từng sản phẩm.Định nghĩa các lớp dẫn xuất của interface trên, bảo vệ đã “bao gói” những phương thức khởi tạo ra (ứng với câu hỏi gọi new).Client không được dùng new mà đề xuất dùng các phương thức mà các bạn đã khai báo sinh hoạt interface.

Xem thêm: Tgif Là Gì ? Các Nghĩa Của Từ Viết Tắt Tgif

Code ví dụ

Dưới đây là code ví dụ về việc khởi tạo các loại CPU, MMU, viết bằng ngữ điệu Java.

Các “sản phẩm” (CPU, MMU)

// class CPUabstract class CPU // class EmberCPUclass EmberCPU extends CPU // class EnginolaCPUclass EnginolaCPU extends CPU // class MMUabstract class MMU // class EmberMMUclass EmberMMU extends MMU // class EnginolaMMUclass EnginolaMMU extends MMU Các “nền tảng” nuốm thể// class EmberFactoryclass EmberToolkit extends AbstractFactory
Override
public MMU createMMU() return new EmberMMU(); // class EnginolaFactoryclass EnginolaToolkit extends AbstractFactory
Override
public MMU createMMU() return new EnginolaMMU(); “Nền tảng” trừu tượngenum Architecture ENGINOLA, EMBERabstract class AbstractFactory private static final EmberToolkit EMBER_TOOLKIT = new EmberToolkit(); private static final EnginolaToolkit ENGINOLA_TOOLKIT = new EnginolaToolkit(); // Returns a concrete factory object that is an instance of the // concrete factory class appropriate for the given architecture. static AbstractFactory getFactory(Architecture architecture) AbstractFactory factory = null; switch (architecture) case ENGINOLA: factory = ENGINOLA_TOOLKIT; break; case EMBER: factory = EMBER_TOOLKIT; break; return factory; public abstract CPU createCPU(); public abstract MMU createMMU();Clientpublic class Client public static void main(String<> args) AbstractFactory factory = AbstractFactory.getFactory(Architecture.EMBER); CPU cpu = factory.createCPU();

Lưu ý

Creational patterns hoàn toàn có thể kết hợp với nhau hoặc thay thế sửa chữa cho nhau. cùng để ra quyết định dùng pattern làm sao hoặc phối hợp như ráng nào, chúng ta phải chú ý trường hợp của mình.

Abstract Factory thường xuyên được kết hợp với Factory Method, đôi lúc là cả Protoype nữa.

Abstract Factory hoàn toàn có thể thay chũm cho Facade để che giấu đều lớp được sệt tả riêng cho từng “nền tảng”.

Phân biệt Abstract Factory và Builder. Trong những khi Abstract Factory chú trọng việc khởi tạo đầy đủ nhóm đối tượng người tiêu dùng có tương quan đến nhau (chiều ngang); thì Builder chú trọng vào việc tạo thành một đối tượng qua nhiều bước tiếp liền nhau, giống hệt như một dây chuyền vậy (chiều dọc). Trường đúng theo của Abstract Factory, đối tượng người dùng được trả về ngay; còn vào trường thích hợp của Builder, đối tượng là tác dụng của cả vượt trình.

Thông thường, việc thiết kế hệ thống sẽ đi từ Factory Method (dễ hiểu, dễ dàng tuỳ biến) thành Abstract Factory, Prototype, hoặc Builder (mềm dẻo hơn, phức hợp hơn) ví như như người kiến tạo cảm thấy tính mềm mỏng là cần thiết.

Vài lời bình luận

Như đã nói sinh sống trên, các creational pattern có thể thay thế lẫn nhau hoặc kết phù hợp với nhau tuỳ trả cảnh, và bài toán thiết kế hoàn toàn có thể đi trường đoản cú Factory Method cho Abstract Factory. Tức là bạn yêu cầu xem xét thật kỹ lưỡng bài toán của mình để biết phải lựa chọn phương án nào, thay bởi vội rubi lựa chọn.

Xem thêm: Tìm Hiểu Về Mạng Kết Nối Không Dây Có Lợi Ích Gì, Mạng Không Dây Là Gì

Các pattern được đưa ra cụ thể là đem đến cái lợi lớn cho những lập trình viên nhưng chúng ta không nên phụ thuộc vào chúng. Theo tôi, đừng lúc nào nên trả định rằng: “Chắc tương lai hệ thống sẽ đề nghị thế này, cố kỉnh kia” hay “Có lẽ sau này hệ thống cần bắt buộc mềm dẻo hơn, flexible hơn buộc phải phải chọn Abstract Factory”. Code ít hơn khi nào cũng giỏi hơn.