Trước tiên cảm ơn bạn nhé, câu hỏi gãi đúng chỗ ngứa lunn.
Mình khuyên thật là bạn nên "say no" với Decorator trong case này nhé. Lúc đầu bọc bọc lại thì thấy hay, nhưng tới lúc Business yêu cầu đổi thứ tự tính tiền (kiểu giảm % trước hay trừ tiền mặt trước), hoặc áp luật "dùng mã A thì cấm mã B" là code toang ngay, siêu rối.
Thay vào đó, bạn cứ "vã" combo Strategy + Chain of Responsibility (kiểu Pipeline) cho mình. Tách mỗi khuyến mãi thành một Strategy độc lập, rồi cho chạy qua một cái Chain. Trúng stack Java/Spring Boot thì cứ nhét vào List rồi dùng @Order mà sắp xếp là chuẩn bài! Sau này có thêm chục cái khuyến mãi mới thì chỉ việc viết class mới, không lo đụng chạm code cũ. Bạn cứ thử hướng này xem nhé. Dự án hiện tại của bạn có dính nhiều mấy quả rule khuyến mãi "đánh nhau" (loại trừ lẫn nhau) không? 🤜🤛
Bài viết tổng hợp rất hay và dễ hiểu, cảm ơn tác giả! Sẵn tiện đang bàn về Design Pattern, mình đang gặp một bài toán thực tế và muốn tham khảo góc nhìn của bạn.
Bài toán là tính tổng tiền của giỏ hàng khi user có thể áp dụng nhiều loại khuyến mãi cùng lúc (ví dụ: giảm 10% cho thành viên VIP, giảm 50k cho đơn trên 500k, và thêm mã Freeship).
Mình đang phân vân giữa việc dùng Decorator Pattern (để bọc/wrap các rule tính giá lại với nhau) hoặc kết hợp Strategy Pattern với Chain of Responsibility. Theo kinh nghiệm của bạn thì pattern nào sẽ tối ưu, dễ scale và dễ maintain hơn khi số lượng rule khuyến mãi ngày càng nhiều và phức tạp? Rất mong nhận được chia sẻ từ bạn
THẢO LUẬN
Bài viết hay, đúng thực tế mình đang gặp trong quá trình làm việc, căn bản là hay vị vội nên cứ có yêu cầu là lao vào làm
Hay quá bạn ơi, hóng phân tích thêm các design pattern khác
Giờ mới hiểu ra vấn đề, thankiu tác giả vì chia sẻ
NGUYỄN HUY HOÀNG Software Engineer
📞 Phone: 0941 280 073
📧 Email: hhoang02052004@gmail.com
Bài viết hay. Cảm ơn chủ thớt 😁
Rất vui vì bài viết giúp ích được cho bạn, thấy hay thì chia sẻ mọi người nhé
Cảm ơn sự ủng hộ và ghi nhận của bạn nhé🥰
Trước tiên cảm ơn bạn nhé, câu hỏi gãi đúng chỗ ngứa lunn. Mình khuyên thật là bạn nên "say no" với Decorator trong case này nhé. Lúc đầu bọc bọc lại thì thấy hay, nhưng tới lúc Business yêu cầu đổi thứ tự tính tiền (kiểu giảm % trước hay trừ tiền mặt trước), hoặc áp luật "dùng mã A thì cấm mã B" là code toang ngay, siêu rối. Thay vào đó, bạn cứ "vã" combo Strategy + Chain of Responsibility (kiểu Pipeline) cho mình. Tách mỗi khuyến mãi thành một Strategy độc lập, rồi cho chạy qua một cái Chain. Trúng stack Java/Spring Boot thì cứ nhét vào List rồi dùng @Order mà sắp xếp là chuẩn bài! Sau này có thêm chục cái khuyến mãi mới thì chỉ việc viết class mới, không lo đụng chạm code cũ. Bạn cứ thử hướng này xem nhé. Dự án hiện tại của bạn có dính nhiều mấy quả rule khuyến mãi "đánh nhau" (loại trừ lẫn nhau) không? 🤜🤛
Rất vui vì bài viết giúp ích được cho bạn😁
Bài viết tổng hợp rất hay và dễ hiểu, cảm ơn tác giả! Sẵn tiện đang bàn về Design Pattern, mình đang gặp một bài toán thực tế và muốn tham khảo góc nhìn của bạn. Bài toán là tính tổng tiền của giỏ hàng khi user có thể áp dụng nhiều loại khuyến mãi cùng lúc (ví dụ: giảm 10% cho thành viên VIP, giảm 50k cho đơn trên 500k, và thêm mã Freeship). Mình đang phân vân giữa việc dùng Decorator Pattern (để bọc/wrap các rule tính giá lại với nhau) hoặc kết hợp Strategy Pattern với Chain of Responsibility. Theo kinh nghiệm của bạn thì pattern nào sẽ tối ưu, dễ scale và dễ maintain hơn khi số lượng rule khuyến mãi ngày càng nhiều và phức tạp? Rất mong nhận được chia sẻ từ bạn
Khá hay và dễ hiểu
Một chủ đề không phải là mới, nhưng cách tiếp cận, đặt câu hỏi và những ví dụ đi kèm khá hay, cảm ơn công sức của tác giả
Cảm ơn tác giả đã khai sáng mình huhu
Đúng nơi, đúng người rồi đây, quá hay tác giả ơiii
Quá hay, 10đ
Nào ra tiếp phần 2 thế bạn
Cực thích cách viết bài của bạn này
Bài viết xứng đáng được chia sẻ rộng rãi, rất hay và dễ hiểu
Bài viết chi tiết, đi vào bản chất, các ví dụ khá dễ hiểu, các bạn mới nên đọc
Cảm ơn tác giả đã chia sẻ