"Câu trả lời là với việc type-hint Interface thì ta có thể có được sự linh hoạt trong việc thay đổi các Implementation mà mình muốn, hay sử dụng một Implementation mà mình viết thay vì cái mặc địch của Laravel mà không gây ảnh hưởng gì đến Framework hay service của mình. Đó là nguyên tắc "program to an interface, not an implementation"!
Chẳng hạn như bạn cần viết một package có sử dụng chức năng gửi mail. Hay nói cách khác bạn sẽ cần một class có dependency là một class gửi mail nào đó, giả sử là MailerImplentation chẳng hạn. Nếu bạn sử dụng dependency injection thông qua constructor với type-hint là MailerImplentation thì class của bạn sẽ hoàn toàn bị phụ thuộc vào MailerImplentation đó và không thể thay đổi được.
Thay vào đó bạn nên để dependency của class của mình là MailerInterface, khi đó thì bất kỳ class nào có implement MailerInterface đều có thể được inject vào và sử dụng trong class của bạn. Như vậy thì trong service chỉ cần có một implementation của MailerInterface là package của bạn sẽ có thể hoạt động, bạn không cần biết implementation đó là gì, là mặc địch hay là do người khác viết."
:d, sau khi hiểu khái niệm, rồi đi vô vấn đề, thì tự nhiên quên mất khái niệm, ra nghiền ngẫm lại thế nào là đồng bộ, vô lại Await/async thì lại rối tung lên. Thật sự basic của js rối nhất thằng này, nhưng cố cạp cũng xong. Js là bất đồng bộ, promise là để xử lý đồng bộ lại cho cái Bất đồng bộ đó. Còn tại sao js lại Bất đồng bộ thì lại là 1 câu chuyện cũng khá hay ho, nói chung là mệt mỏi. =)))).
Mình thắc mắc là tại sao mình phải bind interface với class implement cái interface đó rùi inject cái interface đó trong controller
mà không inject trực tiếp cái class implement cái interface đó trong controller nhỉ
THẢO LUẬN
cho mình hỏi. Làm sao để xem được các thông tin request và response của giao thức rtp khi mình request vào một cái stream sever. Cám ơn bạn
cảm ơn bạn, nếu như vậy thì mình đã hiểu rõ rồi.
Thanks bạn, mình đã hiểu ^^
ok bạn nạ =))
ok bạn nạ
"Câu trả lời là với việc type-hint Interface thì ta có thể có được sự linh hoạt trong việc thay đổi các Implementation mà mình muốn, hay sử dụng một Implementation mà mình viết thay vì cái mặc địch của Laravel mà không gây ảnh hưởng gì đến Framework hay service của mình. Đó là nguyên tắc "program to an interface, not an implementation"!
Chẳng hạn như bạn cần viết một package có sử dụng chức năng gửi mail. Hay nói cách khác bạn sẽ cần một class có dependency là một class gửi mail nào đó, giả sử là MailerImplentation chẳng hạn. Nếu bạn sử dụng dependency injection thông qua constructor với type-hint là MailerImplentation thì class của bạn sẽ hoàn toàn bị phụ thuộc vào MailerImplentation đó và không thể thay đổi được.
Thay vào đó bạn nên để dependency của class của mình là MailerInterface, khi đó thì bất kỳ class nào có implement MailerInterface đều có thể được inject vào và sử dụng trong class của bạn. Như vậy thì trong service chỉ cần có một implementation của MailerInterface là package của bạn sẽ có thể hoạt động, bạn không cần biết implementation đó là gì, là mặc địch hay là do người khác viết."
Trích đoạn bài viết https://viblo.asia/p/laravel-beauty-tim-hieu-ve-service-container-3KbvZ1wLGmWB#_service-container-everywhere-6
Cảm ơn bạn đã đọc bài ạ
nếu thấy hữu ích thì chia sẻ cho bạn bè nhé 
Uầy uầy, cảm ơn bạn nha. Rất là vui
Cảm ơn bạn nhé. Mình sẽ cố gắng thu xếp thời gian
Thông tin rất hữu ích, cảm ơn bạn đã chia sẻ
Nhờ bạn mới biết đến "chunk method". Lúc nào thử áp dụng trong project xem thế nào!
Ừa, t mới demo HTTP thôi chứ chưa có HTTPS (yaoming)
Thông tin bổ ích. Nhưng đoạn HTTP/HTTPS cần sửa lại đoạn port của HTTPS thành 443 nha :v
Cảm ơn bạn đã chia sẻ. Mình cũng đag bắt đầu tìm hiểu về async để áp dụng vào web của mình. Cải thiện được tốc độ xử lý sướng hơn hẳn.
Bạn dùng signalR là ngon đó bạn.
Bình luận cũng hay quá bạn ơi
@Plumpboy cảm ơn bạn đã bổ sung cho mình
mình đã sửa lại rồi nehs chỗ này là lỗi do mình viết nhầm, cảm ơn bạn đã report
:d, sau khi hiểu khái niệm, rồi đi vô vấn đề, thì tự nhiên quên mất khái niệm, ra nghiền ngẫm lại thế nào là đồng bộ, vô lại Await/async thì lại rối tung lên. Thật sự basic của js rối nhất thằng này, nhưng cố cạp cũng xong. Js là bất đồng bộ, promise là để xử lý đồng bộ lại cho cái Bất đồng bộ đó. Còn tại sao js lại Bất đồng bộ thì lại là 1 câu chuyện cũng khá hay ho, nói chung là mệt mỏi. =)))).
Mình thắc mắc là tại sao mình phải bind interface với class implement cái interface đó rùi inject cái interface đó trong controller mà không inject trực tiếp cái class implement cái interface đó trong controller nhỉ