Mọi người thử AZGram nhé. chat. gọi điện, gọi video, gọi tới số điện thoại. http://www.azgram.com/download/

Mình build bị lỗi này bạn giúp mình với ..Thanks!

lần sau anh có thể giải thích qua mấy cái định nghĩa . ví dụ ở cái giải thích uv ấy anh nói qua nó là gì rồi đưa link chi tiết chứ em đọc đang máu thì lại phải quay ra tìm hiểu uv nó là cái gì .

love u

@pham ky khoi Thanks

STL có phải là standard template library phải ko ạ, standard library của C++ phải ko ạ

@helix

Bạn có thể nói rõ hơn ví dụ của mình có điểm nào chưa đúng nhỉ?

Tham khảo UML từ wiki:

Như vậy ở ví dụ của mình Human sẽ đóng vai trò là Element, method hit đóng vai trò như accept.

Từ đó, ConcreteElement sẽ gồm có Warrior, Wizzard

Visitor trong ví dụ này sẽ làMonster, interface này cần có các method visit tương ứng với từng ConcereteElement, chính là các method hitBy đó vậy

Bạn hãy kiểm tra xem bạn có load đống ảnh kia trên main thread ko nhé, nếu là trên main thì cần phải để nó dưới backgroud, các tiến trình không cập nhật UI mà để trên main sẽ lock thao tác sử dụng, hãy cẩn thận vấn đề này.

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.