So sánh factory và strategy pattern

Một ngày đẹp trời, sếp giao cho Tồ ngồi code vài ba con vịt – chẳng liên quan gì tới Strategy Pattern. Vịt thì cũng không nhiều loại lắm (vịt nhựa, vịt trời và vịt nhà). Làm dev cái qq gì lại đi code vài ba con vịt. Rõ điên, tồ cay lắm.

Nhưng thôi, “ăn cơm chúa múa tối ngày”, không code có khi nó lại đuổi cmn mình mất. Tồ lọ mọ ngồi thiết kế class, kế thừa (inheritance) này nọ. Dự án kết thúc, Tồ lại về nhà, ăn ngon, ngủ yên.

3 tháng sau, dự án mantain, dự án thêm 30 loại vịt. Tồ mở code lên maintain, code thế này sao mở rộng được. Hướng thiết kế vừa khó sửa chữa, vừa mất thời gian. Tồ tìm hiểu ngay về STRATEGY PATTERN, cố gắng thiết kế lại. Thành công, tồ hiểu thêm về strategy, tiện viết luôn bài này chia sẻ cùng mọi người.

1. Revisiting inheritance – một xíu về kế thừa.

Kế thừa (inheritance) là một bốn khái niệm quan trọng và cốt lõi của OOP (lập trình hướng đối tượng). Thông qua kế thừa, ta có thể tái sử dụng hoặc mở rộng hành vi (behavior), thuộc tính (properties) của lớp khác.

Khi kế thừa được sử dụng đúng đắn, code sẽ viết ít đi, các lớp (class) trở nên linh động (flexible). Việc một đối tượng có thể được kế thừa hay không chủ yếu tới từ IS-A (là cái gì).

Ví dụ: Mèo là động vật -> nó nên thuộc về lớp Animal. Mà giờ có khi lại thuộc cmn lớp Boss (vì nó như bố của đứa nuôi nó) =)).

Mặc dù kế thừa là khái niệm quan trọng, lạm dụng kế thừa lại không hề tốt. Nếu thiết kế các lớp kế thừa không tốt, code sẽ trở nên cực kì rối rắm. Các lớp kế thừa được thiết kế nhiều, nhưng các lớp con lại không thể sử dụng linh hoạt, đó là chưa nói tới các đoạn code phải lặp đi lặp lại nhiều lần.

2. Limit of inheritance – hạn chế của việc kế thừa.

Lấy ví dụ như sau: có 3 loại vịt (vịt trời, vịt nhà, vịt nhựa). Cả ba đều kế thừa lớp Vịt. Thiết kế lớp để kế thừa của ta ban đầu được thiết kế như sau:

Cả vịt nhưa, vịt trời và vịt nhà đều override lại method display() từ class cha. Tuy nhiên, chỉ có vịt trời và vịt nhà là thật sự biết kêu (quack). Chà, thiết kế còn tốt chán. Trông ra thì cũng chả có vấn đề gì to tát ở đây cả.

Tuy nhiên, một ngày đẹp trời, class cha Duck thêm vào method fly(), tất nhiên, trong họ nhà vịt thiếu gì con biết bay.

Đệch, vịt nhựa thì chắc chắn là không bay được, vì vậy phải override lại method này. Hơn nữa, còn phải chắc chắn rằng trong method override này không làm gì cả (do nothing). Sự thật là thế, con vịt nhựa mà bay được thì code sai tè le mất rồi. =))).

Không thể cứ class nào cùng overide method.

Nếu class cha có tới 15 method thì sao, chả nhẽ method nào cũng phải override lại?. Tới đây, hạn chế của kế thừa đã lộ rõ, các đoạn code kế thừa ở các lớp con lặp đi lặp lại. Đã không dùng lại phải thêm một đống code vào class. Thật sự tệ. Một thay đổi nhỏ ở lớp cha (super class) cũng kéo theo việc phải thay đổi code ở các lớp con kế thừa nó.

Hừm, để nghĩ xem. À, còn interface, sao không tách m* 2 cái fly và quack ra thành interface. Ngon.

3. Trying interface – thử dùng interface

Đm, học hành phỏng vấn đã lâu, nay đã đùng được interface, thật đáng công sức. Tách ra thế này.

Đầu tiên, 2 method fly() và quack() sẽ được tạo thành 2 interface riêng (flyable và quackable). Vịt trời và vịt nhà sẽ implement hai inteface này. Vịt nhựa thì do không bay cũng không kêu, nên nó không implements cái nào.

Chà, nghĩ chút, thiết kế này trông có vẻ ổn. Nếu lớp Duck sau này có thêm method fly(), thì chỉ cần tạo thêm interface Flyable nữa.

Lúc sử dụng thì con vịt nào cần cái nào thì nó implement cái đó.

Mà khoan. Trường hợp có 30 hay 40 lớp vịt thì như thế nào?

Đệch, cả 30, 40 cái class cùng implement quack và fly (hầu như mấy loài vịt khác con nào chả kêu, con nào chả bay). Lúc có thì, bất cứ thay đổi gì (cho dù là nhỏ) trong phương thức fly(), các class implement đều sửa. Maintenance code kiểu này thật sự là ác mộng (nightmare).

Thiết kế kiểu này xem ra không ổn -> mấy thằng dev sau nó vào đọc code mà đi mainte chắc nó chửi chết. Thôi đành xuất chiêu cuối, sử đụng strategy pattern.

4. Apply the principle – chốt hạ dùng Strategy pattern

Không thể để hậu nhân chửi bới được. Thiết kế chuẩn chỉnh lại theo strategy pattern thôi.

Để xem, vẫn có hai cái interface được tách ra (fly behavior, quack behavior).

Tuy nhiên, cái hay của strategy pattern là không phải lũ vịt sẽ implement trực tiếp các interface này. Ta sẽ viết các subclass implement. Cụ thể là:

Các class implements sẽ được tách ra theo behavior. Hai class implement fly behavior là flyWithWings (bay được) và flyNoWay (không bay được).

Quack thì có 2 class Quack (kêu được), Mute (không kêu được).

Khúc quan trọng đây rồi. Khi đã có các class cụ thể implements từ interface. Công việc còn lại là viết abtract class Duck cho tất cả lũ vịt extends.

Ngon lành cành đào, lúc khởi tạo class mới, ví dụ như vịt trời, chỉ cần new constructor theo behavior cho nó. Tất nhiên sẽ extends class Duck.

Đối với vịt nhựa, do vịt nhựa không kêu cũng không bay, nên instance của nó sẽ là Mute và FlyNoWay.

Cuối cùng, class Vịt chỉ đơn giản gọi các method được perform là quack và fly.

5. Kết luận

Strategy pattern rõ ràng là một thiết kế tốt. Tại sao lại thế?. Mặc dù vẫn sử dụng các interface. Tuy nhiên, với mô hình strategy, các interface sẽ được xác định rõ chức năng của nó (thông qua các behavior – class implements FlyNoWays, FlyWithWings, …). Trường hợp có sửa đổi hay thêm mới ta không cần sửa tới các interface, mỗi loài vịt đều có các class riêng đặc trưng khả năng của nó.

Trường hợp lũ vịt có thêm các method mới, đơn giản chỉ cần thêm các class behavior. Các class này độc lập, rất thuận tiện cho việc sửa đổi sau này.

Lúc maintain code, có thể dễ dàng bổ sung class implement các behaviors. Việc sửa đổi hay thêm mới class không hề làm ảnh hưởng tới các loài vịt khác.

Rõ ràng, stategy pattern đem tới một thiết kế không tồi tẹo nào. =))

Trên đây là hiểu biết cá nhân và ý kiến riêng của mình về strategy pattern. Rất mong nhận được phản hồi từ các bạn. Ngoài ra, các bạn có thể tham khảo thêm bài viết về JVM architecture.