Thiết kế phần mềm hướng đối tượng

Thiết kế phần mềm hướng đối tượng là một thực tiễn trừu tượng liên quan đến Kỹ thuật phần mềm hoặc Lập trình máy tính.

Bối cảnh

Trước khi phần mềm có thể được tạo ra, mục đích của nó phải được xác định. Thiết kế của một phần mềm thường được ghi lại trong một số loại tài liệu, nhưng tất cả các dự án phần mềm tầm thường nhất đều được hưởng lợi từ tài liệu thiết kế tốt, đặc biệt là khi có nhiều hơn một người tham gia vào việc tạo ra phần mềm. Hai lớp chính của tài liệu thiết kế đã được đưa vào thực tiễn rộng rãi:

Yêu cầu - Các yêu cầu xác định chức năng dự định của phần mềm cho người dùng và các hệ thống bên ngoài. Ví dụ, một yêu cầu của máy rút tiền tự động là người dùng đáp ứng các tiêu chí nhất định phải có thể rút tiền mặt.
Thông số kỹ thuật - Các thông số kỹ thuật nêu rõ các ràng buộc phải được đáp ứng bởi người dùng và các hệ thống bên ngoài trước khi phần mềm sẽ hoạt động đúng (như được xác định bởi các yêu cầu). Ví dụ, một phần của đặc điểm kỹ thuật của một số máy rút tiền tự động là người dùng phải mang theo thẻ ngân hàng và quẹt nó trong máy.Người dùng không tuân thủ phần này của thông số kỹ thuật sẽ không thể sử dụng nó.

Thực tiễn ban đầu về thiết kế phần mềm thường tập trung vào việc tạo ra các sản phẩm công việc nắm bắt các yêu cầu và thông số kỹ thuật mong muốn của phần mềm được đề xuất. Có nhiều cách tiếp cận khác nhau để thiết kế phần mềm, nhưng hầu hết các phần mềm sẽ không bao giờ đạt đến điểm mà tất cả các yêu cầu mong muốn được đáp ứng vì các yêu cầu sẽ thay đổi và phát triển ngay khi phần mềm được sử dụng. Vì vậy, thiết kế phần mềm chủ yếu liên quan đến việc thiết kế phần mềm dự kiến sẽ liên tục phát triển để đáp ứng một danh sách các yêu cầu luôn thay đổi. Việc hiểu được các quy trình thiết kế và phát triển phần mềm sẽ dễ dàng hơn rất nhiều khi khái niệm quan trọng nhưng tinh tế này được nắm bắt: thiết kế tốt là tạo ra phần mềm có thể phát triển và thích nghi trong một thời gian dài và số lượng phiên bản không xác định. không chủ yếu liên quan đến việc tạo ra một sản phẩm hoàn thiện nguyên sơ mà dự định sẽ không bị ảnh hưởng sau khi hoàn thành.

Phần mềm đầu tiên được thiết kế với mô hình thủ tục trong tâm trí. Mô hình thủ tục hình dung phần mềm chỉ đơn giản là một danh sách các hướng dẫn, thường được chứa trong nhiều tệp, sẽ được thực thi. Khi máy tính trở nên mạnh hơn, các chương trình đã phát triển đến một kích thước khiến cho cách tiếp cận này không thể quản lý được mà không áp dụng các thiết kế chỉ định các quy trình tổ chức phức tạp để theo dõi tất cả các tệp có chứa các hướng dẫn này. Kể từ đó, nhiều mô hình lập trình đã được hình dung, phổ biến nhất trong số đó là mô hình hướng đối tượng.

Hỗ trợ mô hình hướng đối tượng là quá trình thiết kế hướng đối tượng , hay còn gọi là OOD. OOD nhằm mục đích thiết kế phần mềm sao cho nó được chia thành các phần có thể quản lý được gọi là các lớp. Một lớp là một đơn vị mã chứa thông tin và định nghĩa các hành vi quản lý thông tin đó. Theo cách này, thông tin được quản lý bởi lớp chỉ có thể được thay đổi bởi thế giới bên ngoài theo những cách được xác định bởi lớp. Thế giới bên ngoài lớp học đó không cần phải hiểu chi tiết về cách thông tin đó phải được thao túng; đảm bảo rằng thông tin đầy đủ và nhất quán được quản lý trong chính lớp, đơn giản hóa rất nhiều nhiệm vụ làm việc với thông tin đó cho thế giới bên ngoài.

Khái niệm cơ bản: Lớp học & Kế thừa

Đơn vị cơ bản của một hệ thống hướng đối tượng là lớp. Một lớp là một tập hợp dữ liệu và các hành vi vận hành theo dữ liệu đó. Mỗi hành vi được nắm bắt trong một phương thức , đó là một hàm được liên kết với một lớp. Một lớp định nghĩa một loại đối tượng có thể tồn tại trong hệ thống.

Đó là hướng dẫn để xem xét một ví dụ. Một đối tượng có liên quan đến lớp của nó giống như cách một con chó cụ thể (hãy gọi anh ta là Rover) có liên quan đến lớp của tất cả các con chó. Theo cách tiếp cận hướng đối tượng, chúng tôi nói rằng Rover là một ví dụ của một con chó. Tương tự như vậy, chúng ta sẽ đề cập đến một đối tượng như là một thể hiện của một lớp cụ thể. Giống như Rover và Fido là hai trường hợp riêng biệt của chó, tại bất kỳ thời điểm nào cũng có thể có nhiều trường hợp của một lớp cụ thể tồn tại trong một hệ thống hướng đối tượng.

Nếu chúng ta đang thiết kế một hệ thống hướng đối tượng được thiết kế để đại diện cho chó, thì chúng ta sẽ sử dụng sự tương tự này để tạo ra một lớp được gọi là Dog. Mở lớp này chúng ta có thể xác định các biến như hairColor,hairLength, eyeColor, weight, height, vv Chúng tôi cũng có thể xác định hành vi mà tất cả những con chó chia sẻ như eat(), sleep(), bark(), và run(). Các hành vi chúng tôi xác định có thể sử dụng trạng thái được lưu trữ trong các biến để xác định cách thực hiện chính xác hành vi (ví dụ: một con chó lớn sẽ ăn nhiều hơn và sủa to hơn một con chó nhỏ). Khi chúng tôi khởi tạo hoặc tạo ra một con chó mới, chúng tôi sẽ khởi tạo nó với tất cả các thuộc tính của con chó cụ thể mà chúng tôi muốn đại diện. Vì vậy, mặc dù chúng tôi có hai trường hợp của Doglớp trong hệ thống của mìnhfidovà roverchúng sẽ thể hiện các hành vi giống nhau theo những cách khác nhau dựa trên trạng thái cá nhân của chúng.

Có ba nguyên tắc cơ bản để định nghĩa tất cả các phần mềm hướng đối tượng: đóng gói , kế thừa và đa hình . Chúng ta sẽ lần lượt thảo luận từng vấn đề, nhưng điều quan trọng là phải nhận ra rằng cả ba nguyên tắc phối hợp với nhau để xác định một lớp cụ thể.

Nguyên tắc đóng gói đề cập đến phạm vi và khả năng hiển thị của trạng thái trong một lớp. Điều quan trọng đối với mỗi lớp là xác định các hành vi có thể sử dụng được bởi thế giới bên ngoài theo cách mà trạng thái bên trong không được biết bên ngoài đối tượng, và cũng không cần biết trạng thái đó của các đối tượng của lớp để phục vụ mục đích bên trong hệ thống. Đóng gói đi đôi với nguyên tắc che giấu thông tin , trong đó nói rằng bất kỳ thông tin nào không cần phải biết bởi các tác nhân bên ngoài nên được ẩn khỏi tầm nhìn. Theo cách này, thế giới bên ngoài chỉ nhìn thấy những gì nó cần thấy để sử dụng đối tượng, đơn giản hóa việc sử dụng nó. Để sử dụng ví dụ trên, eat()phương pháp của Doglớp chúng tôicó thể sử dụng thuật toán rất phức tạp dựa trên trọng lượng, chiều cao và bất kỳ đặc điểm nào khác của con chó cụ thể đó để tính toán số lượng thức ăn nên ăn khi được gọi. Thế giới bên ngoài phải xem xét quá trình cụ thể được sử dụng bởi lớp với sự không quan tâm, nó chỉ đơn giản gọi eat()phương thức và, từ quan điểm bên ngoài đó, con chó ăn.

Kế thừa đề cập đến một mối quan hệ cụ thể mà hai hoặc nhiều lớp có thể chia sẻ. Sau khi chúng tôi xác định Doglớp củamình, chúng tôi có thể muốn thiết kế một số lớp đại diện cho các giống cụ thể: Ví dụ như Người chăn cừu Đức, Con trỏ và Chó tha mồi. Tất cả đều là những loại chó khác nhau. Như vậy, bất kỳ hành vi hoặc đặc điểm nào của Doglớp chung chung hơn của chúng ta cũng phải được chứa trong mỗi lớp này. Tuy nhiên, sẽ là một sự lãng phí công sức khủng khiếp khi sao chép tất cả các công việc chúng tôi đã thực hiện để xác định các đặc điểm và hành vi đó trên Doglớp. Hơn nữa, bất cứ khi nào chúng tôi cập nhật mã như vậy được chia sẻ bởi tất cả các con chó (chẳng hạn như khi sửa lỗi), chúng tôi sẽ phải áp dụng cùng một bản cập nhật cho tất cả các lớp có bản sao của cùng một mã. May mắn thay, vì các hệ thống hướng đối tượng cho phép kế thừa, chúng tôi không cần xác định cùng chức năng nhiều lần. Chúng tôi chỉ có thể nói rằng các giống khác nhau của chó kéo dài hoặc kế thừa từ các Doglớp học, và trường hợp của những lớp học tự động nhận được tất cả các đặc điểm và hành vi được xác định trên Dog.

Đa hình đề cập đến một tính năng cụ thể của các lớp xác định mối quan hệ thừa kế. Ở trên, chúng tôi đã nói rằng Con trỏ là một loại Chó cụ thể, và do đó Pointerlớp có thể mở rộng Doglớp. Khi mối quan hệ kiểu thừa kế này được xác định giữa hai lớp này, thế giới bên ngoài có thể coi bất kỳ con trỏ nào cụ thể là một con trỏ, hoặc nó cũng có thể coi nó nói chung đơn giản hơn là một con chó. Trong thực tế, khi làm việc với một trường hợp cụ thể, thế giới bên ngoài thậm chí không cần biết cách xử lý của nó với một con trỏ. Ví dụ, nếu Pointerlớp định nghĩa một hành vi bổ sung duy nhất cho con trỏ, chẳng hạn như point()khi xử lý một thể hiện của Pointerlớp thì hãy gọi con chó đặc biệt này pointylàwewe có thể gọipoint()phương thức và quan sát điểm Pointy. Tuy nhiên, nếu chúng ta chỉ quan tâm đến yêu cầu rằng chóp làm những điều mà tất cả những con chó có thể làm, chẳng hạn như eat()và sleep(), chúng tôi có thể quên hẳn rằng chóp là trong thực tế, một con trỏ và chỉ cần đối xử với anh cũng giống như mặc dù ông đã trực tiếp một thể hiện của Doglớp. Đa hình là khả năng của các đối tượng hành xử như thể chúng là các thể hiện của siêu lớp.

Mẫu thiết kế

Các mẫu thiết kế là giải pháp được công nhận cho các yêu cầu thiết kế chung. Chúng được khuyến khích nghiên cứu, vì chúng cung cấp các giải pháp sạch & hiệu quả có thể được sử dụng phổ biến ở nhiều nơi trong suốt thiết kế ứng dụng. Đối với người học, họ cung cấp các tùy chọn thiết kế tốt mà không cần phải đánh giá cẩn thận các nguyên tắc OO.

UML

Xem xét và giao tiếp thiết kế OO đòi hỏi một ngôn ngữ chung để được hiểu. Đối với OO, chủ nghĩa hình thức phổ biến nhất - bên cạnh chính mã - là UML.

UML định nghĩa các sơ đồ được công nhận rộng rãi như sơ đồ lớp, sơ đồ hoạt động, sơ đồ ca sử dụng và sơ đồ tuần tự có thể chính thức hóa và giao tiếp thiết kế một cách hiệu quả.

Nguyên tắc OO

Ngoài một vài lớp, có nhiều khả năng về cách đặt trách nhiệm hành vi & cấu trúc trong một thiết kế OO. Nguyên tắc OO giúp cung cấp các nguyên tắc & số liệu theo đó _good design_ có thể được chính thức hóa. Chúng vượt xa các Mẫu thiết kế (mặc dù hầu hết đã được phát minh trước đó); họ cung cấp sự biện minh & củng cố bằng cách xác định các mẫu thiết kế ban đầu.

Tài nguyên

Dưới đây là một số tài liệu học tập Thiết kế phần mềm hướng đối tượng và nhiều liên kết hơn

Các cấu trúc dữ liệu và thuật toán với các mẫu thiết kế hướng đối tượng trong Java 1
Một chỉ số của các công nghệ hướng đối tượng và tài liệu tham khảo trực tuyến. 2
Một trang khóa học Stanford với các liên kết hữu ích.3

Bài viết giới thiệu (tiếng Anh)

Tham khảo