quan điểm cá nhân của em thôi nhé: Trong cách làm dựa vào Factory DP như trong Ví dụ này :

• A đang sử dụng 1 data-structure trong Factory để tạo ra Customer cần thiết -> đặc điểm của loại này là khó thay đổi type, dễ thêm behavior, đoạn này đồng ý vì trách nhiệm lớn nhất của Factory là để tạo ra instance mình cần.
• Ở công đoạn tiêu thụ instance có được từ Factory, ta lại sử dụng các instance của Object (hiden type, public behavior).

Bây giờ đặt trường hợp em muốn thêm hành vi gift() cho các loại customer, anh sẽ phải viết thêm vào toàn bộ các Class Customer => không tốt Và nếu em muốn thêm loại Customer Standard thì em phải sửa lại Factory => cũng không tốt

thay vì thế nếu em không dùng Factory, mà chỉ sử dụng 1 datastructure như Code ban đầu của anh lúc chưa dùng Factory, thì khi em muốn thêm 1 behavior thì rất đơn giản đổi lại việc thêm 1 Type của Customer thì khó khăn hơn vì phải sửa lại Code cũ. 1 vấn đề có tính 2 chiều, đều có lợi và có hại.

Nói chung là theo em nên tuỳ từng trường hợp, ý đồ của mình phát triển theo hướng nào thì mới áp dụng các DP vào nữa

Cảm ơn anh đã cho em một bài học bổ ích , thanks

Ha ha, còn 1 vài bài nữa mới hết series nên chưa đến bài cuối luôn được đâu ^^. Còn vấn đề thêm mới "hành vi" thì thà rằng chúng ta thêm mới ở các class được tập trung trong 1 folder sẽ dễ dàng hơn rất nhiều là phải thêm mới ở các file khác nhau trong hệ thống ^^

Đã làm theo gợi ý của bạn ^^. Xin cám ơn bạn rất nhiều

cái ví dụ cuối cùng, không phải trường hợp nào cũng áp dụng được, cái này chỉ áp dụng được khi mình có nhu cầu thêm mới các "type (hạng khách hàng)", còn nếu muốn thêm mới "hành vi" sẽ phải sửa lại code của toàn bộ các class

btw, ra nốt bài cuối của series luôn đi anh

@trthanhbk Cảm ơn anh vì những bài viết hữu ích về Laravel (y) Em có một góp ý nhỏ là ở mỗi bài viết trong series, anh thêm vào mục index về danh sách và đường link dẫn đến các bài viết, kiểu như

Index

Kiến trúc hệ thống trên Laravel – phần 1 Kiến trúc hệ thống trên Laravel – phần 2 Kiến trúc hệ thống trên Laravel – phần 3 Kiến trúc hệ thống trên Laravel – phần 4 Kiến trúc hệ thống trên Laravel – phần 5 Kiến trúc hệ thống trên Laravel – phần 6 Kiến trúc hệ thống trên Laravel – phần 7

thì người đọc mới vào sẽ dễ dàng tiếp cận được với những bài viết cũ trong series của anh hơn ạ

@VibloTeam Dear Viblo Team, Xin lỗi vì mình không để ý điều này. Mình đã cập nhật link đến bài viết gốc rồi ạ.

@ho.van.tuan Chúng tôi nhận được report báo rằng bài viết của bạn được dịch từ nguồn https://medium.com/@ageitgey/machine-learning-is-fun-80ea3ec3c471

Nếu thực sự là vậy, mong bạn có thể giới thiệu và bổ sung đường link dẫn đến bài viết gốc vào bài viết của mình. Xin cám ơn bạn rất nhiều.

Cảm ơn bạn đã có bài viết hay. (bow)

good job !

Theo mình cách implement của tác giả cho lớp Builder Pattern đã vi phạm nguyên tác "O" trong SOLID rồi.

Chính xác em, anh đã sửa nhé.

B cho mình xem file docker-compose.yml của bạn đi

Bài viết của bạn rất hay

Bài viết hay lắm

Please. Translate to Vietnamese.

Chào bạn Thành Trần Công, bạn liên lạc với mình https://www.facebook.com/du.ngodac mình sẽ giải thích và gửi bạn demo

Tuyệt vời!

Tác giả có source code ko cho mình xin thao khảo ? Còn rối logic một số chổ như là:

đoạn "let indexPath = NSIndexPath(forItem: index, inSection: section)" : rows với section là từ bên ngoài mình thả vào trong layout à hay là thế nào .

if (section == 0) && (index == 0) { attributes.zIndex = 1024 } else if (section == 0) || (index == 0) { attributes.zIndex = 1023 } đoạn này mình ko hiểu hơi mâu thuẩn , mình ko hiểu rõ . Tác giả có thể vẽ ra đâu là vùng section đâu là vị trí index cho mình được không ?

sectionAttributes.addObject(attributes) , nó ở đâu ko có khai báo và sectionAttributes thì nó là kiểu gì ?

và cuối cùng là khi sử dụng uicollectionview thì mình có infinite scroll cho nó có đc không ? Nếu đc tác giả có thể cho mình facebook để liên lạc nhá mình cũng có 1 số câu hỏi ?

thanks