Đã lâu không xoay quay về với series design pattern. Tiếp tục với Creational Pattern (pattern khởi tạo), tiếp cận không còn luôn luôn cả luồng. Bài viết lách này trình làng với bạn bè pattern Factory Method, một pattern khá có tiếng, được rất nhiều bạn bè biết cho tới.
Anh em ready ko, chính thức ngay lập tức thôi!
Bạn đang xem: factory method là gì
1. Định nghĩa Factory Method pattern
Rất chi là rất khó hiểu tuy nhiên luôn luôn luôn luôn là khái niệm về pattern. Nếu bạn bè mới mẻ lần hiểu về pattern này lần thứ nhất thì chớ lo ngại. Cứ lướt qua quýt khái niệm, trở xuống ví dụ, từng từng một tiếp tục rõ nét rời khỏi.
Sau khi hiểu không còn và đem loại hiểu cơ phiên bản về pattern, trở lại hiểu định nghĩa thỉnh thoảng lại vỡ đúng ra nhiều điều.
Factory Method is a creational design pattern that provides an interface for creating objects in a superclass, but allows subclasses lớn alter the type of objects that will be created. Factory method là design pattern khởi tạo ra cung ứng interface nhằm khởi tạo ra những đối tượng người dùng (object) ở superclass, tuy nhiên được chấp nhận class phụ (subclasses) thay cho thay đổi loại của object sẽ tiến hành tạo nên.
Nghe ảo quái canada ko, khởi tạo ra ở superclass tuy nhiên lại được chấp nhận thay cho thay đổi được loại của object cho tới phù phù hợp với subclass của tớ. Vậy Factory Method pattern đã trải vấn đề này như vậy nào?
2. Đặt vấn đề
Giả sử như bạn bè đang được khởi tạo ra một phần mềm tương quan cho tới vận chuyển (cũng hoàn toàn có thể gọi là khối hệ thống quản lý và vận hành vận chuyển – logistics management application). Thứ nhất, chi phí còn không nhiều nên bạn bè chỉ nỗ lực xoay xoả góp nhặt mua sắm được con cái xe tải lớn.
Quản lý vận chuyển vì thế xe tải lớn (truck), bạn bè sẽ khởi tạo Truck class.
Một thời hạn sau, những ngôi nhà góp vốn đầu tư bựa bần nhảy vô (nhầm, những agents) nhảy vô, phần mềm của bạn bè trở thành phổ cập hơn hết Ahamove, Nin-Ja Van. Một ông quý khách lớn bự, cất cánh vô nhờ bạn bè quản lý và vận hành thêm thắt vận chuyển trên biển khơi (sea logistics).
Ngon, business cách tân và phát triển rồi, tuy nhiên giờ code thì sao?. Truck class thì viết lách chan chứa vô rồi, nhưng mà thêm thắt Ship vô thì thay cho thay đổi tổn thất code base. Mà không chỉ có đem từng sea, trong tương lai còn tồn tại hé thị ngôi trường vận chuyển sản phẩm ko thì sao?.
Với Factory Method pattern, với Việc phía trên, bạn bè ước muốn thi công một class sao cho tất cả Truck, Sea hoặc Airplane trong tương lai hoàn toàn có thể thừa kế. Mỗi lượt xử lý lô hàng là từng lượt tạo ra transport.
Vậy công thức createTransport sẽ khởi tạo rời khỏi object đúng mực cho tới từng mô hình vận gửi.
- createTransport ở RoadLogistics tiếp tục return new Truck()
- createTransport ở SeaLogistics tiếp tục return new Ship()
Phương thức createTransport tiếp tục nằm tại SuperClass, subclass (Road, Sea) thời điểm này trả về những loại không giống nhau.
Constructor khởi tạo ra thời điểm này dịch chuyển về Factory Method class (superclass), những class con cái triển khai override lại, toàn bộ những công thức vận gửi đều dùng cộng đồng một interface, loại không giống là loại trả về cho tới từng class
Ví dụ, cả Truck (xe tải) và Ship (thuyền) đều implement cộng đồng Transport interface. Trong interface rõ nét khai báo method deliver(). Nhưng từng class lai hiện tại thức method này ở class của tớ không giống nhau. Truck thì dịch chuyển bên trên đường đi bộ, Ship thì dịch chuyển bên trên đàng sông.
Factory Method thời điểm này, sau thời điểm khởi tạo ra constructor ở class RoadLogistics tiếp tục trả về truck object, còn ShipLogistics tiếp tục trả về ship object. Rõ ràng nếu như thực hiện được vậy thì sau này còn có airplane hoặc sản phẩm ko ngoài trái đất gì rồi cũng ko là yếu tố.
Xem thêm: sat test là gì
Tất cả những class đều implement cộng đồng một common interface, với Factory Method, tao pass những object cho tới đích đối tượng người dùng tuy nhiên ko thực hiện đánh tan cút code base của Factory.
4. Thực tế xử lý bài bác toán
Rồi, giờ tổ chức thực hiện ví dụ với class diagram
- Số 1: Product tiếp tục khai báo interface, điều này là common interface toàn bộ những class đều dùng. doStuff() phía trên bạn bè hoàn toàn có thể hiểu là vận gửi, xác nhận đơn, gửi gắm thành công xuất sắc hoặc bất kể cái gì không giống. Nói cộng đồng là đem vận chuyển vì thế mẫu mã nào là thì nó cũng có thể có những công thức cần thiết implement.
- Số 2: Concrete ProductA và Concrete ProductB tiếp tục implement inferface common, ví dụ làm cái gi thì viết lách vô phía trên. Ví dụ thuyền thì số km tính vì thế hải lý, còn đường đi bộ thì tính vì thế km
- Số 3: Class Creator tiếp tục khai báo những factory method trả về new product objects. Kiểu trả về ở phía trên khớp với Product interface là ok
- Số 4: Concrete Creators tiếp tục override những method base ở Factory với những loại trả về không giống nhau.
5. Code ví dụ
Ví dụ giờ bản thân sử dụng loại Factory Method pattern sẽ tạo một chiếc UI cross platform (đi qua không ít platform). Cái UI này còn có một nút nhấn, kể từ cơ hé được 2 loại:
- Web dialog
- Windows dialog
Lúc này ở interface sẽ có được 2 method là render(), show loại button rời khỏi. Cái loại nhị là ấn vô nhằm hé dialog.
Ở GUIFactory.java tao define interface tạo ra button và click. Render thay đổi qua quýt trở nên createButton nha bạn bè. Đây là 2 common interface.
package refactoring_guru.abstract_factory.example.factories;
import refactoring_guru.abstract_factory.example.buttons.Button;
import refactoring_guru.abstract_factory.example.checkboxes.Checkbox;
/**
* Abstract factory knows about all (abstract) product types.
*/
public interface GUIFactory {
Button createButton();
Button onClick();
}
Kế cho tới là MacOS (giả loại sử như thể MacOS) mang theo nha. Cái này tiếp tục implement GUIFactory.
package refactoring_guru.abstract_factory.example.factories;
import refactoring_guru.abstract_factory.example.buttons.Button;
import refactoring_guru.abstract_factory.example.buttons.MacOSButton;
import refactoring_guru.abstract_factory.example.checkboxes.Checkbox;
import refactoring_guru.abstract_factory.example.checkboxes.MacOSCheckbox;
/**
* Each concrete factory extends basic factory and responsible for creating
* products of a single variety.
*/
public class MacOSFactory implements GUIFactory {
@Override
public Button createButton() {
return new MacOSButton();
}
@Override
public function onClick() {
return smt with click event
}
}
Phía Windows factory cũng tương tự
package refactoring_guru.abstract_factory.example.factories;
import refactoring_guru.abstract_factory.example.buttons.Button;
import refactoring_guru.abstract_factory.example.buttons.WindowsButton;
import refactoring_guru.abstract_factory.example.checkboxes.Checkbox;
import refactoring_guru.abstract_factory.example.checkboxes.WindowsCheckbox;
/**
* Each concrete factory extends basic factory and responsible for creating
* products of a single variety.
*/
public class WindowsFactory implements GUIFactory {
@Override
public Button createButton() {
return new WindowsButton();
}
@Override
public function onClick() {
return smt with click event
}
}
Footer
Xong phần Factory, giờ là khi một cách thực tế Button cho tới từng class. Button là common interface đem method paint() nhằm render button.
package refactoring_guru.abstract_factory.example.buttons;
/**
* Abstract Factory assumes that you have several families of products,
* structured into separate class hierarchies (Button/Checkbox). All products of
* the same family have the common interface.
*
* This is the common interface for buttons family.
*/
public interface Button {
void paint();
}
Footer
Lúc này ở MacButton thì khoẻ rồi. Override method và implement những gì mình yêu thích thôi
package refactoring_guru.abstract_factory.example.buttons;
/**
* All products families have the same varieties (MacOS/Windows).
*
* This is a MacOS variant of a button.
*/
public class MacOSButton implements Button {
@Override
public void paint() {
System.out.println("You have created MacOSButton.");
}
}
Xong xuôi đâu vô đấy thì ở application còn giúp gì nữa đâu. Cứ gọi factory là trả rời khỏi đích object của button cần thiết tạo ra, quí button thì button, quí checkbox thì đem checkbox. Rồi kể từ cơ cứ gọi rời khỏi những method implement là kết thúc thôi.
package refactoring_guru.abstract_factory.example.app;
import refactoring_guru.abstract_factory.example.buttons.Button;
import refactoring_guru.abstract_factory.example.checkboxes.Checkbox;
import refactoring_guru.abstract_factory.example.factories.GUIFactory;
/**
* Factory users don't care which concrete factory they use since they work with
* factories and products through abstract interfaces.
*/
public class Application {
private Button button;
private Checkbox checkbox;
public Application(GUIFactory factory) {
button = factory.createButton();
checkbox = factory.createCheckbox();
}
public void paint() {
button.paint();
checkbox.paint();
}
}
Footer
6. Ưu nhược điểm
- Đầu tiên là với Factory pattern bạn bè tiếp tục giới hạn chạm chừng Một trong những class.
- Mỗi product giờ nằm tại một điểm, chia nhỏ ra rõ nét, đơn giản rộng lớn nhằm maintain trong tương lai.
- Open,close principles: Anh em tự do tạp thêm thắt creator mới mẻ nhưng mà ko cần thiết chạm cho tới những methods, class cũ đang được implement. không nhiều bug rộng lớn.
- Sử dụng Factory pattern thỉnh thoảng thực hiện cho tới code trở thành khó khăn hiểu rộng lớn, phức tạp. Trường thích hợp có tương đối nhiều subclass.
7. Tham khảo
- Design Patterns – SourceMaking
- Adapter Pattern – Xoá nhoà không giống biệt
- Mediator Design Pattern – Collaborate via me
Thank you for your time – Happy coding!
Tác giả: Kiên Nguyễn
Cảm ơn bạn bè đang được dành riêng thời hạn nhằm hiểu bài bác. Anh em hoàn toàn có thể xem thêm thêm thắt tin tưởng tuyển dụng IT bên trên TopDev nhằm cách tân và phát triển sự nghiệp.
Xem thêm:
Xem thêm: ete là gì
Một số custom hooks hoặc dùng cho tới React
AngularJS Là Gì? Khác Biệt Nào Giữa Angular Và Frontend Framework Khác
Mediator Design Pattern – Collaborate via me
Bình luận