theo tôi thấy ví dụ của tác giả chưa thực sự đúng với mục tiêu của pattern này.ngay từ việc có 2 interface cho 2 đối tượng chính

Nice profile pic vai. Also, nice article (y)

(good)

Ra nhiều bài nữa Minh nhé. Có thời gian tớ sẽ tìm hiểu cái này Dạo này bận quá

Cảm ơn anh nhiều, mong a luôn khỏe mạnh và thành công Em luôn chờ những bài chia sẻ của anh

Thêm nốt trường hợp transclude đi cưng

@asiful thanks a lot just tried my best to know something for myself & share with all !

@iamloivx Có nhiều solution để giải quyết một bài toán và trong bài viết này tôi chọn trait để giới thiệu. Dùng interface kết hợp với trait thích hợp với trường hợp như bạn nói trong Laravel khi triển khai Contract. Còn trường hợp không dùng interface chỉ là ví dụ giả định cho trường hợp của tôi. Cảm ơn bạn đã đóng góp ý kiến (bow)

@iamloivx Bài viết của mình focus vào việc xây dựng Repository, còn trường hợp bạn nói mình nghĩ là một bài toán riêng rẽ. Bạn có chắc rằng tất cả các RDMS đều hỗ trợ Transaction hay không? Hoặc với NoSQL chẳng hạn. Còn với MySQL với bài toán mà bạn đặt ra mình nghĩ chúng ta có thể tìm hiểu về Nesting Transaction hoạt động thế nào và phụ thuộc vào logic bài toán cụ thể mà bạn triển khai.

MySQL có hỗ trợ SAVEPOINTS với engine InnoDB giúp ta giải quyết bài toán Nesting Transaction, đồng thời Laravel 5.1 cũng đã hỗ trợ Nesting Transaction

Một giải pháp "chày cối" là cho class C kế thừa từ class B (tôi sử dụng được Y) rồi lại cho class B kế thừa từ class A (tôi sử dụng được X)

Tại sao bạn không sử dụng interface?

Trait có thể giải quyết vấn đề của bạn ngay tức khắc, tuy nhiên Composition có thể là câu trả lời chính xác hơn cho những khó khăn mà bạn gặp phải.

Bạn dùng Laravel chắc bạn hiểu vì sao Laravel sinh ra nhiều Contract đến thế. Thông thường, trait sẽ đi kèm với interface. Ví dụ, bạn định nghĩa interface A thì sẽ kèm với một trait A để giảm thiểu việc bạn duplicate code (Don't repeat yourself). Class X cài đặt interface A sẽ có lựa chọn sử dụng cài đặt mặc định từ trait A của bạn hoặc là có thể viết customize cho riêng nó.

Mình đọc nhiều bài viết về Repository và thấy tác giả ít khi đề cập tới transaction khi xử lý logic với nhiều repository. Không biết bạn có hướng xử lý thế nào không.

cái này không cần facebook cấp quyền thì phải mình đã làm và không thấy nó hỏi han gì , nếu chưa login thì nó bắt login thôi . còn về nó có khá nhiều thứ nên dùng mỗi chức năng share social thôi thì cũng làm nặng game đó . nhưng thường trong game có cả phần mua bán item , google analytic , hiển thị popup của native những cái đó cái này làm được tất và còn nhiều tính năng của native nữa mà unity không làm được .

অসাধারণ লেখা। অনেক কিছু জানতে পারলাম।

ধন্যবাদ লেখককে এরকম চমৎকার একটা লেখার জন্য।

Mình cũng đang nghiên cứu học Flask, bài viết bổ ích. Mong bạn chia sẽ thêm những bài viết hay.

@tienvv I greatly appreciate your comment (bow)

In this post, as i told in the beginning, it's just a translated article involved me for researching more about PHP.

• Which is the old version of PHP you mentioned in your comment? PHP 4? PHP 3?
• Please show me the point that i can not coverage the knowledge of PHP? Or give me some reference link help me research more about that.
• About self and static i didn't cover in this post? So what's the problem you want to say?

I also try to complete myself about knowledge, so if you have any information can share with me, please let me know to make other post better

template engine mình nghĩ nên dùng Twig, code có vẻ thân thiện hơn

Bài viết rất hay. Chờ bài viết sau của bạn. Thanks bạn

có thể dùng expressio luôn. vừa hỗ trợ web + websocket

Một series quá tuyệt vời! Tự hào là người theo hết từ đầu tới cuối (yeah3) Mong rằng sau này anh sẽ viết thêm nhiều bài về Laravel hơn nữa.

Sorry, mình đang dịch dở. Bấm nhầm Publish.