1. Lịch sử công ty
Tôi muốn kể cho bạn một câu chuyện chứng minh OOP giúp chống lại sự phức tạp của các hệ thống lớn như thế nào. Điều này là cần thiết để bạn hiểu mục đích của OOP .
Ngày xửa ngày xưa, có một công ty nhỏ cung cấp dịch vụ vận chuyển giữa các thiên hà...
Hãy gọi nó là Galaxy Rush. Nó sử dụng 5 người. Một người làm tài chính, người thứ hai làm việc trong nhà kho, người thứ ba giao hàng, người thứ tư phụ trách quảng cáo và người thứ năm quản lý toàn bộ doanh nghiệp.
Họ là những người lao động rất chăm chỉ và thành công trong mọi việc. Công ty đã có một danh tiếng tốt và kiếm được rất nhiều tiền. Nhưng mỗi năm đơn đặt hàng ngày càng nhiều nên ông chủ phải thuê thêm nhân viên. Thêm vài người cho kho hàng, vài người nữa cho việc giao hàng, một người nữa cho tài chính, và thêm một chuyên gia quảng cáo để mở rộng thị phần của công ty.
Và đó là khi các vấn đề bắt đầu. Có nhiều người hơn , và họ bắt đầu cản đường nhau.
Nhà tiếp thị tiêu hết tài khoản ngân hàng cho một chiến dịch quảng cáo mới, vì vậy không có tiền để mua các sản phẩm cần vận chuyển gấp.
Nhà kho có 10 ổ đĩa siêu tốc hoàn toàn mới được chuyển đến khách hàng mỗi tháng một lần. Một người chuyển phát nhanh đã bay đến và lấy đi một siêu ổ đĩa cho một khách hàng khác, khiến đơn đặt hàng thông thường cho 10 ổ đĩa siêu tốc bị chậm lại một tháng. Đơn giản là người chuyển phát nhanh đầu tiên không biết về đơn đặt hàng khác đã được thực hiện bởi người chuyển phát nhanh thứ hai.
Trợ lý giám đốc mới cử người chuyển phát nhanh đi trên một con tàu vũ trụ để mua thêm hàng hóa. Trong khi đó, những người khác chờ đợi một con tàu vũ trụ có sẵn xuất hiện. Có hàng tấn hàng cần giao gấp, nhưng người trợ lý này chỉ giám sát việc thu mua và đang cố gắng làm tốt công việc của mình. Nhân viên càng thực hiện tốt nhiệm vụ của mình thì anh ta càng can thiệp vào công việc của người khác.
Phân tích tình hình, ông chủ nhận ra rằng các tài nguyên quan trọng như tàu vũ trụ, tiền mặt và sản phẩm không được sử dụng một cách tối ưu. Thay vào đó, họ phải tuân theo quy tắc "bạn ngủ, bạn thua". Bất kỳ nhân viên nào cũng có thể lấy tài nguyên mà những người khác cần cho công việc của họ, do đó gây nguy hiểm cho các nhân viên khác và toàn bộ công ty.
Phải làm một cái gì đó, vì vậy ông chủ quyết định chia công ty nguyên khối thành một vài phòng ban. Ông thành lập bộ phận vận chuyển, bộ phận tiếp thị, bộ phận thu mua, bộ phận tài chính và bộ phận kiểm kê. Không còn ai có thể đơn giản đi tàu vũ trụ nữa. Trưởng bộ phận vận chuyển tiếp nhận mọi thông tin về việc giao hàng và cấp phát tàu cho nhân viên chuyển phát nhanh với đơn hàng có lợi nhất. Ngoài ra, nhà kho không cho phép người đưa thư lấy bất kỳ hàng hóa nào họ muốn. Thay vào đó, chọn sản phẩm từ kho đã trở thành một quy trình được kiểm soát. Bộ phận tài chính sẽ không tung tiền cho một chiến dịch tiếp thị nếu họ biết rằng sẽ sớm có người mua hàng. Mỗi bộ phận có một gương mặt đại chúng - người đứng đầu bộ phận.Cấu trúc bên trong của mỗi bộ phận là công việc kinh doanh của riêng nó. Nếu một nhân viên chuyển phát nhanh muốn lấy sản phẩm, cô ấy sẽ đến gặp người quản lý kho chứ không phải đến nhà kho. Nếu một đơn đặt hàng mới đến, nó sẽ được nhận bởi trưởng bộ phận vận chuyển ( public-facing representative) chứ không phải bởi người chuyển phát nhanh ( someone not authorized to interact with the other departments).
Nói cách khác, ông chủ hợp nhất các nguồn lực và các hành động liên quan đến nguồn lực thành các nhóm (phòng ban) , đồng thời cấm những người khác can thiệp vào cấu trúc nội bộ của các phòng ban. Các tương tác giữa các bộ phận phải thông qua một người cụ thể.
Theo quan điểm của OOP , đây không gì khác hơn là chia chương trình thành các đối tượng. Một chương trình nguyên khối gồm các phương thức và biến trở thành một chương trình bao gồm các đối tượng. Và các đối tượng có các biến và phương thức.
Vấn đề là bất kỳ nhân viên nào cũng có thể làm việc với bất kỳ tài nguyên nào và ra lệnh cho bất kỳ nhân viên nào khác, tất cả đều không có sự giám sát hoặc kiểm soát. Chúng tôi áp đặt một hạn chế nhỏ, nhưng đã đạt được nhiều trật tự hơn. Và chúng tôi cũng đã có thể kiểm soát mọi thứ tốt hơn.
Đây là sự phân chia và chinh phục ở dạng tinh khiết nhất của nó.
2. Cách tạo chương trình
Tôi muốn đề cập đến một điểm quan trọng hơn cho thấy một ưu điểm khác của OOP . Bạn có thấy rằng các chương trình giống động vật hơn là các tòa nhà không? Chúng không được xây dựng. Chúng đã lớn. Phát triển là sự thay đổi không ngừng. Trong xây dựng, bạn có thể có một kế hoạch tốt và tuân theo nó một cách chính xác. Đây không phải là trường hợp phát triển phần mềm.
Rất thường xuyên trong lập trình, bạn không thể làm điều gì đó theo cách bạn dự định ban đầu và phải làm lại rất nhiều. Yêu cầu của khách hàng thậm chí còn thay đổi thường xuyên hơn.
Nhưng nếu khách hàng cung cấp một thông số kỹ thuật rất chính xác thì sao? Điều đó làm cho mọi thứ thậm chí còn tồi tệ hơn. Hãy xem những gì xảy ra với sản phẩm theo thời gian.
Sự thành công của sản phẩm sẽ khiến khách hàng muốn tung ra 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, tất cả những gì bạn cần làm là thêm "những thay đổi nhỏ" vào sản phẩm hiện có. Vì vậy, bạn có thể thấy quá trình phát triển sản phẩm là một chuỗi các thay đổi liên tục. Chỉ có quy mô thời gian là khác nhau. Một phiên bản mới có thể được phát hành mỗi tuần một lần, mỗi tháng một lần hoặc sáu tháng một lần.
Và chúng ta có thể rút ra 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 cần phải được duy trì theo cách cho phép thực hiện những thay đổi quan trọng (và nhỏ) với việc làm lại tối thiểu.
đối tượng gắn kết
Nhưng thực hiện điều đó còn khó hơn quyết định thực hiện. Chúng ta đã nói rằng một chương trình bao gồm các đối tượng tương tác với nhau. Hãy vẽ tất cả các đối tượng trong chương trình của chúng ta lên bảng, biểu thị chúng bằng điểm. Và hãy vẽ các mũi tên từ mỗi đối tượng (điểm) đến tất cả các đối tượng (điểm) khác mà nó tương tác.
Bây giờ chúng ta sẽ kết hợp các đối tượng (điểm) thành các nhóm. Các điểm nên được nhóm lại nếu mối liên hệ giữa chúng mạnh hơn nhiều so với các điểm có điểm khác. Nếu hầu hết các mũi tên từ một điểm đi đến các điểm khác trong nhóm của chính nó, thì các nhóm đã được hình thành chính xác. Ta nói rằng các điểm trong một nhóm có tính gắn kết cao trong khi các điểm trong các nhóm khác nhau có tính gắn kết thấp hơn.
Nguyên tắc khớp nối lỏng lẻo
Có một "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 các lớp/bộ phận này được liên kết chặt chẽ với cấu trúc bên trong của chúng và được liên kết rất lỏng lẻo với các lớp/bộ phận khác. Tương tác giữa các lớp thường rất quy định. Một lớp có thể tham chiếu đến lớp thứ hai và chỉ sử dụng một tập con nhỏ các lớp của nó. Đây là nguyên tắc "chia công ty thành các bộ phận" mà chúng ta đã thấy trước đó, nhưng ở quy mô lớn hơn.
Kết quả là chúng ta có thể tổ chức lại một bộ phận khi cần thiết để tăng hiệu quả của bộ phận đó và thậm chí chúng ta có thể thuê nhiều người hơn cho bộ phận đó, và miễn là chúng ta không thay đổi giao thức tương tác với các bộ phận khác, thì tất cả những thay đổi được thực hiện sẽ giữ nguyên địa phương. Không ai phải học lại bất cứ điều gì. Bạn không phải làm lại toàn bộ hệ thống. Mỗi bộ phận có thể thực hiện loại tối ưu hóa nội bộ này nếu các cơ chế tương tác giữa các bộ phận được lựa chọn tốt.
Được chọn tốt. Nhưng nếu họ không được chọn tốt thì sao? Sau đó, khả năng thay đổi sẽ nhanh chóng cạn kiệt và bạn sẽ phải làm lại toàn bộ hệ thống. Điều này phải được thực hiện theo thời gian. Bạn không thể dự đoán tương lai, nhưng bạn có thể giữ số lần làm lại ở mức tối thiểu.
Nguyên lý trừu tượng
Chọn cách các bộ phận được cấu trúc và cách chúng tương tác với nhau là " nguyên tắc trừu tượng ". Trong lập trình, nó được sử dụng để xác định cách tốt nhất để chia chương trình thành các phần cấu thành và cách các phần đó tương tác với nhau. Chúng ta có thể áp dụng lại nguyên tắc, chia các phần kết quả thành nhiều phần, cho đến khi chúng ta chia chương trình thành các lớp riêng lẻ.
Ẩn cấu trúc bên trong của các bộ phận này và hạn chế nghiêm ngặt các tương tác với các bộ phận khác là sự đóng gói . Đó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 theo hai nguyên tắc này. Trong tương lai, chúng ta sẽ xem xét phần còn lại của các nguyên tắc và khám phá những lợi ích mà chúng mang lại.