Giới thiệ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 nơi thực hành đi trước lý thuyết, các nhà phát triển học được nhiều nhất khi họ làm việc trực tiếp với mã. Do đó, chúng ta sẽ tạm thời bỏ qua lý thuyết và khái niệm và xem xét một chương trình đơn giản.

Triển khai ứng dụng bán vé

• Chúng tôi muốn tổ chức một sự kiện nhỏ để quảng bá cho một nhà hát nhỏ.
  • Nội dung sự kiện: Rút thăm để chọn ra những khán giả được gửi thư mời xem biểu diễn miễn phí.
• Chúng ta cần phân biệt những khán giả trúng thưởng và những người không trúng thưởng.
  • Khán giả trúng thưởng sự kiện: Trao đổi thư mời để lấy vé.
  • Khán giả không trúng thưởng sự kiện: Mua vé bằng tiền.

Mã thực hành: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

Vấn đề là gì?

Robert Martin đã giải thích ba chức năng mà một mô-đun phần mềm (không phụ thuộc vào kích thước, bất kỳ yếu tố nào cấu thành chương trình, như lớp, gói hoặc thư viện) phải có.

• Hoạt động chính xác trong quá trình thực thi.
• Tồn tại để thay đổi.
  • Cần có thể thay đổi với một lượng công việc tối thiểu.
• Giao tiếp với những người đọc mã.
  • Các nhà phát triển cần dễ dàng đọc và hiểu.

Ứng dụng bán vé trước đây đáp ứng được hạn chế đầu tiên, đó là hoạt động chính xác, nhưng nó không đáp ứng được mục tiêu về khả năng thay đổi và giao tiếp.

Mã không theo dự kiến

Hãy xem xét lý do tại sao nó không đáp ứng được mục tiêu giao tiếp.

• Những gì phương thức enter() của lớp Theater thực hiện
  • Nhà hát kiểm tra xem có thư mời nào trong túi của khán giả hay không.
  • Nếu có thư mời trong túi, nhà hát yêu cầu người bán vé chuyển vé từ quầy vé sang túi của khán giả.
  • Nếu không có thư mời trong túi, nhà hát lấy tiền từ túi của khán giả, mua vé và đặt vé vào túi.
• Từ quan điểm của khán giả, nhà hát như một bên thứ ba tự do lục soát túi của họ, lấy tiền và đặt vé vào.
• Từ quan điểm của người bán vé, nhà hát như một bên thứ ba tự do thao túng giá trị của vé và tiền mặt trong quầy vé mà không có sự cho phép.
• Mã có thể hiểu được là mã không khác biệt nhiều so với kỳ vọng của chúng ta, nhưng nhà hát vượt quá kỳ vọng của chúng ta.
  • Khán giả cần tự lấy tiền từ túi và trả cho người bán vé để lấy vé.
  • Người bán vé cần tự lấy vé từ quầy vé và đưa cho khán giả, đồng thời nhận tiền từ khán giả và lưu giữ trong quầy vé.
• Ngoài ra, để hiểu được phương thức enter(), bạn cần ghi nhớ tất cả các chi tiết.
  • Audience có Bag.
  • Bag chứa tiền mặt và vé.
  • TiketSellet bán vé từ TicketOffice, TicketOffice lưu trữ tiền mặt và vé.

Mã dễ bị 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.
• Người bán vé chỉ bán vé tại quầy vé.

Vậy điều gì sẽ xảy ra trong các tình huống sau?

• Khán giả có thể không có túi.
• Khán giả có thể sử dụng thẻ tín dụng thay vì tiền mặt.
• Người bán vé có thể bán vé bên ngoài quầy 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 thực tế rằng khán giả mang theo túi và người bán vé chỉ bán vé tại quầy vé. Nếu bất kỳ chi tiết nào trong số này thay đổi, chúng ta cần sửa đổi cả lớp đó và các lớp phụ thuộc vào nó (ví dụ: Theater).

Đâ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 thay đổi. Tuy nhiên, thiết kế hướng đối tượng nhắm mục tiêu đến việc tạo ra một cộng đồng các đối tượng hợp tác với nhau, vì vậy thay vì loại bỏ sự phụ thuộc, chúng ta cần giữ lại sự phụ thuộc tối thiểucần thiết để triển khai chức năng của ứng dụng và loại bỏ sự phụ thuộc không cần thiết.

Kết hợp độ cao khi sự phụ thuộc giữa các đối tượng quá mứcKết hợp độ cao có nghĩa là khả năng thay đổi cùng nhau càng cao thì kết hợp độ cao giữa hai đối tượng càng cao. Do đó, mục tiêu của thiết kế là giảm kết hợp độ cao 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 biết khán giả có mang theo túi hay không và người bán vé bán vé tại quầy vé. Theater chỉ muốn khán giả vào nhà hát. Do đó, chúng ta cần tạo ra những thực thể tự trị để khán giả tự xử lý tiền mặt và thư mời trong túi của họ và người bán vé tự quản lý vé và phí bán hàng tại quầy vé.

Tăng cường tự trị

Một đối tượng thực hiện những tác vụ chặt chẽ liên quan đến nhau và ủy thác những tác vụ không liên quan đến các đối tượng khác được gọi là có độ kết hợp cao. Tạo ra các đối tượng tự trị xử lý dữ liệu của chính chúng sẽ giúp giảm kết hợp độ cao và tăng cường độ kết hợp.

Hướng thủ tục và hướng đối tượng

• Hướng thủ tục
  • Phương thức enter() của Theater là một quá trình, Audience, TicketSeller, Bag, TicketOffice là dữ liệu.
  • Phương pháp đặt quá trình và dữ liệu vào các mô-đun riêng biệt được gọi là lập trình hướng thủ tục.
  • Có rất nhiều mã trái 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 của họ).
  • 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ý tất cả)
• Hướng đối tượng
  • Phương pháp đặt dữ liệu và quá trình vào 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 chúng ta.
  • 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.
  • 
    

Mã thực hành: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

Chúng ta 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 do lớp Audience điều khiển, vì vậy chúng ta cần tạo ra lớp Bag thành một đối tượng tự trị.
• TicketOffice của lớp TicketSeller cũng bị TicketSeller quản lý tùy ý. Chúng ta cần tạo ra TicketOffice thành một đối tượng tự trị.
  • Tuy nhiên, sau khi thay đổi, TicketOffice đã tạo ra kết hợp độ cao bổ sung với Audience.
  • Thiết kế như vậy cần cân nhắc kỹ lưỡng các sự đánh đổi. Trong trường hợp này, để giảm kết hợp độ cao với Audience, chúng ta có thể đồng ý tạo ra TicketOffice thành một đối tượng thụ động ở một mức độ nào đó.

Mã thực hành: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

Đúng vậy, đó là lời nói dối!

• Trong thực tế, mặc dù là một thực thể thụ động, nhưng khi bước vào thế giới hướng đối tượng, mọi thứ đều trở thành một thực thể chủ động và tự trị.
• Nên sử dụng phép nhân hóa để coi các đối tượng thụ động như những đối tượng cười, nói chuyện và nổi giận.

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

Tại sao thiết kế lại cần thiết?

• Thiết kế là cách bạn bố trí mã.
• Một thiết kế tốt là một thiết kế có thể đáp ứng đầy đủ các chức năng được yêu cầu trong ngày hôm nay và có thể thích ứng với những thay đổi trong tương lai một cách suôn sẻ.

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.
• Các đối tượng là những thực thể tự trị tự chịu trách nhiệm về dữ liệu của chính chúng.
• 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 hợp lý.

Nguồn

• Đối tượng