DESIGN PATTERN là gì trong Thế giới này và trong giới Lập Trình cũng như ngành Công Nghệ Phần Mềm?

Khái quát về Design Pattern nói chung, cũng có khá nhiều bài viết khá đầy đủ và chi tiết rồi. Cụ thể nhất có thể nói đến bài NHẬP MÔN DESIGN PATTERN (PHONG CÁCH KIẾM HIỆP) của anh chủ blog Toidicodedao. Với 1 kẻ nhiễm kiếm hiệp và văn hóa Tàu như mình thì mình thấy bài viết này khá dễ hiểu. Bản thân mình cũng từ khi đọc bài viết này, đúng kiểu "từ ấy trong tôi bừng nắng hạ" luôn; các bạn cũng nên đọc ngay bài đó đi, rồi nếu hứng thú thì có thể quay lại đây đọc bài khái quát của mình theo 1 cách hình dung ví von mới!

Từ Quy luật của Trời Đất.

"Trời đất dung hoa, vạn vật sinh sôi, ...", thôi mình đùa đấy! Người quân tử có 3 điều SỢ, thứ nhất là sợ "ĐẠO". "Đạo" ở đây là chỉ những quy luật chung của Trời Đất. Bản thân mình thấy trong mọi khía cạnh của cuộc sống, mỗi khía cạnh đều sở hữu cho nó một bộ các quy luật chung, mà mọi sự vật, hiện tượng liên quan đến khía cạnh này đều tuân theo nó.

Triết Học.

"Triết Học là hệ thống những lý luận chung nhất của con người về thế giới, về vị trí và vai trò của con người trong thế giới ấy". Về cơ bản, Triết Học dạy chúng ta những thứ trừu tượng và có tính khái quát hết mức có thể (kiểu như Interface trong Java hay "lớp thuần ảo" trong C++ ấy) về cách nhìn nhận thế giới, suy nghĩ về một vấn đề và nhận thức một sự việc, ... . Tất cả các khía cạnh khác trong cuộc sống đều mở rộng, phát triển (extends) từ Triết Học mà ra. Còn với từng ngành Khoa Học riêng, từng lĩnh vực riêng, từng sự việc riêng, ..., ta phải căn cứ vào những quy luật Triết Học đó để hình thành cho mình cách nhận thức riêng. Có thể đủ, có thể chưa đủ, có thể chưa đúng; nhưng sẽ không bao giờ sai, nếu như ta căn cứ đúng!

Binh Pháp.

"Binh pháp là Hệ thống tri thức về những vấn đề lý luận quân sự nói chung và phương pháp tác chiến nói riêng". Có thể kể đến nổi tiếng và cội nguồn nhất chính là Binh Pháp Tôn Tử của Tôn Vũ; tiếp đến gần với chúng ta nhất chính là Binh Thư Yếu Lược của Hưng Đạo Vương Trần Quốc Tuấn, được phát triển (extends) từ Binh Pháp Tôn Tử để áp dụng vào điều kiện của Đại Việt. Binh Thư Yếu Lược thì mình chưa có dịp nghiên cứu nên mình không rõ lắm; còn Binh Pháp Tôn Tử, mình đã có dịp đọc rồi nên cũng có đôi chút cái nhìn về nó.

Binh Pháp Tôn Tử bao gồm 13 Thiên (chương/phần hoàn chỉnh) đề cập đến toàn bộ mọi vấn đề trong việc dùng binh và quân sự trong chiến tranh. 13 Thiên này cũng trình bày một cách rất khái quát và trừu tượng các vấn đề binh pháp, cũng kiểu khái quát và trừu tượng như Triết Học vậy. Còn việc triển khai mưu kế, chiến thuật tác chiến thế nào, thì không những tùy thuộc vào tư chất và khả năng lĩnh hội của từng tướng lĩnh, mà còn phải tùy thuộc vào khả nặng NGỘ (giác ngộ) của mỗi vị tướng.

Độc Cô Cửu Kiếm.

"Tổng quát thức, Phá Kiếm thức, Phá Đao thức, Phá Thương thức, Phá Sách thức, ...". Chắc hẳn ai đã từng xem phim hoặc đọc truyện kiếm hiệp Kim Dung thì cũng đều biết đến Độc Cô Cầu Bại với tuyệt kỹ Độc Cô Cửu Kiếm bá đạo nhất võ lâm. Các hậu bối có được bộ kiếm pháp này như Dương Quá, Phong Thanh Dương và Lệnh Hồ Xung cũng đều trở thành những đại cao thủ võ lâm, bá đạo nhất trong bộ truyện mà họ có mặt.

Độc Cô Cửu Kiếm bao gồm 9 thức, dựa vào quy luật trong Kinh Dịch, là căn cứ để phá giải mọi chiêu thức võ công trong thiên hạ. Độc Cô Cầu Bại chưa bao giờ phải rút kiếm về phòng thủ; Lệnh Hồ Xung nhìn ra được điểm yếu có thể phá giải trong chiêu thức của Quỳ Hoa Bảo Điển, nhưng vì Quỳ Hoa Bảo Điển tốc độ quá nhanh nên không thể phá giải được. Nhưng cảnh giới cao nhất của Độc Cô Cửu Kiếm không phải là thành thục tất cả 9 kiếm thức, mà là "Vô chiêu thắng hữu chiêu"; cũng tương tự quan điểm "lấy nhu thắng cương" trong Thái Cực Kiếm của Trương Tam Phong vậy. Do vậy, 9 thức này cũng mới chỉ là bước đầu trong việc luyện Độc Cô Cửu Kiếm; nó cũng thể hiện một cách rất khái quát việc phá giải chiêu thức của từng loại binh khí riêng, cũng kiểu khái quát và trừu tượng như Triết Học và Binh Pháp Tôn Tử vậy. Còn việc đạt đến cảnh giới quên hết chiêu thức mà "dĩ vô chiêu thắng hữu chiêu" thì còn tùy vào người học, và khả năng NGỘ của người đó.

Cho đến Design Pattern.

Ngành Công Nghệ Phần Mềm nói chung cũng như khía cạnh Lập Trình nói riêng, cũng có một bộ quy tắc như vậy, tương ứng với 13 Thiên của Binh Pháp Tôn Tử hay 9 Thức của Độc Cô Cửu Kiếm. Bộ quy tắc này được dân trong ngành gọi là DESIGN PATTERN.

Có thể hiểu Design Pattern là 1 bộ các mẫu thiết kế được đưa ra từ quá trình nghiên cứu và các kinh nghiệm lập trình thực tế; bộ các mẫu thiết kế này được áp dụng vào việc Lập Trình, sẽ làm cho code trở lên hệ thống hơn, dễ đọc, dễ hiểu, dễ bảo trì, đóng gói và mở rộng hơn. Lập trình viên nếu biết sử dụng đúng loại Design Pattern ở đúng trường hợp, đúng lúc đúng chỗ; với bản thân, sẽ tự nâng cao sở học để đạt đến cảnh giới cao hơn; với người khác, họ sẽ dễ hiểu và dễ sử dụng code của mình hơn; với chương trình mà mình sử dụng Design Pattern để viết ra, sẽ trong sáng, dễ bảo trì và phát triển hơn.

Tuy nhiên, nếu lạm dung Design Pattern quá, sẽ dễ dẫn đến Tẩu hỏa nhập ma. Nội lực chưa đủ mà đòi luyện một phát lên tiên thì sẽ tự chuốc họa vào thân. Thường thì chỉ những người học nghệ chưa thông thì mới hay thể hiện bản thân bằng cách cố nhồi nhét cả tá Design Pattern vào chương trình của mình. Việc sử dụng bừa bãi Design Pattern sẽ gây phản tác dụng, làm code dài dòng hơn rất nhiều, do đó càng khó để đọc hiểu, bảo trì hay mở rộng, ..., hại người hại mình.

Tuyệt kỹ Design Pattern.

Sau một thời gian bắt tay vào code thực tế, bản thân mình cũng học được một vài Design Pattern cơ bản và đã đem áp dụng trực tiếp vào các dự án mình thực hiện, như là Singleton Pattern, Builder Pattern, Adapter Pattern, Composite Pattern, Decorator Pattern, Strategy Pattern, Observer Pattern. Chừng đó vẫn còn khá ít ỏi; vì thứ nhất là mình chưa áp dụng được nhiều các Design Pattern trên, nên biết dùng thì có, nhưng thuần thục thì chắc là chưa; và thứ hai là còn nhiều Design Pattern quan trọng nữa mình chưa có điều kiện áp dụng thực tế nữa.

Về nguồn học liệu thì cơ bản mình tìm đọc thông qua Google thần thánh, tham khảo các quyển sách gối đầu giường về Design Pattern như Head First Design Patterns và Design patterns : elements of reusable object-oriented software, hay còn được dân trong ngành gọi vắn tắt là GoF (Gang of Four). Ngoài ra, mình cũng học hỏi từ bạn bè và sếp nữa. Bộ các Design Pattern được chia nhỏ ra làm 3 bộ nhỏ hơn ứng với từng chức năng riêng:

• Creational Design Pattern: Bao gồm các Design Pattern được sử dụng cho việc tạo ra đối tượng. Mình đã sử dụng đc vài Design Pattern trong bộ này như Singleton Pattern, Builder Pattern.
• Structure Design Pattern: Bao gồm các Design Pattern được sử dụng để thay đổi cấu trúc của đối tượng. Mình cũng đã sử dụng được vài Design Pattern trong bộ này như Adapter Pattern, Composite Pattern, Decorator Pattern.
• Behavioral Design Pattern: Bao gồm các Design Pattern được sử dụng trong việc điều khiển hành vi của các đối tượng. Mình mới sử dụng được mỗi Strategy Pattern trong bộ này thôi.

Học về Design Pattern là 1 chuyện, nhưng có biết sử dụng Design Pattern hay không thì lại là chuyện khác khó hơn nhiều; và có sử dụng được Design Pattern đúng lúc đúng chỗ hay không thì lại là một cảnh giới cao hơn nữa. Thế nên, học nhiều các Design Pattern cũng như việc thuộc làu binh thư, tinh thông binh pháp thôi; còn khi ra thực chiến, bày mưu tính kế, đấu pháp đấu trí thế nào thì còn tùy thuộc vào tài năng mưu trí và NGỘ của từng Lập trình viên.

Nói chung thì đọc nhiều cũng tốt, nhưng để hiểu rõ và thuần thục được một Design Pattern nào đó thì ta còn cần phải sử dụng nó vào thực tế nữa. Không những sử dụng một lần, mà còn phải sử dụng nhiều lần, nhưng phải sử dụng đúng lúc đúng chỗ, tránh lạm dụng. Đầu tiên, hãy chỉ nên nhớ quan điểm của các Design Pattern thôi. Đứng trước một yêu cầu, nếu có thể nhìn thấy việc áp dụng được ngay 1 Design Pattern nào đó mà có thể làm tăng hiệu quả công việc thì hãy áp dụng, còn không thì cứ buông tay mà code (đương nhiên phải có phân tích thiết kế hệ thống trước khi code nhé). Vừa code, ta lại vừa tranh thủ một chút thời gian nhìn lại những j mình đã code ra, để xem có những đoạn code nào cùng chức năng, có những đoạn code nào lặp lại, ... hay không. Nếu có, vậy có thể dùng Design Pattern nào trong tình huống này không, nếu sử dụng thì sẽ giải quyết được những vấn đề j, hay là ko giải quyết được j nhiều; nếu hiện tại ko giải quyết đc j nhiều thì sau này nếu mở rộng thêm chức năng này thì có thể gặp vấn đề j nữa ko? ... . Nhiều lắm các bạn ạ!

Sau đây, mình xin phép múa rìu qua mắt thợ, cụ thể 1 Design Pattern cơ bản nhất: Singleton.

Quan điểm:

Singleton được sử dụng khi ta muốn đối tượng được tạo ra là DUY NHẤT trong toàn hệ thống.

Đồ hình:

Bình thường, Constructor của 1 class phải public để có thể tạo ra đối tượng mới (ví dụ như Singleton singleton = new Singleton() ). Nhưng ta thấy ở UML trên, Constructor của một đối tượng Singleton lại là private, do đó ta không thể tạo ra nhiều đối tượng Singleton trong hệ thống được.

Ngoài ra, trong đối tượng Singleton có một thuộc tính instance là thể hiện của đối tượng Singleton này, và có 1 phương thức getter là getInstance() sẽ đảm bảo rằng ta chỉ có thể truy cập vào đối tượng Singleton duy nhất này thông qua hàm getter.

Code:

Bên trên là một đoạn code Java mô tả việc mình quy định class TaskRepo sẽ tạo ra duy nhất 1 đối tượng instance để tương tác với Database. Đối tượng này là độc nhất trong hệ thống và sẽ chỉ có thể truy cập thông qua một phương thức public duy nhất là getInstance(). Nếu trong hệ thống chưa có instance thì sẽ tạo ra một instance là thể hiện của TaskRepo, còn nếu trong hệ thống đã tồn tại instance rồi thì sẽ trả về instance đó ngay lập tức.

Kết.

Lời kết của anh chủ blog Toidicodedao trong bài viết về Nhập môn Design Pattern (mình đã trình bày ở đầu bài viết) đã là quá hay và đủ rồi; do đó mình cũng ko cần nói thêm j nhiều. Về cơ bản, mình cũng mới thực hành và cũng chưa thuần thục nhiều Design Pattern để đạt đến cảnh giới Senior Dev, nên đứng dưới góc độ của 1 coder, mình sẽ cố gắng áp dụng Design Pattern một cách đúng lúc đúng chỗ, càng nhiều càng tốt vào trong các dự án thực tế; đúng thì tốt mà sai thì cũng được, coi như có kinh nghiệm cho lần sau; quay lại đọc về nguyên lý của các Design Pattern mỗi khi cần hoặc rảnh.

Ngoài Design Pattern, trong ngành Công Nghệ Phần Mềm còn 1 khái niệm nữa, mà theo mình cảm nhận, thì khái niệm này còn cao siêu hơn Design Pattern. Người ta gọi đó là AntiPattern. Cái này thì nói về việc sử dụng Design Pattern không đúng dẫn đến kiểu "tránh vỏ dưa gặp vò dừa". Cảm thấy tu vi bản thân chưa đủ để tiếp thu những cái này nên mình cũng ko đọc tiếp. Chắc là phải thuần thục Design Pattern rồi thì mới có thể lĩnh hội được AntiPattern. Chắc phải đến khi nào làm được Technical Lead, hoặc có khi phải đến Software Architect trở lên thì mới đủ tu vi để lĩnh hội cái này ấy chứ.