Thiết kế hướng đối tượng.

Sau khi đọc cuốn Clean Architecture của tác giả Robert C. Martin, tôi chắt lọc ra những ý tưởng hay nhất và xin giới thiệu đến các bạn. Đầu tiên là quan điểm về hướng đối tượng.

Có nhiều ý kiến về vấn đề này, nhưng với một kiến trúc sư phần mềm thì câu trả lời cho câu hỏi Hướng đối tượng là gì sẽ rõ ràng như sau. Hướng đối tượng là khả năng có thể hoàn toàn kiểm soát được từng sự phụ thuộc mã nguồn trong hệ thống. Điều này cho phép kiến trúc sư phần mềm tạo ra được một kiến trúc cài cắm(plugin), mà ở đó các mô đun chứa logic trừu tượng (high-level policies) thì độc lập với các mô đun chứa logic cụ thể (low-level details). Các logic cụ thể được xếp đặt vào các mô đun cài cắm(plugin modules) để có thể được triển khai và phát triển một cách độc lập với các mô đun chứa logic trừu tượng.

Bạn có thể làm gì với khả năng trên của thiết kế hướng đối tượng. Một ứng dụng đó là bạn có thể sắp xếp lại sự phụ thuộc mã nguồn trong hệ thống của bạn để cho Database(DB) và User Interface(UI) phụ thuộc vào các Business Rule(BR) như hình minh hoạ dưới đây. Điều này có nghĩa là UI và DB có thể là những plugin cài cắm của BR. Tức là trong mã nguồn của BR sẽ không đề cập đến UI hoặc DB.

Kết quả là Business Rule, User Interface, và Database có thể được compile vào 3 component riêng biệt mà sự phụ thuộc của chúng cũng giống như sự phụ thuộc của các mã nguồn tương ứng. Component chứa Business Rule sẽ không phụ thuộc vào các component chứa UI và DB.

Tiếp đó thì Business Rule có thể được triển khai độc lập với UI và DB. Các thay đổi của UI và DB không gây ảnh hưởng đến BR. Các component này có thể được triển khai một cách riêng rẽ và độc lập với nhau. Nói cách khác, khi mã nguồn của một component thay đổi thì chỉ có component đó cần triển khai lại (Independent Deployability).

Nếu các mô đun trong hệ thống của bạn có thể triển khai một cách độc lập thì chúng có thể được phát triển độc lập bởi các team khác nhau(Independent Developability)

 

Add a Comment

Scroll Up