chả hiểu gì

"Bạn mới" mà viết thế này thì sao gọi là dễ hiểu được bạn??? đơn điệu đơn giản quá, cứ như kiểu 'lười viết'. Đọc xong ko thấy gì sáng tỏ hơn!

Hóng bản tiếng Việt để có thể hiểu sâu hơn

@thangtd90 Bài viết của anh rất chi tiết và văn phong cũng rất hay, khó có thể kiếm được bài nhập môn nào tốt hơn. Cảm ơn anh đã dành thời gian để viết bài này.

@Vagabond Bài viết sau có một đoạn nói về self vs static, hy vọng nó có ích cho bạn https://viblo.asia/Hoanghoi/posts/MLzGObjnvpq#ph-n-bi-t-static-method-v-i-self-method-10

僕もKarabinerを使っています。超便利ですね。日本語レイアウトのキーボードでもOK!

@Vagabond: Bạn có thể đọc chi tiết thông qua cụm từ Late Static Bindings

Vậy cho mình hỏi cách sử dụng self:: và static:: khác biệt như thế nào?

Mình đồng ý với bạn . Một vấn đề luôn có nhiều cách giải quyết, không phải lúc nào cũng nhất nhất phải design pattern ^^. Design pattern bản chất sinh ra để giải quyết 1 số vấn đề nhất định nên nó không phải là cái gì đó là hoàn hảo ^^. Điều quan trọng khi học design pattern là nhận diện được vấn đề để áp dụng được nó vào -> đừng nên thần tượng hóa design pattern nhưng cũng không được xem nhẹ nó nha >.<

với mảng trong js mình thường dùng for(var index in arr) hơn không cần biết phần tử mảng dài bao nhiêu.

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 !