DEV Community: Cong Quy Nguyen

Sequence diagram - Drawing process

Cong Quy Nguyen — Sat, 22 Feb 2025 09:50:55 +0000

Tìm Hiểu Quy Trình Vẽ Sequence Diagram

Sequence Diagram (Biểu đồ tuần tự) là một công cụ mạnh mẽ trong UML để mô hình hóa quá trình tương tác giữa các đối tượng (objects) trong hệ thống theo trình tự thời gian. Nó giúp hiểu rõ luồng thực thi, sự trao đổi thông điệp (messages), và trách nhiệm của từng thành phần. Quy trình vẽ Sequence Diagram đòi hỏi sự chính xác về logic và thứ tự, đặc biệt hữu ích trong giai đoạn thiết kế và kiểm thử hệ thống.

Trong bài viết này, chúng ta sẽ khám phá chi tiết từng bước xây dựng Sequence Diagram, từ việc xác định các thành phần cơ bản đến áp dụng các kỹ thuật nâng cao để mô tả luồng phức tạp.

1. Các Bước Cơ Bản Trong Quy Trình Vẽ Sequence Diagram

1.1 Xác Định Các Đối Tượng Tham Gia (Participants)

Bước đầu tiên là xác định các đối tượng (objects) hoặc thành phần hệ thống tham gia vào quá trình tương tác. Mỗi đối tượng đại diện cho một thực thể trong hệ thống, chẳng hạn như lớp (class), actor, hoặc hệ thống con.

Các bước thực hiện:

Liệt kê tất cả các đối tượng liên quan đến use case cụ thể.
Sắp xếp đối tượng theo vai trò: Đặt actor (người dùng hoặc hệ thống bên ngoài) ở phía trái, các đối tượng nghiệp vụ ở giữa và phải.

Ví dụ minh họa:

Actor: Khách hàng.
Đối tượng: LoginPage, AuthenticatioController, AuthenticationService, AuthenticationRepository, Database.

Ký hiệu:

Đối tượng được biểu diễn bằng hình chữ nhật với tên đối tượng và lớp (ví dụ: user: Customer).
Lifeline (đường đời): Đường đứt nét dọc dưới mỗi đối tượng, thể hiện vòng đời của đối tượng trong quá trình tương tác.

1.2 Xác Định Thông Điệp (Messages) và Thứ Tự Thực Thi

Thông điệp là các hành động hoặc lời gọi phương thức giữa các đối tượng. Thứ tự của chúng được sắp xếp từ trên xuống dưới theo dòng thời gian.

Các loại thông điệp phổ biến:

Synchronous Message (Thông điệp đồng bộ):
- Được biểu diễn bằng mũi tên liền nét kèm đầu mũi tên đặc.
- Ví dụ: Gọi phương thức login() từ LoginPage đến AuthenticationController.
Asynchronous Message (Thông điệp bất đồng bộ):
- Biểu diễn bằng mũi tên liền nét với đầu mũi tên rỗng.
- Ví dụ: Gửi sự kiện onPaymentComplete từ hệ thống thanh toán đến OrderService.
Return Message (Phản hồi):
- Biểu diễn bằng mũi tên đứt nét.
- Ví dụ: AuthenticationService trả về kết quả success: boolean cho AuthenticationController.

Các bước thực hiện:

Liệt kê các thông điệp theo trình tự logic từ khi bắt đầu đến khi kết thúc quy trình.
Đảm bảo mỗi thông điệp được gán đúng đối tượng gửi và nhận.

Ví dụ minh họa:

Khách hàng → LoginPage: Nhập thông tin đăng nhập.
LoginPage → AuthenticationController: Kiểm tra và điều hướng thông tin đến AuthenticationService.
AuthenticationService → AuthenticationRepository: Thực hiện logic nghiệp vụ của chức năng login, sau đó tiến hành lưu các thông tin cần thiết thông qua việc gọi AuthenticationRepository.
AuthenticationRepository → Database: Truy vấn dữ liệu và lưu thông tin cần thiết.

1.3 Thêm Activation Bars (Thanh Kích Hoạt)

Activation Bar (thanh kích hoạt) thể hiện khoảng thời gian một đối tượng đang xử lý một tác vụ. Nó giúp làm rõ thời điểm phương thức được thực thi.

Các bước thực hiện:

Vẽ hình chữ nhật hẹp dọc theo lifeline của đối tượng khi nó đang xử lý thông điệp.
Kéo dài thanh kích hoạt cho đến khi phương thức hoàn tất.

Ví dụ:

Khi AuthenticationService xử lý authenticate(), một activation bar xuất hiện trên lifeline của nó.

2. Xử Lý Các Tình Huống Phức Tạp Với Combined Fragments

Combined Fragments là các khối logic giúp mô tả các luồng điều kiện, vòng lặp, hoặc luồng song song. Chúng được biểu diễn bằng hình chữ nhật với nhãn và điều kiện.

2.1 Fragment Điều Kiện (Alt/Opt)

Alt (Alternative): Dùng để mô tả các trường hợp "if-else".

alt [Điều kiện 1] => Thông điệp 1

else [Điều kiện 2] => Thông điệp 2

end

Opt (Optional): Mô tả trường hợp "if" không có else.

opt [Điều kiện] => Thông điệp

end

Ví dụ:

Alt: Nếu xác thực thành công, hiển thị trang chủ; ngược lại, hiển thị thông báo lỗi.

2.2 Fragment Lặp (Loop)

Loop thể hiện một nhóm thông điệp được lặp lại nhiều lần dựa trên điều kiện.

loop [5 lần] => Thông điệp

end

Ví dụ:

Lặp lại việc gửi OTP tối đa 3 lần nếu không nhận được phản hồi.

3. Kiểm Tra và Tối Ưu Sequence Diagram

Sau khi hoàn thành, cần kiểm tra kỹ lưỡng để đảm bảo tính chính xác:

Kiểm tra tính logic: Thứ tự thông điệp phải đúng với nghiệp vụ thực tế.
Kiểm tra phạm vi: Tránh thêm quá nhiều đối tượng làm biểu đồ phức tạp.
Tối ưu hóa: Nhóm các thông điệp liên quan vào combined fragments.

Tóm Tắt Quy Trình Vẽ Sequence Diagram

Các bước thực hiện:

Bước 1: Xác định chức năng cần thiết kế. Bạn dựa vào Use Case Diagram để xác định xem chức năng nào cần thiết kế.
Bước 2: Xác định các bước thực hiện theo nghiệp vụ.
Bước 3: Đối chiếu với Class Diagram để xác định lớp trong hệ thống tham gia vào nghiệp vụ.
Bước 4: Vẽ Sequence Diagarm
Bước 5: Cập nhật lại bản vẽ Class Diagram

Sequence Diagram không chỉ giúp thiết kế hệ thống mà còn là công cụ đắc lực trong việc debug và giao tiếp giữa các bên liên quan. Bằng cách tuân thủ quy trình này, bạn có thể tạo ra các biểu đồ mô tả rõ ràng và hiệu quả luồng nghiệp vụ của hệ thống.

Agile project managerment

Cong Quy Nguyen — Sat, 22 Feb 2025 09:48:31 +0000

Phương pháp Scrum trong phát triển phần mềm: Lý thuyết và ứng dụng thực tế

1. Giới thiệu về Scrum và sự cần thiết trong quản lý dự án phần mềm

Trong bất kỳ doanh nghiệp phần mềm nào, các nhà quản lý luôn cần theo dõi tiến độ và đánh giá khả năng hoàn thành dự án đúng thời hạn với ngân sách đề ra. Để đáp ứng yêu cầu này, các phương pháp phát triển phần mềm theo kế hoạch (Plan-driven approaches) đã ra đời. Tuy nhiên, khi Agile xuất hiện, nó đã đưa ra một cách tiếp cận linh hoạt hơn, trong đó Scrum nổi lên như một phương pháp phổ biến nhất để tổ chức và quản lý các dự án phát triển phần mềm.

Scrum không chỉ giúp tổ chức công việc trong các nhóm phát triển mà còn giúp tăng cường khả năng thích ứng với thay đổi và đảm bảo tính minh bạch trong dự án. Nhờ vậy, Scrum đã trở thành một phương pháp quản lý quan trọng trong các công ty phần mềm, đặc biệt là trong những môi trường có yêu cầu thay đổi liên tục.

2. Tổng quan về phương pháp Scrum

Scrum là một phương pháp phát triển phần mềm theo mô hình Agile, tập trung vào việc tổ chức công việc theo các chu kỳ phát triển ngắn gọi là Sprint (thường kéo dài từ 2 đến 4 tuần). Các thành viên trong nhóm Scrum làm việc cùng nhau để hoàn thành một phần chức năng của sản phẩm sau mỗi Sprint.

Các thành phần chính trong Scrum

Thuật ngữ	Định nghĩa
Nhóm phát triển (Development Team)	Một nhóm tự tổ chức, gồm tối đa 7 thành viên, chịu trách nhiệm phát triển phần mềm và các tài liệu liên quan.
Sản phẩm có thể giao hàng (Potentially Shippable Product Increment)	Một phần mềm hoàn chỉnh được tạo ra sau mỗi Sprint, có thể được triển khai ngay mà không cần chỉnh sửa.
Danh sách công việc tồn đọng (Product Backlog)	Danh sách các yêu cầu, tính năng hoặc nhiệm vụ mà nhóm Scrum cần thực hiện.
Chủ sở hữu sản phẩm (Product Owner)	Người chịu trách nhiệm xác định các tính năng, sắp xếp thứ tự ưu tiên và đảm bảo rằng sản phẩm đáp ứng nhu cầu kinh doanh.
ScrumMaster	Người hướng dẫn và đảm bảo Scrum được thực hiện đúng cách, đồng thời bảo vệ nhóm khỏi sự can thiệp từ bên ngoài.
Sprint	Một chu kỳ phát triển phần mềm kéo dài từ 2 đến 4 tuần.
Tốc độ phát triển (Velocity)	Số lượng công việc mà nhóm có thể hoàn thành trong một Sprint, giúp ước tính tiến độ của dự án.

3. Quy trình làm việc trong Scrum

3.1. Lập kế hoạch Sprint

Mỗi Sprint bắt đầu bằng một cuộc họp lập kế hoạch Sprint (Sprint Planning). Trong cuộc họp này:

Product Owner ưu tiên các mục trong Product Backlog.
Nhóm phát triển lựa chọn các mục có thể hoàn thành trong Sprint.
Sprint Backlog được tạo ra, chứa danh sách công việc của Sprint.

Ví dụ:
Một công ty phát triển ứng dụng thương mại điện tử muốn thêm tính năng "Thanh toán qua ví điện tử". Trong cuộc họp lập kế hoạch Sprint, Product Owner sẽ xác định các hạng mục công việc như:

Tích hợp API của nhà cung cấp dịch vụ ví điện tử.
Thiết kế giao diện người dùng cho trang thanh toán.
Viết unit test để kiểm tra chức năng.

3.2. Thực hiện Sprint

Trong thời gian Sprint diễn ra, nhóm phát triển làm việc để hoàn thành các nhiệm vụ đã cam kết. Mỗi ngày, nhóm tổ chức cuộc họp Scrum ngắn (Daily Scrum) để cập nhật tiến độ.

Ví dụ:
Nếu trong Sprint, nhóm phát triển gặp lỗi khi tích hợp API ví điện tử, họ sẽ báo cáo trong Daily Scrum và điều chỉnh công việc để giải quyết vấn đề kịp thời.

3.3. Kết thúc Sprint

Khi Sprint kết thúc, có hai cuộc họp quan trọng:

Sprint Review: Trình bày sản phẩm đã hoàn thành.
Sprint Retrospective: Đánh giá lại cách làm việc và đề xuất cải tiến cho Sprint tiếp theo.

Ví dụ:
Nếu sau Sprint, nhóm nhận thấy việc giao tiếp giữa các thành viên chưa hiệu quả, họ có thể đề xuất sử dụng công cụ như Slack hoặc Trello để cải thiện quy trình làm việc.

Dưới đây là ảnh minh họa vòng đời của một chu kỳ Scrum:

4. Lợi ích của Scrum và ứng dụng thực tế

Scrum mang lại nhiều lợi ích cho doanh nghiệp và nhóm phát triển, bao gồm:

Tăng cường khả năng thích ứng: Khi yêu cầu thay đổi, nhóm có thể điều chỉnh kế hoạch mà không làm ảnh hưởng đến toàn bộ dự án.
Cải thiện giao tiếp và minh bạch: Mọi thành viên đều biết rõ tiến độ công việc.
Tăng năng suất: Nhóm tập trung vào các nhiệm vụ ưu tiên, giúp nâng cao hiệu suất làm việc.
Khách hàng có thể thấy kết quả sớm: Do sản phẩm được phát triển theo từng phần nhỏ, khách hàng có thể kiểm tra và phản hồi ngay.

Ví dụ:
Công ty phát triển phần mềm quản lý bệnh viện đã sử dụng Scrum để phát triển từng module (quản lý bệnh nhân, quản lý thuốc, thanh toán). Nhờ Scrum, họ có thể đưa vào sử dụng từng module một cách nhanh chóng thay vì chờ hoàn thành toàn bộ hệ thống.

5. Những thách thức khi áp dụng Scrum

Mặc dù Scrum mang lại nhiều lợi ích, nó cũng có những thách thức:

Khó khăn khi áp dụng trong các nhóm lớn: Khi có nhiều nhóm làm việc cùng nhau, cần có sự điều phối tốt để tránh xung đột.
Phụ thuộc vào Product Owner: Nếu Product Owner không quản lý Product Backlog hiệu quả, dự án có thể bị chậm tiến độ.
Yêu cầu sự thay đổi văn hóa làm việc: Scrum đòi hỏi nhóm làm việc chủ động và tự tổ chức, điều này có thể gây khó khăn trong môi trường truyền thống.

Ví dụ:
Một công ty phần mềm tại Việt Nam áp dụng Scrum nhưng gặp khó khăn vì nhân viên đã quen với mô hình quản lý truyền thống. Để khắc phục, công ty đã tổ chức các buổi đào tạo về Scrum và dần dần thay đổi cách làm việc.

6. Scrum trong môi trường phát triển phần mềm phân tán

Ngày nay, nhiều công ty có nhóm phát triển làm việc từ nhiều quốc gia khác nhau. Để áp dụng Scrum hiệu quả trong môi trường này, có thể sử dụng:

Công cụ quản lý dự án như Jira, Trello để theo dõi tiến độ.
Họp Scrum qua video call (Zoom, Google Meet).
Chia múi giờ làm việc hợp lý để đảm bảo giao tiếp hiệu quả.

Ví dụ:
Một công ty phần mềm tại Mỹ có nhóm phát triển tại Việt Nam và Ấn Độ. Họ sử dụng Jira để quản lý công việc và tổ chức họp Scrum vào buổi tối (theo giờ Việt Nam) để cả ba nhóm có thể tham gia.

7. Kết luận

Scrum là một phương pháp linh hoạt giúp nâng cao hiệu suất làm việc trong phát triển phần mềm. Khi được áp dụng đúng cách, nó giúp tổ chức công việc hiệu quả, tăng tính minh bạch và đảm bảo sản phẩm đáp ứng yêu cầu của khách hàng. Tuy nhiên, việc triển khai Scrum cũng đi kèm với những thách thức, đòi hỏi sự thích nghi từ cả đội ngũ quản lý lẫn nhân viên.

Việc hiểu rõ và ứng dụng Scrum một cách linh hoạt sẽ giúp các công ty phần mềm tối ưu hóa quy trình làm việc và đạt được thành công bền vững. Do đó đây sẽ là nền tảng quan trọng để các nhóm phát triển phần mềm nâng cao hiệu suất, giảm thiểu lãng phí thời gian và tài nguyên, đồng thời tăng khả năng thích ứng với những thay đổi nhanh chóng của thị trường.

Ngoài lĩnh vực phần mềm, Scrum cũng được áp dụng rộng rãi trong các ngành khác như quản lý dự án, sản xuất, giáo dục và thậm chí cả y tế. Việc hiểu sâu về phương pháp này không chỉ giúp nhóm làm việc hiệu quả hơn mà còn góp phần xây dựng văn hóa làm việc linh hoạt, tập trung vào kết quả và cải tiến liên tục.

Với sự phát triển không ngừng của công nghệ và nhu cầu đổi mới sáng tạo, Scrum sẽ tiếp tục là một trong những phương pháp quản lý dự án quan trọng nhất, giúp các tổ chức cạnh tranh và phát triển bền vững trong thời đại số.

Quyết định kiến trúc phần mềm

Cong Quy Nguyen — Wed, 08 Jan 2025 16:00:41 +0000

Xin chào mọi người!

Hôm nay, chúng ta sẽ cùng nhau khám phá một chủ đề rất thú vị trong thiết kế phần mềm: Architectural Design Decisions. Đây là những quyết định cực kỳ quan trọng, ảnh hưởng đến cách một hệ thống phần mềm được xây dựng, vận hành và mở rộng. Hãy cùng mình tìm hiểu và làm rõ tại sao các quyết định này lại quan trọng nhé!

Architectural Design Decisions là gì?

Khi xây dựng phần mềm, nhóm phát triển thường phải đối mặt với rất nhiều câu hỏi, chẳng hạn như:

Sử dụng công nghệ nào?
Làm thế nào để xử lý hiệu quả khi có hàng triệu người dùng?
Làm sao để hệ thống dễ bảo trì, dễ nâng cấp trong tương lai?

Những câu hỏi này chính là nền tảng của Architectural Design Decisions – các quyết định kiến trúc, giúp định hình hệ thống phần mềm từ những bước đầu tiên.

Tại sao cần phải đưa ra quyết định kiến trúc?

Nếu ví một hệ thống phần mềm như một ngôi nhà, thì các quyết định kiến trúc chính là việc chọn nền móng, thiết kế cột trụ, và xác định cách xây dựng. Một quyết định sai lầm có thể dẫn đến việc phải "đập đi xây lại", tốn kém cả về thời gian lẫn chi phí.

Một số lý do cụ thể:

Đảm bảo đáp ứng yêu cầu của dự án:
- Hệ thống phải đáp ứng được cả yêu cầu chức năng (functional) và phi chức năng (non-functional).
Tối ưu tài nguyên:
- Các quyết định kiến trúc cần cân đối giữa chi phí, hiệu năng và khả năng mở rộng.
Giảm thiểu rủi ro:
- Một hệ thống được thiết kế tốt sẽ ít bị gián đoạn khi gặp sự cố.

Các yếu tố cần cân nhắc khi đưa ra quyết định kiến trúc

1. Yêu cầu của hệ thống (System Requirements):

Hiểu rõ mục tiêu và yêu cầu của dự án là bước đầu tiên. Ví dụ:

Hệ thống cần xử lý bao nhiêu yêu cầu mỗi giây?
Dữ liệu có cần bảo mật cao không?

2. Ràng buộc về tài nguyên (Constraints):

Ngân sách: Có bao nhiêu tiền để đầu tư?
Thời gian: Deadline có sát không?
Đội ngũ: Team có đủ kỹ năng và kinh nghiệm để thực hiện không?

3. Xu hướng công nghệ (Technology Trends):

Chọn công nghệ phổ biến và được hỗ trợ lâu dài sẽ giúp giảm rủi ro.

Những quyết định kiến trúc thường gặp

Monolithic vs Microservices:

Monolithic Architecture là một kiểu kiến trúc mà mọi chức năng của hệ thống được gom lại trong một ứng dụng duy nhất. Kiến trúc này dễ triển khai và có tính đơn giản cao, vì tất cả các thành phần của hệ thống đều nằm trong cùng một mã nguồn và cấu hình. Tuy nhiên, khi hệ thống phát triển lớn mạnh, việc mở rộng và bảo trì trở nên khó khăn, vì mọi thay đổi đều có thể ảnh hưởng đến toàn bộ ứng dụng, khiến việc duy trì và nâng cấp trở nên phức tạp.

Ngược lại, Microservices Architecture chia hệ thống thành nhiều dịch vụ nhỏ, mỗi dịch vụ đảm nhận một nhiệm vụ cụ thể và có thể phát triển độc lập. Kiến trúc này dễ mở rộng và bảo trì, vì mỗi dịch vụ có thể được thay đổi, mở rộng mà không ảnh hưởng đến các dịch vụ khác. Tuy nhiên, việc triển khai Microservices đòi hỏi kỹ năng cao và tài nguyên tốt hơn, vì cần quản lý nhiều dịch vụ và đảm bảo chúng hoạt động phối hợp một cách hiệu quả.

SQL hay NoSQL?

SQL: Dành cho dữ liệu có cấu trúc rõ ràng và quan hệ chặt chẽ (VD: MySQL, PostgreSQL).
NoSQL: Dành cho dữ liệu phi cấu trúc hoặc khi cần tốc độ xử lý cao (VD: MongoDB, Redis, Neo4j).

Tổng kết

Các quyết định kiến trúc đóng vai trò quan trọng trong việc đảm bảo hệ thống phần mềm vận hành hiệu quả, linh hoạt và bền vững. Mỗi quyết định đều phải dựa trên sự cân nhắc kỹ lưỡng về yêu cầu dự án, tài nguyên, và xu hướng công nghệ.

Hy vọng qua bài viết này, các bạn đã hiểu rõ hơn về tầm quan trọng của Architectural Design Decisions. Nếu có thắc mắc hay ý kiến, đừng ngần ngại để lại bình luận nhé!

Cảm ơn các bạn đã theo dõi bài viết, chúc các bạn học tập thật tốt! 😊

Interface và Abstract class

Cong Quy Nguyen — Sun, 05 Jan 2025 11:17:01 +0000

Xin chào mọi người! Hôm nay, ở bài học hôm nay, chúng ta sẽ nói về một chủ đề rất thú vị trong lập trình hướng đối tượng. Đó là sự khác biệt giữa Interface và Abstract Class. Khi nào chúng ta nên dùng Interface? Khi nào thì Abstract Class mới là lựa chọn phù hợp? Và cùng tìm hiểu một vài ví dụ nhỏ minh họa của chúng! Hãy cùng mình tìm hiểu nhé!

Đây là hai khái niệm khá "trừu tượng", nhưng nếu hiểu rõ thì bạn sẽ dễ dàng áp dụng vào thiết kế phần mềm. Giờ thì bắt đầu thôi!

Do bài học này chủ yếu là ôn lại để củng cố kiến thức cho các bạn trước khi bước vào UML, nên mình sẽ cố gắng trình bày một cách cô đọng nhất những kiến thức chính của phần này để giúp các bạn có thể dễ nhớ và áp dụng.

1. Định nghĩa

Interface

Interface trong Java giống như một "hợp đồng" mà các lớp phải thực hiện. Nó chỉ chứa các phương thức trừu tượng (abstract methods) và hằng số (constants). Khi triển khai "hợp đồng" này thì các đối tượng triển khai bắt buộc phải triển khai các method đã được quy định. Từ Java 8 trở đi, Interface đã "nâng cấp" khi có thêm phương thức mặc định (default methods) và phương thức tĩnh (static methods). Thật tiện lợi phải không nào?

Abstract Class

Abstract Class thì hơi khác một chút. Nó giống như một "bản thiết kế" nhưng có thể cung cấp cả các chi tiết cụ thể (phương thức thông thường) và các phần trừu tượng (phương thức abstract). "Bản thiết kế" này quy định điểm chung về thuộc tính hay method của các đối tượng kế thừa nó, điểm đặc biệt là bạn không thể khởi tạo trực tiếp một Abstract Class.

2. Sự khác biệt chính

Chúng ta cùng so sánh để thấy rõ hơn nhé:

Đặc điểm	Interface	Abstract Class
Từ khóa sử dụng	`interface`	`abstract class`
Kế thừa	Một lớp có thể triển khai nhiều interface	Một lớp chỉ có thể kế thừa một abstract class
Phương thức	Chỉ chứa phương thức trừu tượng (trước Java 8)	Có cả phương thức trừu tượng và thông thường
Constructor	Không có	Có
Biến	Chỉ chứa hằng số (public static final)	Có thể chứa biến với mọi mức độ truy cập
Tốc độ thực thi	Nhanh hơn (được tối ưu hóa hơn)	Chậm hơn
Thích hợp cho	Các hành vi chung giữa các lớp không liên quan	Các lớp có mối quan hệ kế thừa

Đơn giản vậy thôi, nhưng tuỳ vào trường hợp, bạn sẽ chọn cái nào hợp lý nhất nhé!

3. Khi nào nên sử dụng?

Interface

Bạn nên dùng Interface khi:

Muốn định nghĩa một tập hợp hành vi mà nhiều lớp (không liên quan) có thể thực hiện. Ví dụ: Bay, bơi, chạy.
Cần hỗ trợ đa kế thừa, vì Java không cho phép đa kế thừa với Abstract Class.

Abstract Class

Abstract Class thì phù hợp nếu:

Bạn muốn chia sẻ code giữa các lớp "cùng họ hàng" (liên quan trực tiếp).
Cần định nghĩa các thuộc tính hoặc phương thức có thể tái sử dụng trong lớp con. Ví dụ: Các loài động vật đều "ăn" và "ngủ".

4. Ví dụ minh họa

Interface

Hãy tưởng tượng bạn đang xây dựng một chương trình về các loài động vật:

public interface Animal {
    void eat();
    void sleep();
}

public class Dog implements Animal {
    @Override
    public void eat() {
        System.out.println("Dog eats bones");
    }

    @Override
    public void sleep() {
        System.out.println("Dog sleeps in a kennel");
    }
}

Như bạn thấy, Dog chỉ cần thực hiện những hành vi được định nghĩa trong Interface.

Abstract Class

Nếu các loài động vật có vài điểm chung nhưng mỗi loài lại "ăn" theo cách riêng thì sao?

public abstract class Animal {
    abstract void eat();

    void sleep() {
        System.out.println("This animal sleeps");
    }
}

public class Dog extends Animal {
    @Override
    public void eat() {
        System.out.println("Dog eats bones");
    }
}

Ở đây, Dog không cần tự định nghĩa hành vi "ngủ" vì nó đã có sẵn từ Abstract Class rồi!

5. Tổng kết

Vậy là chúng ta đã hiểu thêm về sự khác biệt giữa Interface và Abstract Class rồi. Tóm lại:

Nếu bạn cần "đa kế thừa" hoặc các lớp không liên quan cùng thực hiện một hành vi, hãy chọn Interface.
Nếu bạn muốn chia sẻ code và các lớp có mối quan hệ "họ hàng", hãy chọn Abstract Class.

Cảm ơn các bạn đã theo dõi! Có câu hỏi nào không? Đừng ngại để lại bình luận nhé! 😊

DRY Principles

Cong Quy Nguyen — Sun, 05 Jan 2025 11:16:30 +0000

DRY Principle - "Don't Repeat Yourself"

🤔 Vậy DRY là gì nhỉ?

"DRY" là viết tắt của "Don't Repeat Yourself", một nguyên tắc vàng trong lập trình (và cả trong cuộc sống nữa đó!). Ý tưởng rất đơn giản: "Đừng lặp lại chính mình."

Hãy tưởng tượng bạn viết một công thức nấu ăn mà phải copy-paste từng bước mỗi khi làm một món ăn khác. Lỡ bạn muốn thêm muối, bạn sẽ phải cập nhật từng bản copy. Ngán chưa? Đó chính là "lặp lại" trong lập trình!

DRY dưới góc nhìn lập trình

Nguyên tắc DRY yêu cầu bạn cô lập logic hoặc đoạn mã thường lặp lại vào một vị trí duy nhất. Khi cần thay đổi, bạn chỉ việc sửa một nơi mà không cần tìm từng dòng để sửa.

✔ Ví dụ:

Bạn đang viết một ứng dụng quản lý thú cưng:

Trước khi áp dụng DRY:

public void feedDog() {
    System.out.println("Feeding the dog");
}

public void feedCat() {
    System.out.println("Feeding the cat");
}

public void feedParrot() {
    System.out.println("Feeding the parrot");
}

Cứ thêm thú cưng là bạn phải viết thêm một phương thức mới. Thật phiền phức đúng không nào? 🙈

public void feedAnimal(String animal) {
    System.out.println("Feeding the " + animal);
}

Bây giờ, bạn chỉ cần gọi feedAnimal("dog"), feedAnimal("cat") mà không lo lặp lại đoạn code y chang nhau! Tiết kiệm thời gian, giảm đau đầu. 🥳

DRY trong thực tế

DRY không chỉ giúp bạn viết code "ngầu" hơn mà còn cải thiện khả năng bảo trì và mở rộng ứng dụng.

✔ Một ví dụ thực tế:

Giả sử bạn xây dựng một website và phải sử dụng cùng một đoạn HTML cho phần footer:

<div class="footer">
    <p>Contact us at: congquynguyen@gmail.com</p>
</div>

Trước DRY:
Bạn copy-paste đoạn HTML này vào mọi trang. Lỡ email thay đổi? Hoặc đó là một đoạn code dài ơi là dài ? Bạn phải chỉnh sửa từng trang. Quá tốn công!

Sau DRY:
Sử dụng một tệp template hoặc component tái sử dụng:

<include src="footer.html"></include>

Bây giờ chỉ cần sửa một tệp duy nhất khi có thay đổi. Đơn giản hơn nhiều, đúng không?

Lợi ích khi áp dụng DRY

Dễ bảo trì hơn: Sửa một chỗ thay vì "sửa toàn cầu".
Code gọn gàng: Giảm "sự lộn xộn" và tăng độ đọc hiểu.
Ít lỗi hơn: Mỗi thay đổi đều được áp dụng nhất quán.

Thách thức khi thực hiện DRY

Over-DRY: Đừng cố DRY mọi thứ! Đôi khi, chia nhỏ quá mức sẽ làm code phức tạp và khó hiểu hơn.
Lựa chọn sai ngữ cảnh: DRY chỉ hiệu quả khi áp dụng đúng lúc, đúng chỗ. Nếu không, nó sẽ trở thành một "cơn ác mộng bảo trì."

Tóm lại

Nguyên tắc DRY là một trong những "bí kíp" giúp bạn trở thành lập trình viên chuyên nghiệp. Tuy nhiên, hãy nhớ rằng cân bằng là chìa khóa. Không phải lúc nào DRY cũng là giải pháp tốt nhất, nhưng khi áp dụng đúng, nó sẽ giúp bạn tiết kiệm cả thời gian và năng lượng! 💪

SOLID Principles

Cong Quy Nguyen — Sun, 05 Jan 2025 11:16:06 +0000

SOLID: Bí mật để code "đỉnh" hơn mỗi ngày!

Chào bạn,

Hôm nay, hãy tưởng tượng chúng ta ngồi lại, pha tách cà phê và nói chuyện về thứ gì đó vừa ngầu vừa hữu ích cho công việc viết code hằng ngày nhé. Chủ đề chính là: SOLID, một tập hợp nguyên tắc giúp chúng ta viết code sạch hơn, dễ bảo trì hơn và, nói thẳng ra, "ngầu" hơn khi làm việc nhóm.

Nếu bạn từng nghĩ:

"Sao code của mình dễ bị lỗi vậy?"
"Code này sửa một tí là lan ra cả dự án, phải làm sao đây?"

Thì đây, SOLID chính là người bạn đồng hành tuyệt vời! 😎

Vậy SOLID là gì?

SOLID gồm 5 nguyên tắc "vàng" trong thiết kế phần mềm, đặt nền móng cho code dễ hiểu, dễ mở rộng và dễ bảo trì. Chúng ta cùng đi qua từng nguyên tắc nhé!

1. Single Responsibility Principle (SRP)

"Một lớp chỉ nên có một lý do để thay đổi."

Hãy nghĩ về nó như việc mỗi người chỉ nên làm một việc cụ thể trong nhóm. Nếu bạn làm cả code backend lẫn thiết kế giao diện, bạn sẽ nhanh chóng mệt mỏi và mắc lỗi.

Ví dụ xấu:

public class UserService {
    public void addUser() { 
        // Thêm người dùng
    }

    public void sendWelcomeEmail() { 
        // Gửi email chào mừng
    }
}

Ở đây, UserManager vừa quản lý người dùng, vừa lo việc gửi email. Không ổn chút nào!

Cải thiện:

Tách riêng trách nhiệm:

public class UserService {
    public void addUser() { 
        // Thêm người dùng
    }
}

public class EmailService {
    public void sendWelcomeEmail() { 
        // Gửi email chào mừng
    }
}

2. Open/Closed Principle (OCP)

"Mở rộng được nhưng không sửa đổi."

Bạn thích thêm tính năng mà không phải đụng vào code cũ chứ? Đây là nguyên tắc dành cho bạn. Code cũ không sửa thì ít lỗi, đúng không? 😉

Ví dụ xấu:

public class Discount {
    public double calculate(String type) {
        if (type.equals("NEW_YEAR")) {
            return 50;
        } else if (type.equals("BLACK_FRIDAY")) {
            return 70;
        }
        return 0;
    }
}

Ở đây, nếu bạn muốn thêm một dịp giảm giá nào đó thì sao, ví dụ như giảm giá cho cô Thơ chẳng hạn? Hiển nhiên là bạn phải động vào class Discount và chỉnh sửa mã nguồn của nó rồi, nhưng điều này thật sự thì không được hay cho lắm, hãy đọc tiếp để biết được cách giải quyết sao cho thật "ngầu" nhé =))

Cải thiện:

Sử dụng kế thừa:

public interface Discount {
    double calculate();
}

public class NewYearDiscount implements Discount {
    @Override
    public double calculate() {
        return 50;
    }
}

public class BlackFridayDiscount implements Discount {
    @Override
    public double calculate() {
        return 70;
    }
}

Bạn có thể sử dụng một interface để đưa ra các ràng buộc mà các class thực thi phải làm theo (có thể tham khảo lại bài trước). Lúc này thì bạn chỉ cần tạo mới một đối tượng thôi chứ không cần phải can thiệp vào mã nguồn cũ. Trên thực tế, các vấn đề sẽ không đơn giản như thế này đâu nhé!

3. Liskov Substitution Principle (LSP)

"Lớp con phải có thể thay thế lớp cha mà không làm hỏng chương trình."

Nguyên tắc này nghe thì hơi "trừu tượng", nhưng ý tưởng rất đơn giản: nếu bạn thay lớp cha bằng lớp con, mọi thứ vẫn phải chạy tốt.

Hãy cùng xem một ví dụ nổi tiếng từ cuốn Head First Design Patterns:

public class Duck {
    public void quack() {
        System.out.println("Quack!");
    }

    public void swim() {
        System.out.println("Swimming!");
    }
}

public class RubberDuck extends Duck {
    @Override
    public void quack() {
        System.out.println("Squeak!");
    }

    @Override
    public void swim() {
        throw new UnsupportedOperationException("Rubber duck can't swim!");
    }
}

public class DuckTest {
    public static void main(String[] args) {
        Duck duck = new RubberDuck(); // Thay thế lớp cha bằng lớp con
        duck.swim(); // Lỗi xảy ra do RubberDuck không thể bơi
    }
}

Ở đây, RubberDuck (ở đây là vịt đồ chơi nhea) kế thừa Duck nhưng lại phá vỡ hành vi dự kiến của lớp cha vì nó không thực hiện được phương thức swim. Điều này gây ra lỗi khi sử dụng.

Để cải thiện điều này, dưới góc độ cá nhân của mình thì mình đánh giá là vì kế thừa, sử dụng interface để đảm bảo rằng chỉ những lớp thực sự có khả năng bơi mới triển khai hành vi này sẽ khả thi và hợp lý hơn (các bạn có thể chia sẻ cách khác nhé).

Đây là ví dụ minh họa để giải quyết vấn đề của mình

public interface SwimBehavior {
    void swim();
}

public interface QuackBehavior {
    void quack();
}

public class Duck implements SwimBehavior, QuackBehavior {
    @Override
    public void swim() {
        System.out.println("Swimming!");
    }

    @Override
    public void quack() {
        System.out.println("Quack!");
    }
}

public class RubberDuck implements QuackBehavior {
    @Override
    public void quack() {
        System.out.println("Squeak!");
    }
}

4. Interface Segregation Principle (ISP)

"Không nên bắt ai đó dùng những thứ họ không cần."

Nếu bạn tạo ra một interface quá lớn, các lớp triển khai sẽ phải "gánh" những thứ không liên quan.

Ví dụ xấu:

public interface Worker {
    void work();
    void eat();
}

public class Robot implements Worker {
    @Override
    public void work() { 
        // Làm việc
    }

    @Override
    public void eat() { 
        // ??? Robot đâu có ăn!
    }
}

Cải thiện:

Tách interface:

public interface Worker {
    void work();
}

public interface Eater {
    void eat();
}

Trên đây là cách giải quyết dựa trên tư tưởng của ISP, tuy nhiên bạn cũng đừng nên lạm dụng quá nhé, bởi vì như bạn thấy đấy, cách giải quyết này có một nhược điểm đó chính là sản sinh ra nhiều interface nên nếu không khéo léo thì dễ gây ra sự thừa thải trong mã nguồn. Vậy nên hãy cẩn thận khi sử dụng nhé!

5. Dependency Inversion Principle (DIP)

"Code nên phụ thuộc vào abstraction, không phụ thuộc vào implementation."

Nghe hơi phức tạp, nhưng bạn chỉ cần nhớ: thay vì code phụ thuộc vào chi tiết cụ thể, hãy để nó dựa vào cái tổng quát.

Bây giờ mình sẽ trình bày một ví dụ để các bạn dễ hình dung. Do phần này khá là khó nên các bạn chú ý tập trung nhé!

Mình sẽ lấy ví dụ về việc thiết kế một service xử lý thanh toán. Hiện tại, ví dụ chúng ta có 1 phương thức thanh toán là PayPalPayment:

public class PayPalPayment {
    public void processPayment(double amount) {
        System.out.println("Payment of $" + amount + " processed via PayPal.");
    }
}

public class PaymentProcessor {
    private PayPalPayment payPalPayment;

    public PaymentProcessor() {
        this.payPalPayment = new PayPalPayment();
    }

    public void makePayment(double amount) {
        payPalPayment.processPayment(amount);
    }
}

// Main
public class Main {
    public static void main(String[] args) {
        PaymentProcessor processor = new PaymentProcessor();
        processor.makePayment(100.0);
    }
}

Tại đây sẽ xuất hiện một vấn đề, PaymentProcessor phụ thuộc trực tiếp vào lớp PayPalPayment. Nếu cần tích hợp thêm phương thức thanh toán mới (ví dụ: Stripe, Bank Transfer), bạn sẽ phải sửa đổi code trong PaymentProcessor, vi phạm OCP và tăng rủi ro lỗi.

Lúc này, để tuân thủ theo DIP, chúng ta cần tạo ra một abstraction (interface PaymentService) để đại diện cho hành vi thanh toán.

// Abstraction
public interface PaymentService {
    void processPayment(double amount);
}

// PayPal
public class PayPalPayment implements PaymentService {
    @Override
    public void processPayment(double amount) {
        System.out.println("Payment of $" + amount + " processed via PayPal.");
    }
}

// Stripe
public class StripePayment implements PaymentService {
    @Override
    public void processPayment(double amount) {
        System.out.println("Payment of $" + amount + " processed via Stripe.");
    }
}

public class PaymentProcessor {
    private PaymentService paymentService;

    // Dependency Injection qua constructor
    public PaymentProcessor(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    public void makePayment(double amount) {
        paymentService.processPayment(amount);
    }
}

// Main
public class Main {
    public static void main(String[] args) {
        // Inject PayPalPayment
        PaymentProcessor payPalProcessor = new PaymentProcessor(new PayPalPayment());
        payPalProcessor.makePayment(100.0);

        // Inject StripePayment
        PaymentProcessor stripeProcessor = new PaymentProcessor(new StripePayment());
        stripeProcessor.makePayment(200.0);
    }
}

Khi triển khai như thế này thì PaymentProcessor chỉ biết PaymentService và không cần quan tâm tới chi tiết của PayPalPayment hay StripePayment, do đó khi muốn thêm một phương thức thanh toán mới (ví dụ: BankTransferPayment), chỉ cần tạo lớp mới triển khai PaymentService.

Lời kết

Bạn thấy đó, nguyên tắc SOLID không hề "đáng sợ" như tên gọi. Nó giống như những bài học nhỏ, giúp bạn trở thành một lập trình viên thông minh hơn mỗi ngày. Để áp dụng được tốt SOLID trong quá trình code của mình, không phải ngày một ngày hai mà được nhé, nó sẽ dần tích hợp vào khả năng của bạn trong quá trình phát triển.

Vậy, bạn đã sẵn sàng áp dụng SOLID vào code của mình chưa? Cùng thử ngay và xem sự khác biệt nhé! 🚀

Include vs Extend

Cong Quy Nguyen — Sun, 05 Jan 2025 11:15:29 +0000

Include vs Extend – Vấn đề Use Case!

💡 Chào mừng bạn đến với thế giới của Use Case =))

Hôm nay, chúng ta sẽ khám phá hai mối quan hệ nổi tiếng nhất trong mô hình Use Case: <<include>> và <<extend>>. Hãy tưởng tượng đây là hai người bạn trong thế giới lập trình, mỗi người đều có sức cách hành xử riêng và mục tiêu đặc biệt.

1. `<<include>>` – Người bạn "luôn luôn bên nhau"

<<include>> là kiểu bạn đồng hành trung thành. Họ luôn xuất hiện mỗi khi bạn cần hoàn thành công việc. Đây là người mà bạn gọi khi muốn tái sử dụng những việc làm lặp đi lặp lại.

Ví dụ siêu đơn giản:

Hãy tưởng tượng bạn đang quản lý một trang web bán sách.

Khi khách hàng đăng ký tài khoản, bạn luôn luôn cần thực hiện bước xác nhận email.
Tương tự, khi xác nhận một đơn hàng, bạn cũng luôn luôn cần thực hiện phương thức xác nhận.

Tính cách của `<<include>>`:

Cần thiết: Không có họ, công việc sẽ không thể hoàn thành.
Cứu tinh của sự lặp lại: Nếu một hành động xuất hiện ở nhiều nơi? Gọi ngay cho <<include>>!

Ký hiệu:

Mũi tên đứt nét, có nhãn <<include>>, trỏ từ Use Case chính đến Use Case được bao gồm.

📌 Tóm lại: <<include>> là kiểu bạn không thể thiếu, luôn đi cùng bạn trên hành trình.

2. `<<extend>>` – Người bạn "chỉ đến khi cần"

<<extend>> lại là kiểu bạn đặc biệt, chỉ xuất hiện khi bạn thực sự cần. Họ là người mang đến sự tùy chọn trong các tình huống cụ thể.

Ví dụ siêu thực tế:

Quay lại trang web bán sách:

Khi khách hàng thực hiện xem đơn hàng, họ có thể yêu cầu thêm tính năng hủy đơn hàng hoặc hoàn trả đơn hàng nếu muốn.
Hoặc trong quá trình đăng nhập, nếu khách hàng quên mất mật khẩu, tính năng quên mật khẩu có thể được áp dụng để giảm lấy lại mật khẩu cho khách hàng.

Tính cách của `<<extend>>`:

Tùy chọn: Không phải lúc nào cũng cần đến họ.
Linh hoạt: Chỉ xuất hiện khi điều kiện đặc biệt xảy ra.

Ký hiệu:

Mũi tên đứt nét, có nhãn <<extend>>, trỏ từ Use Case mở rộng đến Use Case chính.

📌 Tóm lại: <<extend>> là người bạn thêm "gia vị" cho cuộc sống của bạn khi cần thiết.

3. `<<include>>` vs `<<extend>>` – Ai là ai?

Tiêu chí	`<<include>>`	`<<extend>>`
Khi nào dùng?	Khi một Use Case luôn cần Use Case khác.	Khi một Use Case có thể mở rộng hành vi của Use Case chính.
Hành vi	Bắt buộc: Luôn được thực hiện.	Tùy chọn: Chỉ thực hiện khi điều kiện xảy ra.
Mục đích	Tái sử dụng, giảm lặp lại.	Thêm chức năng đặc biệt, linh hoạt.
Ví dụ	Gửi mail khi đăng ký tài khoản.	Quên mật khẩu khi đăng nhập.

💡 Kết luận

<<include>> giúp bạn tổ chức công việc hợp lý và không lặp lại chính mình.
<<extend>> mang đến sự linh hoạt và những trải nghiệm thú vị, cá nhân hóa hơn.

Dù là <<include>> hay <<extend>>, cả hai đều là những người đồng hành đáng tin cậy, những trợ thủ đắt lực trên trên hành trình thiết kế Use Case của bạn! 🚀