Strategy Pattern – Chiến lược với những thay đổi
NỘI DUNG BÀI VIẾT
Chào mừng đến với THẾ GIỚI VỀ SỰ CHUẨN MỰC TRONG VIỆC THIẾT KẾ VÀ XÂY DỰNG KIẾN TRÚC CHƯƠNG TRÌNH. Như đã nói ở bài trước, mình sẽ bắt đầu viết những đoạn code đơn giản để minh họa bài toán CON VỊT áp dụng các kỹ thuật trong lập trình hướng đối tượng bằng Java. Yêu cầu là xây dựng chương trình để hiện thực những con vịt lên trên màn hình.
TÍNH KẾ THỪA TRONG LẬP TRÌNH HƯỚNG ĐỐI TƯỢNG
Áp dụng tính kế thừa, ta có: Lớp Duck là lớp cơ sở cho những loài vịt cụ thể như MallarDuck, RedHeadDuck.
public abstract class Duck {
public void quack() {
// Quack..
}
public void swim() {
// Swim...
}
public abstract void display();
}
public class MallarDuck extends Duck {
@Override
public void display() {
// Display MallarDuck
}
}
public class RedHeadDuck extends Duck {
@Override
public void display() {
// Display RedHeadDuck
}
}
Ở đây, những con vịt đều có chung hành vi là bơi và kêu, riêng chỉ có hình dáng của chúng là khác nhau nên phương thức display sẽ là abstract, mấy con vịt sẽ tự định nghĩa phương thức đó để hiển thị đúng hình ảnh của chúng.
Sau này có yêu cầu những con vịt có thể bay được. Vậy việc duy nhất chúng ta làm là thêm phương thức fly vào trong lớp Duck, và những lớp con sẽ có thể bay.
public abstract class Duck {
public void quack() {
// Quack..
}
public void swim() {
// Swim...
}
public abstract void display();
public void fly() {
// Fly
}
}
MallarDuck, RedHeadDuck đều là những con vịt thật, chúng có thể kêu, bay và bơi. Bây giờ lại có thêm yêu cầu là support luôn con vịt cao su. Lớp RubberDuck cũng kế thừa từ Duck như sau:
public class RubberDuck extends Duck {
@Override
public void display() {
// Look like a rubber duck
}
}
Chạy chương trình:
public class Test {
public static void main(String[] args) {
Duck mallarDuck = new MallarDuck();
Duck rubberDuck = new RubberDuck();
mallarDuck.quack();
mallarDuck.fly();
rubberDuck.fly();
}
}
Output: Quackkkkkkk... I'm flying I'm flying
Oạch, rất ngạc nhiên khi vịt cao su mà cũng có thể bay. Vấn đề đang dần dần hiện ra, nhưng trong trường hợp này, chúng ta vẫn còn có thể chữa cháy bằng cách override lại phương thức fly của RubberDuck để nó không bay được nữa.
public class RubberDuck extends Duck {
@Override
public void display() {
System.out.println("Look like a RubberDuck");
}
@Override
public void fly() {
// Do nothing. It cannot fly
}
}
Khi chạy lại chương trình thì vịt cao su không thể bay được nữa.
Giờ lại có thêm yêu cầu mới, chúng ta cần support thêm lớp vịt gỗ. Vịt gỗ thì không kêu được, và cũng không bay được. Nghĩa là chúng ta sẽ phải override lại 2 hàm quack và fly để chúng không làm gì cả…
Bây giờ thì vấn đề của tính kế thừa quá rõ ràng. Các lớp dẫn xuất phải phụ thuộc quá chặt vào lớp cơ sở. Mỗi khi có sự thay đổi, chúng ta luôn phải xem xét lại ở mọi lớp để quyết định hành vi chính xác với mỗi lớp. Việc thay đổi ở nhiều lớp sẽ khiến cho những gì đã chắc chắn chạy đúng trước đây, bây giờ không có gì để đảm bảo nữa và việc test lại tất cả những thay đổi là điều không thể tránh khỏi. Với những hệ thống vận hành lâu năm, nếu cái core không được viết một cách cẩn thận, luôn có những ảnh hưởng rộng mỗi khi có sự thay đổi thì việc test lại toàn bộ những chức năng đã vận hành lâu nay sẽ là một ác mộng. Các bạn có thể tham khảo thêm bài viết “Why extends is evil” tại đây để có cái nhìn rõ hơn về những nhược điểm của Kế thừa. Tuy nhiên mình không nói là chúng ta nên loại tính kế thừa ra khi thiết kế hệ thống, tính kế thừa cũng có ưu điểm của nó và chỉ có 3 từ để nói đến là “Tái sử dụng”. Ở đây mình đang nói đến một hướng khác, đó là làm thế nào để có thể giữ lại được những ưu điểm của Kế thừa, đồng thời loại bỏ đi những phiền phức mà nó mang lại, đó là Sự thay đổi.
INTERFACE TRONG LẬP TRÌNH HƯỚNG ĐỐI TƯỢNG
implements chính là từ khóa chúng ta nghĩ đến khi không muốn nhắc đến từ extends (Mình đang dùng một số từ khóa trong Java. implements có nghĩa là một lớp sẽ định nghĩa lại một giao diện interface nào đó, và extends có nghĩa là 1 lớp muốn kế thừa lại một lớp nào đó). Với thiết kế hiện tại, chúng ta sẽ định nghĩa ra các interface như: Flyable, Quackable.
public interface Flyable {
public void fly();
}
public interface Quackable {
public void quack();
}
Khi này, các lớp vịt con có thể implement giao diện (hành vi) mà nó có. Chúng ta sẽ có một thiết kế giống hình sau:
Theo các bạn thì với Design như vậy so với ban đầu thì sao nhỉ? Có thể nói đó là một mớ hỗn độn, có quá nhiều mối quan hệ ở đây. Cũng giống như kế thừa, interface cũng mang lại không ít phiền phức. Hãy tưởng tượng có một “trang trại vịt” có tới 30 loài flyalbe (biết bay) thì chúng ta phải implement 30 phương thức fly. Có một sự duplication không hề nhẹ ở đây.
Có một nguyên lý trong thiết kế hướng đối tượng nói rằng: kiến trúc chương trình cần đóng cho những sự thay đổi và mở cho việc mở rộng. Đó là điều chúng ta cần. Cần có một thiết kế sao cho những thay đổi sẽ có ảnh hưởng ít nhất đến phần còn lại của chương trình. Bằng cách tách biệt những thành phần dễ bị thay đổi ra khỏi những phần khó bị thay đổi. (Nếu đã đọc qua loạt bài về NGUYÊN LÝ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG, bạn sẽ hiểu những gì mình đang viết).
TÁCH BIỆT NHỮNG PHẦN THAY ĐỔI
Cùng phân tích và tái cấu trúc lại “trang trại vịt” ở trên. fly và quack đang là những thành phần gây rắc rối. Mỗi loài vịt sẽ có tiếng kêu khác nhau (Quack!!!, Queck!!!, … (hoặc không kêu)) và tương tự cho việc biết bay hay không. Vì vậy cần phải tách biệt những thành phần này ra. Nguyên lý “The Open Closed Principle” sẽ giúp chúng ta có hướng đi đúng đắn trong trường hợp này.
Phân tích kỹ hơn chút nữa, nếu ta gom nhóm các tiếng kêu: Quack!!!, Queck!!!, … (không biết kêu). Chúng đều là các kiểu kêu. Mỗi loài vịt sẽ CÓ một kiểu kêu KHÁC NHAU. Vậy thiết kế mới cho Kiểu kêu như sau:
Và toàn bộ thiết kế mới sẽ như sau:
Việc thực thi thiết kế mới bằng code cũng khá đơn giản:
interface QuackBehavior {
public void quack();
}
class Quack implements QuackBehavior {
public void quack() {
System.out.println("Quack quack...");
}
}
class Queck implements QuackBehavior {
public void quack() {
System.out.println("Queck queck...");
}
}
class MuteQuack implements QuackBehavior {
public void quack() {
System.out.println("...");
}
}
interface FlyBehavior {
public void fly();
}
class FlyWithWings implements FlyBehavior {
public void fly() {
System.out.println("Fly fly..");
}
}
class FlyNoWay implements FlyBehavior {
public void fly() {
System.out.println("???");
}
}
public abstract class Duck {
protected QuackBehavior quackBehavior;
protected FlyBehavior flyBehavior;
public void quack() {
quackBehavior.quack();
}
public void swim() {
System.out.println("I'm swimming");
}
public void fly() {
flyBehavior.fly();
}
public abstract void display();
}
public class MallarDuck extends Duck {
public MallarDuck() {
quackBehavior = new Quack();
flyBehavior = new FlyWithWings();
}
@Override
public void display() {
System.out.println("Look like a MallarDuck");
}
}
public class RedHeadDuck extends Duck {
public RedHeadDuck() {
quackBehavior = new Queck();
flyBehavior = new FlyWithWings();
}
@Override
public void display() {
System.out.println("Look like a RedHeadDuck");
}
}
public class RubberDuck extends Duck {
public RubberDuck() {
quackBehavior = new Queck();
flyBehavior = new FlyNoWay();
}
@Override
public void display() {
System.out.println("Look like a RubberDuck");
}
}
public class WoodenDuck extends Duck {
public WoodenDuck() {
quackBehavior = new MuteQuack();
flyBehavior = new FlyNoWay();
}
@Override
public void display() {
System.out.println("Look like a WoodenDuck");
}
}
Ở đây, những con vịt sẽ có những kiểu kêu và kiểu bay khác nhau.
TIGHT COUPLING
Nhưng vẫn còn vấn đề cần giải quyết. Đó là tight coupling. Ở đây, những lớp vịt con lại phụ thuộc vào những đối tượng cụ thể khác như: Queck, FlyWithWings, FlyNoWay, … Để giải quyết nốt vụ Tight coupling. Sẽ tốt hơn nếu các đối tượng vịt sẽ nhận các hành vi cụ thể (bay, kêu) từ đối tượng khởi tạo chúng, hoặc bạn có thể giữ nguyên thiết kế bên trên, và thêm các setter để có thể thay đổi được hành vi của chúng lúc runtime (chẳng hạn như hôm nay vịt ốm thì không thể kêu được). Chúng ta cần sửa lại đoạn chương trình như sau:
public abstract class Duck {
protected QuackBehavior quackBehavior;
protected FlyBehavior flyBehavior;
public Duck(QuackBehavior inQuackBehavior, FlyBehavior inFlyBehavior) {
quackBehavior = inQuackBehavior;
flyBehavior = inFlyBehavior;
}
public void setQuackBehavior(QuackBehavior inQuackBehavior) {
quackBehavior = inQuackBehavior;
}
public void setFlyBehavior(FlyBehavior inFlyBehavior) {
flyBehavior = inFlyBehavior;
}
public void quack() {
quackBehavior.quack();
}
public void swim() {
System.out.println("I'm swimming");
}
public void fly() {
flyBehavior.fly();
}
public abstract void display();
}
Đây class diagram mới. Mối liên hệ composition đã được thay đổi bằng aggregation
Như vậy, việc khởi tạo 1 con MallarDuck bây giờ sẽ là:
Duck mallarDuck = new MallarDuck(new Quack(), new FlyWithWings());
Thậm chí chúng ta có thể thay đổi để nó kêu Queck queck bằng cách set lại tiếng kêu cho nó:
mallarDuck.setQuackBehavior(new Queck());
Và khi bạn muốn tiếng kêu Queck queck… sẽ thành Queck queck queck queck… thì việc đơn giản bạn cần làm là tìm lớp Queck và thay đổi cách xử lý của phương thức quack().
Hãy tưởng tượng với những thiết kế ban đầu, cần phải sửa bao nhiêu dòng code, bao nhiêu lớp để làm được những yêu rất đơn giản ở trên???
STRATEGY PATTERN
Chúng ta vừa hoàn tất thiết kế một chương trình đơn giản, bằng cách đi từ những ý tưởng này đến những ý tưởng khác để hoàn thiện chúng. Đó cũng có nghĩa là chúng ta cũng vừa hoàn tất 1 pattern đầu tiên: STRATEGY PATTERN. Mình nghĩ đây là pattern quan trọng nhất trong số các pattern. Nó giúp chúng ta xử lý vấn đề rất quan trọng trong việc lập trình hàng ngày đó là đối phó với những thay đổi. Bằng cách tách rời những thành phần dễ bị thay đổi (hoặc có nhiều cách thể hiện khác nhau) sẽ giúp cho chương trình ít bị biến động, đồng thời nó còn có nhiều tác dụng như một vài ví dụ mình đưa ở trên.
Vì đây là pattern khá quan trọng nên mình viết khá kỹ. Hi vọng các bạn sẽ nắm được tư tưởng này và áp dụng vào thực tế nếu có thể.
Nguồn: https://topdev.vn/blog/strategy-pattern-chien-luoc-voi-nhung-thay-doi/
Leave a Reply