Phân Tích Thiết Kế Hướng Đối Tượng (Ooad), Phân Tích Và Thiết Kế Hướng Đối Tượng Flashcards

Để tăng năng suất và đơn giản hóa công việc lập trình hướng đối tượng, bạn có thể sử dụng mẫu thiết kế hướng đối tượng (Design Pattern). Vậy tại sao nên sử dụng Design Pattern và nó có những mẫu phổ biến nào? Bài viết dưới đây sẽ giúp bạn phân tích chi tiết các vấn đề này.

Bạn đang xem: Thiết kế hướng đối tượng

1. Tại sao nên sử dụng mẫu thiết kế hướng đối tượng?

Design Pattern có thể sử dụng trong hầu hết các ngôn ngữ lập trình hướng đối tượng như: C#, PHP, Java hoặc Python. Các mẫu thiết kế này mang đến cho bạn rất nhiều lợi ích khi lập trình:

1.1. Mẫu thiết kế hướng đối tượng giúp cải thiện tốc độ phát triển phần mềm

Design Pattern cung cấp mô hình test và phát triển ứng dụng đã được kiểm nghiệm. Nhờ đó, thay vì mất thời gian để suy nghĩ giải pháp xử lý vấn đề, bạn có thể sử dụng Design Pattern để tiết kiệm thời gian lập trình.

Sử dụng mẫu thiết kế hướng đối tượng để cải thiện tốc độ phát triển phần mềm

1.2. Mẫu thiết kế hướng đối tượng có thể tái sử dụng

Bạn có thể sử dụng Design Pattern lặp đi lặp lại nhiều lần. Bên cạnh đó, mẫu thiết kế đối tượng cũng cho phép lập trình viên mở rộng, phát triển và bảo trì tùy theo yêu cầu của từng dự án.

1.3. Mẫu thiết kế hướng đối tượng giúp hạn chế tối đa các rủi ro

Design Pattern là một giải pháp đã được công nhận. Thế nên, khi sử dụng chúng, các rủi ro trong quá trình lập trình của bạn sẽ được hạn chế đến mức tối đa.

2. Phân loại các mẫu thiết kế đối tượng

Nếu bạn muốn sử dụng thành thạo Design Pattern, hãy tìm đọc cuốn sách Design Patterns – Elements of Reusable Object-Oriented Software. Được xuất bản vào năm 1994 bởi “bộ tứ” Richard Helm, John Vlissides, Erich Gamma và Ralph Johnson, cuốn sách này là nơi khai sinh cho thuật ngữ Design Pattern trong ngành lập trình.

Design Pattern hiện nay gồm 23 mẫu và được phân thành 3 nhóm chính:

2.1. Nhóm khởi tạo – Creational Pattern

Những mẫu thiết kế trong nhóm này mang đến giải pháp xây dựng các object và ẩn đi logic của việc tạo ra nó. Nhờ đó, các chương trình phần mềm sử dụng Creational Pattern sẽ trở nên linh hoạt hơn trong việc sử dụng object cho từng tình huống.

Mẫu thiết kế hướng đối tượng nhóm khởi tạo

5 mẫu thiết kế trong nhóm khởi tạo:

Factory Method: Đóng gói những lớp được sử dụng để tạo lập đối tượng trong ứng dụng.Abstract Factory: Phương thức chuẩn để xây dựng đối tượng thuộc các loại khác nhau.Builder: Một hàm tạo phức tạp hơn, cùng một khởi tạo có thể tạo nên nhiều định dạng.Prototype: Khởi tạo đối tượng bằng phương thức copy từ một đối tượng đã tồn tại khác.Singleton: Chỉ tạo một thể hiện của một lớp nhất định.

2.2. Nhóm cấu trúc – Structural Pattern

Những mẫu thiết kế thuộc nhóm cấu trúc có liên quan đến các thành phần của object và class. Nó là tập hợp các giải pháp để thiết lập, định nghĩa liên hệ giữa các đối tượng.

Mẫu thiết kế hướng đối tượng nhóm cấu trúc

7 mẫu thiết kế trong nhóm cấu trúc:

Adapter: Dịch một giao diện sang một giao diện trung gian khác.Bridge: Tách một giao diện khỏi các triển khai khác nhau.Composite: Cho phép một số đối tượng của một hệ thống phân cấp được kết hợp với nhau.Decorator: Thêm đặc điểm cho một đối tượng tại thời điểm thực thi.Facade: Cung cấp giao diện cho một số lớp.Flyweight: Chia sẻ các đối tượng giống nhau giữa các phiên bản để quản lý hiệu quả bộ nhớ.Proxy: Sử dụng một đối tượng đơn giản để truy cập một đối tượng phức tạp vì mục đích tốc độ và bảo mật.

2.3. Nhóm tương tác – Behavioral Pattern

Nhóm thiết kế này được sử dụng để thực hiện hành vi của đối tượng, thể hiện giao tiếp giữa các object.

Mẫu thiết kế hướng đối tượng nhóm tương tác

11 mẫu thiết kế trong nhóm tương tác:

Chain of Responsibility: Cho phép bất cứ ai có thể xử lý yêu cầu.Command: Tạo các yêu cầu phức tạp.Interpreter: Mô tả cách một ngôn ngữ có thể được xử lý.Iterator: Cung cấp cách duyệt nội dung của vùng chứa dữ liệu.Mediator: Cho phép giao tiếp giữa các lớp khác nhau.Memento: Cho phép khôi phục trạng thái của một đối tượng.Observer: Tạo ra cách để các cá thể được cập nhật hoặc gọi bởi một đối tượng khác.State: Cho phép thay đổi hành vi.Strategy: Cung cấp một số cách thực hiện điều gì đó.Template Method: Cung cấp bộ khung cho một thuật toán.Visitor: Thực thi mã cho mọi nội dung của một đối tượng.

Bài viết đã chia sẻ cho bạn các mẫu Design Pattern được sử dụng phổ biến nhất hiện nay và lý do tại sao nên sử dụng chúng. Nếu muốn biết chi tiết hơn về cách ứng dụng mẫu thiết kế hướng đối tượng vào các dự án thực tiễn, bạn hãy để lại bình luận bên dưới bài viết để được giải đáp nhé.

Nếu bạn quan tâm, hãy xem các vị trí đang tuyển dụng của Got It tại: bit.ly/gotit-hanoi và đọc thêm về quy trình tuyển dụng tại đây.

Xem thêm: Món ăn từ dế: công thức và cách chế biến dế mèn món ăn đặc sản nhậu ngon

Khi thực hiện các dự án phần mềm, ứng dụng tôi có thói quen chia đôi thời gian thực hiện, một nửa dành cho việc tìm hiểu nghiệp vụ, phân tích tính năng và thiết kế database, một nửa thời gian còn lại dành cho việc code. Trong thời đại mở của các nền tảng kỹ thuật chúng ta hoàn toàn có thể áp dụng những công nghệ tốt nhất cho hiệu suất ứng dụng của mình, lúc này việc ứng dụng hoạt động ổn định, đúng nghiệp vụ, dễ dàng mở rộng theo yêu cầu thay đổi của tình hình thực tế lại là điều quan trọng hơn.

Phân tích và thiết kế hướng đối tượng OOAD (Object Oriented Analysis and Design) và ngôn ngữ mô hình hóa UML (Unified Modeling Language) phổ biến và được đưa vào các trường đào tạo ngành CNTT tuy nhiên để áp dụng thực tế với sinh viên vẫn còn tương đối khó khăn. Trong bài này chúng ta sẽ tiếp cận bằng cách đơn giản những kiến thức về Phân tích và thiết kế hướng đối tượng và UML để cùng hiểu và áp dụng vào thực tế.

Khái niệm OOAD (Object Oriented Analysis and Design)

Phân tích và thiết kế hướng đối tượng là một kỹ thuật tiếp cận phổ biến dùng để phân tích, thiết kế một ứng dụng, hệ thống. Nó dựa trên bộ các nguyên tắc chung, đó là một tập các hướng dẫn để giúp chúng ta tránh khỏi một thiết kế xấu. 5 nguyên tắc SOLID trong thiết kế hướng đối tượng:

Một lớp chỉ nên có một lý do để thay đổi, tức là một lớp chỉ nên xử lý một chức năng đơn lẻ, duy nhất thôi. Nếu đặt nhiều chức năng vào trong một lớp sẽ dẫn đến sự phụ thuộc giữa các chức năng với nhau và mặc dù sau đó ta chỉ thay đổi ở một chức năng thì cũng phá vỡ các chức năng còn lại.Các lớp, module, chức năng nên dễ dàng Mở (Open) cho việc mở rộng (thêm chức năng mới) và Đóng (Close) cho việc thay đổi.Lớp dẫn xuất phải có khả năng thay thế được lớp cha của nó.Chương trình không nên buộc phải cài đặt một interface mà nó không sử dụng đến.Các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc thông qua lớp trừu tượng. Lớp trừu tượng không nên phụ thuộc vào chi tiết. Chi tiết nên phụ thuộc vào trừu tượng

Khái niệm UML

UML là ngôn ngữ mô hình hóa hợp nhất dùng để biểu diễn hệ thống. Nói một cách đơn giản là nó dùng để tạo ra các bản vẽ nhằm mô tả thiết kế hệ thống. Các bản vẽ này được sử dụng để các nhóm thiết kế trao đổi với nhau cũng như dùng để thi công hệ thống (phát triển), thuyết phục khách hàng, các nhà đầu tư v.v..

Tại sao lại là OOAD và UML?

OOAD cần các bản vẽ để mô tả hệ thống được thiết kế, còn UML là ngôn ngữ mô tả các bản vẽ nên cần nội dung thể hiện. Do vậy, chúng ta phân tích và thiết kế theo hướng đối tượng và sử dụng UML để biểu diễn các thiết kế đó nên chúng thường đi đôi với nhau.

OOAD sử dụng UML

UML sử dụng để vẽ cho nhiều lĩnh vực khác nhau như phần mềm, cơ khí, xây dựng v… trong phạm vi các bài viết này chúng ta chỉ nghiên cứu cách sử dụng UML cho phân tích và thiết kế hướng đối tượng trong ngành phần mềm. OOAD sử dụng UML bao gồm các thành phần sau:

View (góc nhìn)Diagram (bản vẽ)Notations (ký hiệu)Mechanisms (qui tắc, cơ chế)

Chúng ta sẽ tìm hiểu kỹ hơn các thành phần trên.

View (góc nhìn)

Mỗi góc nhìn như thầy bói xem voi, nó không thể hiện hết hệ thống nhưng thể hiện rõ hệ thống ở một khía cạnh. Chính vì thế trong xây dựng có bản vẽ kiến trúc (nhìn về mặt kiến trúc), bản vẽ kết cấu (nhìn về mặt kết cấu), bản vẽ thi công (nhìn về mặt thi công). Trong phần mềm cũng như vậy, OOAD sử dụng UML có các góc nhìn sau:

Trong đó,

Use Case View: cung cấp góc nhìn về các ca sử dụng giúp chúng ta hiểu hệ thống có gì? ai dùng và dùng nó như thế nào.Logical View: cung cấp góc nhìn về cấu trúc hệ thống, xem nó được tổ chức như thế nào. Bên trong nó có gì.Process View: cung cấp góc nhìn động về hệ thống, xem các thành phần trong hệ thống tương tác với nhau như thế nào.Component View: Cũng là một góc nhìn về cấu trúc giúp chúng ta hiểu cách phân bổ và sử dụng lại các thành phần trong hệ thống ra sao.Deployment View: cung cấp góc nhìn về triển khai hệ thống, nó cũng ảnh hưởng lớn đến kiến trúc hệ thống.

Tập hợp các góc nhìn này sẽ giúp chúng ta hiểu rõ hệ thống cần phân tích, thiết kế. Trong hình trên chúng ta thấy góc nhìn Use Case View nằm ở giữa và chi phối tất cả các góc nhìn còn lại. Chính vì thế chúng ta thường thấy các tài liệu nói về 4 view + 1 chứ không phải 5 view nhằm nhấn mạnh vai trò của Use Case View.

Diagram (Bản vẽ)

Diagram chúng ta có thể dịch là sơ đồ. Tuy nhiên ở đây chúng ta sử dụng từ bản vẽ cho dễ hình dung. Các bản vẽ được dùng để thể hiện các góc nhìn của hệ thống.

Trong đó,

Use Case Diagram: bản vẽ mô tả về ca sử dụng của hệ thống. Bản vẽ này sẽ giúp chúng ta biết được ai sử dụng hệ thống, hệ thống có những chức năng gì. Lập được bản vẽ này chúng ta sẽ hiểu được yêu cầu của hệ thống cần xây dựng.Class Diagram: bản vẽ này mô tả cấu trúc của hệ thống, tức hệ thống được cấu tạo từ những thành phần nào. Nó mô tả khía cạnh tĩnh của hệ thống.Object Diagram: Tương tự như Class Diagram nhưng nó mô tả đến đối tượng thay vì lớp (Class).Sequence Diagarm: là bản vẽ mô tả sự tương tác của các đối tượng trong hệ thống với nhau được mô tả tuần tự các bước tương tác theo thời gian.Collaboration Diagram: tương tự như sequence Diagram nhưng nhấn mạnh về sự tương tác thay vì tuần tự theo thời gian.State Diagram: bản vẽ mô tả sự thay đổi trạng thái của một đối tượng. Nó được dùng để theo dõi các đối tượng có trạng thái thay đổi nhiều trong hệ thống.Activity Diagram: bản vẽ mô tả các hoạt động của đối tượng, thường được sử dụng để hiểu về nghiệp vụ của hệ thống.Component Diagram: bản vẽ mô tả về việc bố trí các thành phần của hệ thống cũng như việc sử dụng các thành phần đó.Deployment Diagram: bản vẽ mô tả việc triển khai của hệ thống như việc kết nối, cài đặt, hiệu năng của hệ thống v.v…

Notations (các ký hiệu)

Notations là các ký hiệu để vẽ, nó như từ vựng trong ngôn ngữ tự nhiên. Chúng ta phải biết từ vựng thì mới ghép thành câu, thành bài được. Chúng ta sẽ tìm hiểu kỹ các notations trong từng bản vẽ sau này. Dưới đây là vài ví dụ về notation.

Hình trên là ví dụ về ký hiệu của Use Case, Class, Actor, ngoài ra còn rất nhiều các ký hiệu khác

Mechanisms (Rules)

Mechanisms là các qui tắc để lập nên bản vẽ, mỗi bản vẽ có qui tắc riêng và chúng ta phải nắm được để tạo nên các bản vẽ thiết kế đúng. Các qui tắc này chúng ta sẽ bàn kỹ trong các bài về các bản vẽ.

 

Tổng kết

Nguyên tắc phân tích, thiết kế một hệ thống phần mềm cũng không khác việc xây dựng một cái nhà trong xây dựng. Chúng ta nên nhớ cách tiếp cận này để dễ hiểu hơn trong việc phân tích và thiết kế hệ thống. Hãy giữ mọi thứ cho thật đơn giản để dễ hiểu và dễ áp dụng.

Trong thực tế, tùy vào độ phức tạp của dự án mà chúng ta có thể lược bỏ đi một số bản vẽ không cần thiết (bản vẽ cho các phần đơn giản, không phức tạp). Tôi thường vẽ Use Case Diagram, Class Diagram như hai bản bắt buộc và Activity Diagram cho một số tính năng phức tạp.

 

Theo dõi các bài viết tiếp theo: Phân tích thiết kế hệ thống hướng đối tượng (OOAD) và ngôn ngữ mô hình hóa (UML)