"Xin chào, Amigo! Tôi muốn nói với bạn về một lợi ích khác của OOP. Bạn thấy đấy, các chương trình giống như động vật hơn là tòa nhà. Chúng không được xây dựng, chúng lớn lên. Phát triển có nghĩa là thay đổi liên tục. Trong xây dựng, bạn có thể có một kế hoạch tốt và tuân theo kế hoạch đó đến chữ T. Nhưng trong phát triển phần mềm, điều đó không đúng."

Khá thường xuyên, bạn không thể làm điều gì đó theo cách bạn dự định và bạn phải làm lại chương trình của mình rất nhiều. Và thường xuyên hơn, yêu cầu của khách hàng thay đổi.

"Nhưng nếu khách hàng cung cấp một thông số kỹ thuật thực sự chi tiết thì sao?"

"Hãy xem điều gì xảy ra theo thời gian. Nếu một sản phẩm thành công, khách hàng sẽ muốn phát hành một phiên bản mới, rồi phiên bản khác, và phiên bản khác. Và, tất nhiên, bạn sẽ phải thực hiện một vài « thay đổi nhỏ » để sản phẩm hiện có. Vì vậy, phát triển phần mềm là một chuỗi dài các thay đổi. Chỉ có nhịp điệu là khác nhau. Một phiên bản mới có thể được phát hành mỗi tuần, mỗi tháng một lần hoặc sáu tháng một lần."

"Vậy chúng ta kết luận gì từ tất cả những điều này?"

"Cấu trúc bên trong của sản phẩm phải được duy trì theo cách cho phép thực hiện những thay đổi lớn (và nhỏ) với việc làm lại tối thiểu."

"Làm thế nào để bạn làm điều đó?"

"Chúng ta đã nói về cách một chương trình bao gồm các đối tượng tương tác với nhau. Hãy sử dụng các dấu chấm dày để biểu thị tất cả các đối tượng của chương trình trên bảng. Chúng ta sẽ vẽ các mũi tên từ mỗi đối tượng (dấu chấm) đến tất cả các đối tượng (dấu chấm) mà nó tương tác."

Bây giờ hãy kết hợp các đối tượng (dấu chấm) thành các nhóm. Các dấu chấm thuộc cùng một nhóm nếu chúng được kết nối với nhau nhiều hơn các dấu chấm khác. Nếu hầu hết các mũi tên của dấu chấm chỉ vào các dấu chấm trong nhóm của nó, thì chúng ta đã nhóm các đối tượng một cách chính xác. Các dấu chấm trong cùng một nhóm được cho là liên kết chặt chẽ, trong khi các dấu chấm trong các nhóm khác nhau được liên kết lỏng lẻo.

Đây được gọi là « nguyên tắc khớp nối lỏng lẻo ». Một chương trình được chia thành nhiều phần, thường là các lớp, logic của chúng được liên kết chặt chẽ với cấu trúc bên trong của chúng và liên kết yếu với các lớp/phần khác. Tương tác giữa các lớp thường được ngăn cách cao. Một lớp có thể gọi một lớp khác chỉ bằng cách sử dụng một tập con nhỏ các lớp của nó.

"Nguyên tắc 'phân công lao động' giống nhau, nhưng ở quy mô lớn hơn?"

"Chính xác. Điều này cho phép chúng tôi tổ chức lại một bộ phận, làm cho nó hiệu quả hơn và thuê nhiều người hơn nữa, và nếu chúng tôi không thay đổi các giao thức liên bộ phận, thì tất cả các thay đổi của chúng tôi sẽ là cục bộ. Không ai phải được đào tạo lại. Chúng tôi không' Không phải làm lại toàn bộ hệ thống. Mỗi bộ phận có thể tối ưu hóa công việc nội bộ của mình theo cách này nếu cơ chế tương tác giữa các bộ phận được lựa chọn tốt."

"Nếu chúng được chọn tốt. Còn nếu chúng không được chọn tốt thì sao?"

'Sau đó, bạn sẽ nhanh chóng hết « khoảng trống » để thực hiện các thay đổi và phải làm lại toàn bộ hệ thống. Điều đó xảy ra theo thời gian. Chúng tôi không thể dự đoán tương lai, nhưng chúng tôi có thể giảm thiểu số lần chúng tôi phải viết lại chương trình."

"Được rồi. Tôi thấy lợi ích của việc phân chia chương trình như vậy, nhưng OOP đi vào bức tranh như thế nào?"

"Khi chúng tôi chọn cách cấu trúc các bộ phận và cách chúng sẽ tương tác với nhau, chúng tôi áp dụng ' nguyên tắc trừu tượng '. Trong lập trình, tính trừu tượng được sử dụng để xác định cách tốt nhất để chia nhỏ chương trình và cách các bộ phận tương tác với nhau. Nguyên tắc này có thể cũng được áp dụng lặp đi lặp lại cho các phần cấu thành cho đến khi chúng tôi chia chương trình thành các lớp riêng lẻ."

"Và che giấu cấu trúc bên trong của các bộ phận này, đồng thời hạn chế nghiêm ngặt cách chúng tương tác với các bộ phận khác – đó là sự đóng gói , đúng không?"

"Chính xác. Đóng gói và trừu tượng hóa là nền tảng của OOP. Một chương trình tốt phải tuân thủ hai nguyên tắc này. Sau đó, chúng ta sẽ xem xét các nguyên tắc khác và hiểu được lợi thế của chúng."

"Thứ tốt. Tôi không thể chờ đợi!"