Lời mở đầu
Robert L. Glass đã lập luận rằng thực hành đi trước lý thuyết. Đặc biệt, phát triển phần mềm là một lĩnh vực điển hình mà thực hành đi trước lý thuyết, và các nhà phát triển học hỏi được nhiều nhất khi họ “làm bẩn đôi tay” bằng cách viết mã cụ thể. Vì vậy, chúng ta hãy tạm gác lại lý thuyết và khái niệm, và cùng xem xét một chương trình đơn giản.
Triển khai ứng dụng bán vé
- Chúng ta đang lên kế hoạch cho một sự kiện nhỏ để quảng bá cho một nhà hát nhỏ.
- Nội dung sự kiện: Gửi thư mời xem miễn phí cho những khán giả được chọn ngẫu nhiên.
- Chúng ta cần phân biệt những khán giả trúng thưởng và những khán giả không trúng thưởng.
- Khán giả trúng thưởng: Đổi thư mời lấy vé.
- Khán giả không trúng thưởng: Mua vé bằng tiền mặt.
Vấn đề là gì?
Robert Martin đã giải thích về ba chức năng mà một mô-đun phần mềm (bất kể kích thước, chẳng hạn như lớp, gói hoặc thư viện, là bất kỳ thành phần nào cấu thành nên một chương trình) nên có.
- Hoạt động chính xác trong quá trình thực thi.
- Tồn tại để phục vụ cho việc thay đổi.
- Việc thay đổi phải được thực hiện một cách dễ dàng, thậm chí chỉ với những thao tác đơn giản.
- Giao tiếp với những người đọc mã.
- Các nhà phát triển phải dễ dàng đọc và hiểu mã.
Ứng dụng bán vé trước đây đáp ứng được ràng buộc đầu tiên là hoạt động chính xác, nhưng lại không đáp ứng được mục tiêu về tính dễ thay đổi và giao tiếp.
Mã không đúng như mong đợi
Hãy xem xét lý do tại sao mục tiêu giao tiếp không được đáp ứng.
- Phương thức enter() của lớp Theater làm gì?
- Nhà hát kiểm tra xem có thư mời trong túi của khán giả hay không.
- Nếu có thư mời trong túi, nhà hát sẽ yêu cầu nhân viên bán vé lấy vé từ phòng vé và đặt vào túi của khán giả.
- Nếu không có thư mời trong túi, nhà hát sẽ lấy tiền từ túi của khán giả để mua vé và đặt vé vào túi.
- Đối với khán giả, họ phải chứng kiến một bên thứ ba là nhà hát tự ý lục lọi túi của mình, lấy tiền và đặt vé vào.
- Đối với nhân viên bán vé, họ phải chứng kiến một bên thứ ba là nhà hát tự ý thao tác với vé và tiền mặt tại phòng vé mà không được phép.
- Mã dễ hiểu là mã mà hành vi của nó không quá khác biệt so với những gì chúng ta mong đợi, nhưng nhà hát trong ví dụ này lại không đáp ứng được điều đó.
- Khán giả nên tự lấy tiền từ túi của mình và trả cho nhân viên bán vé để nhận vé.
- Nhân viên bán vé nên tự lấy vé từ phòng vé và đưa cho khán giả, đồng thời nhận tiền từ khán giả và cất vào phòng vé.
- Ngoài ra, để hiểu phương thức enter(), người dùng cần nhớ tất cả các chi tiết nhỏ.
- Audience có Bag.
- Bag chứa tiền mặt và vé.
- TiketSellet bán vé tại TicketOffice, và TicketOffice chứa tiền mặt và vé.
Mã dễ bị ảnh hưởng bởi thay đổi
Phương thức enter() giả định hai điều kiện.
- Khán giả luôn mang theo túi để đựng tiền mặt và thư mời.
- Nhân viên bán vé chỉ bán vé tại phòng vé.
Vậy nếu có những tình huống sau thì sao?
- Khán giả có thể không có túi.
- Khán giả có thể thanh toán bằng thẻ tín dụng thay vì tiền mặt.
- Nhân viên bán vé có thể bán vé bên ngoài phòng vé.
Ví dụ, để đáp ứng yêu cầu đầu tiên, chúng ta cần loại bỏ đối tượng Bag của Audience và sửa đổi phương thức enter() của lớp Theater. Điều này là do lớp Theater phụ thuộc quá nhiều vào những chi tiết cụ thể như khán giả luôn mang theo túi và nhân viên bán vé chỉ bán vé tại phòng vé. Nếu bất kỳ chi tiết nào trong số này thay đổi, chúng ta sẽ phải sửa đổi cả lớp liên quan (ví dụ: Theater) và các lớp phụ thuộc vào nó.
Đây là vấn đề liên quan đến sự phụ thuộc giữa các đối tượng, và sự phụ thuộc ngụ ý tác động đến việc thay đổi. Tuy nhiên, mục tiêu của thiết kế hướng đối tượng là tạo ra một cộng đồng các đối tượng hợp tác và phụ thuộc lẫn nhau, vì vậy chúng ta không nên loại bỏ sự phụ thuộc một cách mù quáng, mà cần duy trì sự phụ thuộc tối thiểuvà loại bỏ các sự phụ thuộc không cần thiết.
Trường hợp sự phụ thuộc giữa các đối tượng quá mức được gọi làđộ liên kết cao, và độ liên kết giữa hai đối tượng càng cao thì khả năng chúng cần phải thay đổi cùng nhau càng lớn. Vì vậy, mục tiêu thiết kế là giảm độ liên kết giữa các đối tượng để tạo ra một thiết kế dễ thay đổi.
Cải thiện thiết kế
Theater không cần phải biết rằng khán giả có túi và nhân viên bán vé bán vé tại phòng vé. Theater chỉ muốn khán giả vào rạp. Vì vậy, chúng ta cần phải tạo ra các đối tượng tự chủ, trong đó khán giả tự quản lý tiền mặt và thư mời trong túi của mình, và nhân viên bán vé tự quản lý vé và giá vé tại phòng vé của mình.
Tăng cường tính tự chủ
Các đối tượng thực hiện các tác vụ chặt chẽ liên quan và ủy thác các tác vụ không liên quan cho các đối tượng khác được cho là có độ kết dính cao. Việc tạo ra các đối tượng tự chủ tự xử lý dữ liệu của mình sẽ giúp giảm độ liên kết và tăng độ kết dính.
Lập trình hướng thủ tục và hướng đối tượng
- Lập trình hướng thủ tục
- Phương thức enter() của Theater là một quy trình, và Audience, TicketSeller, Bag, TicketOffice là dữ liệu.
- Phương pháp đặt quy trình và dữ liệu trong các mô-đun riêng biệt được gọi là lập trình hướng thủ tục.
- Có nhiều mã trái ngược với trực giác của chúng ta. (ví dụ: khán giả tự quản lý tiền và thư mời.)
- Khó thu hẹp tác động của việc thay đổi dữ liệu.
- Quản lý trách nhiệm tập trung. (Theater quản lý mọi thứ)
- Lập trình hướng đối tượng
- Phương pháp đặt dữ liệu và quy trình trong cùng một mô-đun được gọi là lập trình hướng đối tượng.
- Chúng ta có thể viết mã phù hợp với trực giác của mình.
- Có thể thu hẹp hiệu quả tác động của việc thay đổi dữ liệu thông qua đóng gói.
- Mỗi đối tượng tự chịu trách nhiệm về bản thân.
Có thể cải thiện hơn nữa
- Lớp Bag của lớp Audience vẫn là một thực thể thụ động bị lớp Audience điều khiển, vì vậy chúng ta cần phải tạo ra lớp Bag thành một đối tượng tự chủ.
- TicketOffice của lớp TicketSeller cũng bị lớp TicketSeller điều khiển một cách tùy tiện. Chúng ta cần phải tạo ra TicketOffice thành một đối tượng tự chủ.
- Tuy nhiên, sau khi thay đổi, TicketOffice đã tăng độ liên kết với Audience.
- Thiết kế như vậy đòi hỏi phải cân nhắc kỹ lưỡng các điểm mạnh và yếu. Trong trường hợp này, chúng ta có thể thỏa thuận để tạo ra TicketOffice thành một đối tượng thụ động ở một mức độ nào đó để giảm độ liên kết với Audience.
Đúng rồi, đó là lời nói dối!
- Trong thực tế, ngay cả khi một thực thể được coi là thụ động, khi nó bước vào thế giới hướng đối tượng, nó sẽ trở thành một thực thể năng động và tự chủ.
- Nên sử dụng phép nhân hóa để xem xét các đối tượng thụ động như thể chúng có thể cười, nói chuyện và nổi giận.
Thiết kế hướng đối tượng
Tại sao cần thiết kế?
- Thiết kế là cách bố trí mã.
- Một thiết kế tốt là thiết kế đáp ứng đầy đủ các chức năng yêu cầu hiện tại và đồng thời có thể dễ dàng thích ứng với các thay đổi trong tương lai.
Thiết kế hướng đối tượng
- Mã có thể thay đổi là mã dễ hiểu.
- Mô hình hướng đối tượng giúp chúng ta viết mã theo cách chúng ta nhìn nhận thế giới.
- Đối tượng là một thực thể tự chủ chịu trách nhiệm về dữ liệu của chính nó.
- Một thiết kế hướng đối tượng tuyệt vời là một thiết kế quản lý sự phụ thuộc giữa các đối tượng hợp tác một cách thích hợp.
Nguồn tham khảo
- Object
Bình luận0