2. What is a design pattern?
• Design patterns represent the best practices used by experienced
object-oriented software developers. Design patterns are solutions
to general problems that software developers faced during
software development. These solutions were obtained by trial and
error by numerous software developers over quite a substantial
period of time.
• Types of Design Patterns
1. Creational Patterns
2. Structural Patterns
3. Behavioral Patterns
• Other reference:S.O.L.I.D
3. The Plan
Cover 4 design patterns
Problem
Pattern Abstract(UML)
Code
Your participation is encouraged!
7. Singleton
• Solution: use singleton
The Singleton pattern attempts to solve the
issue of repeatedly using an object instance, but
only wishing to instantiate it once within a
single transaction context. Common uses for
this pattern include:
1. Global variables - whilst Apex does not
support global variables across
execution contexts, this pattern allows
you to create an object instance that will
only ever be instantiated once within an
execution context.
2. Limiting Impact of Governor Limits
12. 2. Facade
Code
Conclusion
The Facade design pattern increases the maintainability of Apex code by simplifying the
execution of one or complex classes with a facade class.
20. 4.Strategy
Code
Conclusion
The Strategy design pattern uses aggregation instead of inheritance, allowing better
decoupling between the behavior and the class that uses the behavior. This allows the
behavior to be changed without breaking the classes that use it, and the classes can switch
between behaviors by changing the specific implementation used without requiring any
significant code changes.
Nó có thể hiểu là 1 trong những giải pháp điển hình cho các vấn đề chung trong thiết kế phần mềm
Cũng có thể hiểu là 1 bản thiết kế được tạo sẵn mà có thể tùy chỉnh dễ dàng để giải quyết vấn đề thiết kế lặp lại trong các source code của mình
Nó đại diện cho các phương pháp hay nhất, được các nhà phát triển phần mềm hướng đối tượng có kinh nghiệm sử dụng. Nó là giải pháp cho các vấn đề chung, mà các dev thường gặp phải trong quá trình làm PM. -> được đúc rút lại sau 1 khoảng thời gian khá dài
Các developer thường viết mã không hiệu quả, nên có thể gây ra lặp lại việc khởi tạo các đối tượng. Dẫn đế kết quả đoạn code hoạt động ko hiệu quả, và có thể vi phạm governor limits.
Ví dụ ở trên cho thấy, account trigger ở trên đã lặp lại nhiều lần việc gọi pthuc sObject getDescribe, dẫn đến kết quả là vi phạm governor limit, nếu account có hơn 100 bản ghi đc upsert
Như vậy giải pháp là gì?
Mẫu Singleton cố gắng giải quyết vấn đề liên tục sử dụng một khởi tạo đối tượng, nhưng chỉ muốn khởi tạo nó một lần trong một ngữ cảnh giao dịch duy nhất. Sử dụng phổ biến cho mẫu này bao gồm:
In order to implement a Singleton pattern in Apex, the class must instantiate only a single instance and be globally accessible. It is implemented by:
Creating a class with a method that creates a new instance of the class if it doesn't already exist
If it already exists, then simply return a reference to that object
The above code demonstrates the following:
The getInstance() static method will only instantiate an instance of the class if it doesn't already exist in a lazy-initialization manner
The constructor and the instance variable for the class is private to make sure that it cannot be instantiated outside of the getInstance() method
The class defines a private, static instance of itself that can only be referenced via the getInstance() static method
The ID member stores the record ID of the record type and is initialized in the constructor
This allows the trigger to obtain a reference to the record type without breaching governor limits.
Static • Can modify member variables, methods, and blocks • Executed when? • When class is introduced (loaded) to runtime environment • How long does that last in Java? • Life of the JVM • In Apex? • Life of the transaction
facade: sinh ra để giải quyết vấn đề: khi client có quá nhiều lựa chọn, công việc cần phải làm để hoàn thành 1 việc ví dụ như:
mục đích của việc đi chợ: có đồ để nấu bữa trưa
nó giống như kiểu mình đi chợ: mua đồ, chọn đồ, thanh toán, chọn phương tiện, gói đồ, vận chuyển... -> việc này lặp đi lặp lại nhiều lần
thay vì đó mình thuê 1 thằng làm hết những thứ ở trên và mình chỉ việc trả tiền cho nó, để nhận dc hàng (mục đích của việc đi chợ)
thằng facade như kiểu: client cứ yêu cầu nó, nó sẽ tự làm cviec đó thay mình
Facade: biết rõ lớp của hệ thống con nào đảm nhận việc đáp ứng yêu cầu của client, sẽ chuyển yêu cầu của client đến các đối tượng của hệ thống con tương ứng.
Subsystems: cài đặt các chức năng của hệ thống con, xử lý công việc được gọi bởi Facade. Các lớp này không cần biết Facade và không tham chiếu đến nó.
Client: đối tượng sử dụng Facade để tương tác với các subsystem.
Các đối tượng Facade thường là Singleton bởi vì chỉ cần duy nhất một đối tượng Facade
Chúng ta sẽ làm thử 1 Ví dụ: Một công ty bán hàng online, chẳng hạn Tiki cung cấp nhiều lựa chọn cho khách hàng khi mua sản phẩm. Khi một sản phẩm được mua, nó sẽ qua các bước xử lý: lấy thông tin về tài khoản mua hàng, thanh toán, vận chuyển, gửi Email/ SMS thông báo.
Ứng dụng của chúng ta được thiết kế với Facade Pattern, bao gồm các class như sau:
Thông tin về tài khoản (AccountService) : lấy thông tin cơ bản của khách hàng thông qua email được cung cấp.
Dịch vụ thanh toán (PaymentService) : có thể thanh toán thông qua Paypal, thẻ tín dụng (Credit Card), tài khoản ngân hàng trực tuyến (E-banking), Tiền mặt (cash).
Dịch vụ vận chuyển (ShippingService) : có thể chọn Free Shipping, Standard Shipping, Express Shipping.
Dịch vụ email (EmailService) : có thể gửi mail cho khách hàng về tình hình đặt hàng, thanh toán, vận chuyển, nhận hàng.
Dịch vụ tin nhắn (SMS) : có thể gửi thông báo SMS cho khách hàng khi thanh toán online.
ShopFacade : là một Facade Pattern, class này bao gồm các dịch vụ có bên trong hệ thống. Nó cung cấp một vài phương thức để Client có thể dễ dàng mua hàng. Tùy vào nghiệp vụ mà nó sẽ sử dụng những dịch tương ứng, chẳng hạn dịch vụ SMS chỉ được sử dụng nếu khách hàng đăng ký mua hàng thông qua hình thức thanh toán online (Paypal, E-banking, …).
Client : là người dùng cuối sử dụng ShopFacade để mua hàng.
Composite là một mẫu thiết kế thuộc nhóm cấu trúc (Structural Pattern). Composite Pattern là một sự tổng hợp những thành phần có quan hệ với nhau để tạo ra thành phần lớn hơn. Nó cho phép thực hiện các tương tác với tất cả đối tượng trong mẫu tương tự nhau.
Composite Pattern được sử dụng khi chúng ta cần xử lý một nhóm đối tượng tương tự theo cách xử lý 1 object. Composite pattern sắp xếp các object theo cấu trúc cây để diễn giải 1 phần cũng như toàn bộ hệ thống phân cấp. Pattern này tạo một lớp chứa nhóm đối tượng của riêng nó. Lớp này cung cấp các cách để sửa đổi nhóm của cùng 1 object. Pattern này cho phép Client có thể viết code giống nhau để tương tác với composite object này, bất kể đó là một đối tượng riêng lẻ hay tập hợp các đối tượng.
Ví dụ: Một chương trình quản lý một hệ thống tập tin với cấu trúc như hình sau:
Base Component : là một interface hoặc abstract class quy định các method chung cần phải có cho tất cả các thành phần tham gia vào mẫu này.
Leaf : là lớp hiện thực (implements) các phương thức của Component. Nó là các object không có con.
Composite : lưu trữ tập hợp các Leaf và cài đặt các phương thức của Base Component. Composite cài đặt các phương thức được định nghĩa trong interface Component bằng cách ủy nhiệm cho các thành phần con xử lý.
Client: sử dụng Base Component để làm việc với các đối tượng trong Composite.
treating a group of objects in a similar manner to a single instance of that object
defining a family of algorithms, enscapsulating each one and making them interchangeable and selectable at runtime
xác định nhóm thuật toán, gói gọn từng thuật toán và làm cho chúng có thể hoán đổi cho nhau và có thể lựa chọn trong thời gian chạy
Lai tiếp tục kế thừa?
Phải làm sao khi t muốn máy bay của tôi… và khi tôi muốn máy bay của tôi ko còn bắn dc nữa? Khi tôi muốn trang bị cho máy bay dân dụng vu khi?
Vào sửa bắn bằng súng, thả bom??
Vào xóa đi?
-> làm như vậy mỗi lần có yêu cầu mới là phải sửa source code của các lớp trên.
-> làm sao để thay đổi chức năng của 1 đối tượng khi runtime?
xác định nhóm thuật toán, gói gọn từng thuật toán và làm cho chúng có thể hoán đổi cho nhau và có thể lựa chọn trong thời gian chạy
Strategy Pattern là một trong những Pattern thuộc nhóm hành vi (Behavior Pattern). Nó cho phép định nghĩa tập hợp các thuật toán, đóng gói từng thuật toán lại, và dễ dàng thay đổi linh hoạt các thuật toán bên trong object. Strategy cho phép thuật toán biến đổi độc lập khi người dùng sử dụng chúng.
Ý nghĩa thực sự của Strategy Pattern là giúp tách rời phần xử lý một chức năng cụ thể ra khỏi đối tượng. Sau đó tạo ra một tập hợp các hành vi, hành động thực hiện chức năng đó và lựa chọn hành vi nào mà chúng ta thấy đúng đắn nhất khi thực thi chương trình. Mẫu thiết kế này thường được sử dụng để thay thế cho sự kế thừa, khi muốn chấm dứt việc theo dõi và chỉnh sửa một chức năng qua nhiều lớp con.
Mẫu thiết kế này sử dụng tính năng tổng hợp thay vì kế thừa, cho phép tách tốt hơn giữa hành vi và lớp sử dụng hành vi. Điều này cho phép thay đổi hành vi mà không phá vỡ các lớp sử dụng nó và các lớp có thể chuyển đổi giữa các hành vi bằng cách thay đổi triển khai cụ thể được sử dụng mà không yêu cầu bất kỳ thay đổi mã đáng kể nào.
Ý nghĩa thực sự của Strategy Pattern là giúp tách rời phần xử lý một chức năng cụ thể ra khỏi đối tượng. Sau đó tạo ra một tập hợp các hành vi, hành động thực hiện chức năng đó và lựa chọn hành vi nào mà chúng ta thấy đúng đắn nhất khi thực thi chương trình. Mẫu thiết kế này thường được sử dụng để thay thế cho sự kế thừa, khi muốn chấm dứt việc theo dõi và chỉnh sửa một chức năng qua nhiều lớp con.