Kiến trúc tiến hóa và thiết kế nổi dần: Ngôn ngữ, tính biểu cảm và thiết kế, Phần 1 pps

Kiến trúc tiến hóa và thiết kế nổi dần: Ngôn ngữ, tính biểu cảm và thiết kế,

Phần 1

Tính biểu cảm trong mã lệnh của bạn tạo khả năng cho thiết kế nổi dần như thế

nào

Neal Ford, Kiến trúc phần mềm, ThoughtWorks

Tóm tắt: Khả năng xem và thu lượm các mẫu (pattern) diễn đạt đặc trưng là rất

quan trọng đối với thiết kế nổi dần. Và điều quan trọng sống còn đối với thiết kế là

tính biểu cảm của mã lệnh. Trong loạt bài viết gồm hai phần, Neal Ford sẽ bàn về

chỗ giao nhau giữa tính biểu cảm và mẫu diễn đạt đặc trưng, giải thích các khái

niệm này bằng cả mẫu diễn đạt đặc trưng lẫn mẫu thiết kế hình thức hóa. Ông viết

lại một số mẫu cổ điển của Gang of Four trong các ngôn ngữ động cho JVM để

cho bạn thấy rằng các ngôn ngữ biểu cảm hơn cho phép bạn thấy các phần tử thiết

kế bị che khuất bởi các ngôn ngữ mờ tối hơn như thế nào. (N.D: Gang of Four hay

GoF - Nhóm bốn người - là cuốn sách của bốn tác giả : Erich Gamma, Richard

Helm, Ralph Johnson và John Vlissides, được coi là nền tảng của các mẫu thiết kế

khác, được phân loại làm 3 nhóm: tạo lập (Creation), cấu trúc (Structure) và hành

vi (Behavior)).

Một trong những điều chính yếu cho phép thiết kế nổi dần là khả năng xem và thu

lượm các mẫu diễn đạt đặc trưng: các quy trình, các cấu trúc và các đặc ngữ,

chúng lặp lại một cách không tầm thường trong cơ sở mã lệnh của bạn. Tuy nhiên,

đôi khi các mẫu ấy bị ẩn đi. Trong phần đầu tiên của loạt bài viết Kiến trúc tiến

hóa và thiết kế nổi dần tôi đã mô tả các vấn đề che khuất tầm nhìn của các mẫu

này, chẳng hạn như vấn đề khái quát quá đáng. Việc xây dựng các ứng dụng nhiều

tầng có thể có hiệu lực tốt cho các dạng tách biệt mối quan tâm nhằm cho phép

khả năng mở rộng và phân đoạn, nhưng nó che giấu các mẫu diễn đạt đặc trưng

bởi vì bây giờ bạn phải tìm chúng xuyên qua nhiều tầng. Muốn trở thành một nhà

thiết kế và một kiến trúc sư giỏi thì bạn phải phát triển các "con mắt" để phân biệt

các mẫu đó.

Về loạt bài viết này

Loạt bài viết này nhằm cung cấp một phối cảnh tươi mới về các khái niệm thường

được thảo luận nhưng khó nắm bắt về kiến trúc và thiết kế phần mềm. Thông qua

các ví dụ cụ thể, Neal Ford mang đến cho bạn một nền tảng vững chắc cho cách

làm thực tế lanh lẹn của kiến trúc tiến hóa và thiết kế nổi dần. Bằng cách trì hoãn

các quyết định quan trọng về thiết kế và kiến trúc cho đến thời điểm chịu trách

nhiệm cuối cùng, bạn có thể ngăn ngừa được những phức tạp không cần thiết

không để chúng ngầm phá hoại các dự án phần mềm của bạn

Một điều khác ức chế việc thu lượm các mẫu là khả năng biểu cảm của chính ngôn

ngữ lập trình. Ví dụ, ta rất khó thu lượm các mẫu từ hợp ngữ (assembly language)

bởi vì các đặc tính của ngôn ngữ này đối chọi với tính biểu cảm. Ngay cả khi bạn

đã học được cách để đọc hợp ngữ như tiếng mẹ đẻ của bạn, thì các hạn chế khắc

nghiệt về cách viết mã lệnh che khuất khả năng để bạn có được một cái nhìn toàn

diện. Ví dụ: việc chuyển các biến vào và ra khỏi các thanh ghi thay vì có thể tạo ra

các biến và các phương thức có tên phù hợp có nghĩa là bạn tốn nhiều thời gian để

xử lý các gánh nặng công việc cố hữu trong ngôn ngữ này.

Việc so sánh ngôn ngữ Java™ với hợp ngữ là đòi hỏi quá đáng (stretch), nhưng

tính biểu cảm của các ngôn ngữ máy tính xếp dọc theo một dải phổ. Một số ngôn

ngữ có tính biểu cảm hơn các ngôn ngữ khác, làm cho việc xem các bản mẫu hiệu

quả trở nên dễ dàng hơn. Nhằm mục đích đó, bài viết này — là bài viết đầu tiên

của loạt bài viết gồm hai phần — sử dụng một ngôn ngữ động cho JVM (ngôn ngữ

Groovy) để giải thích các triển khai thay thế của một số mẫu Gang of Four.

Ôn lại về các mẫu thiết kế