Bất kỳ ai sử dụng Qi4J

Question

tôi đã được đọc một bài báo InfoQ trên composite Lập trình hướng trước đây về:

http://www.infoq.com/articles/Composite-Programming-Qi4j

tôi đã quan tâm đến việc tìm hiểu xem ai đang sử dụng (hoặc đã được sử dụng) khuôn khổ Qi4j ở tất cả?

Làm cách nào để so sánh với việc sử dụng khuôn khổ tiêm phụ thuộc truyền thống như Spring cho các lớp kết nối với nhau. Là đồ thị đối tượng kết quả (dựa trên mixins chứ không phải là các lớp học) dễ dàng hơn để đối phó với từ một quan điểm bảo trì?

Answer 1

Vâng, tôi đã sử dụng Qi4j bản thân mình trong khoảng một năm nay trong một dự án. Một khi bạn quen với sức mạnh của mixin trong mô hình miền của mình, bạn sẽ tự hỏi bạn đã từng quản lý như thế nào mà không có chúng trước đây. Trong thực tế, tôi nghĩ rằng phương pháp POJO tạo các mô hình miền nên lỗi thời. Nó tạo ra mã không thể duy trì một cách hệ thống. Bởi vì mô hình mixin/composite là tính năng quan trọng của Qi4j, chứ không phải DI, thực sự không có bất kỳ so sánh nào trên nền tảng Java.

Đối với mối quan tâm của Bozho: khi nói đến tuyên bố mixins có hai trường hợp riêng biệt. Trong các thực thể, tức là mô hình miền, một giao diện thường sẽ chỉ có một triển khai thực hiện và bạn thực sự muốn chủ động tránh việc triển khai một số lý do bảo trì và khả năng đọc. Vì vậy, tôi tuyên bố thực hiện ngay trong giao diện. Tuy nhiên, nó chỉ là một mặc định, có thể được overriden bởi composite nếu bạn muốn. Tôi đã không bao giờ tìm thấy một nhu cầu để làm như vậy.

Trường hợp khác là dịch vụ, điều này hoàn toàn khác. Đối với nhiều trường hợp sẽ chỉ có một thực hiện, và do đó tuyên bố việc thực hiện trong giao diện là một lần nữa khá ok. Tuy nhiên, có nhiều trường hợp hơn với các dịch vụ mà bạn muốn triển khai khác nhau, và vì vậy đối với những trường hợp đó, bạn chỉ cần khai báo mixin trong khai báo kiểu kết hợp bê tông thay thế. Vì vậy, cả hai kiểu đều có thể và được khuyến nghị vì nhiều lý do khác nhau.

Đối với tính năng truyền, có thể truyền một đối tượng là tiền thưởng, không phải là vấn đề. Nếu bạn không có đúc từ một vai trò đến vai trò khác, bạn sẽ phải khá sáng tạo để có được xung quanh nó, mà có lẽ sẽ không làm cho mã của bạn đơn giản hơn.

Answer 2

Sau khi đọc phần đầu của bài viết liên quan, tôi không thích hai điều:

• triển khai được định nghĩa trong giao diện (sử dụng @Mixins) - những gì nếu những nên chế giễu, hoặc triển khai thay đổi ?
• đòi hỏi đúc

Không có kinh nghiệm với Qi4J, tôi không thể nói như thế nào điều này hóa ra trong thực tế, nhưng nó không cảm thấy tốt.

Answer 3

Hy vọng rằng không quá muộn về cuộc thảo luận này: Nhưng đây là cách tôi nhìn thấy nó.

Trước hết tôi thích các ý tưởng (Composites, Mixins, Assemblies) phía sau Qi4j nhưng bị giữ lại bởi sự phức tạp của việc sử dụng nó.

Các khái niệm nên là một phần của ô rộng hơn như ngôn ngữ (chẳng hạn như Java) so với khung công tác và phải dễ sử dụng hơn.

Tôi gặp phải vấn đề 2 năm trước khiến tôi ước gì mình có thứ gì đó như thế.

Tôi muốn có 3 hành vi khác nhau có thể được sử dụng lại trên một nhóm đậu. Một số hạt cà phê sử dụng tất cả những người khác bất kỳ sự kết hợp của hai. Tôi không muốn đặt tất cả chúng lại với nhau trong một lớp bởi vì nó không có ý nghĩa. Mặt khác, tôi đã bị ràng buộc bởi thực tế là tôi không thể có nhiều thừa kế. Giải pháp hiển nhiên: sử dụng giao diện; có nghĩa là thực hiện điều đó nhiều lần. Tôi nhớ đã phàn nàn với một đồng nghiệp về thực tế là tôi hy vọng tôi có cách cung cấp triển khai mặc định cho một giao diện. Điều này với tôi là một khái niệm OO đơn giản cho phép người ta sử dụng lại các hành vi theo một cách rõ ràng hơn. Và nếu nó là trường hợp bạn cần một cái gì đó khác với việc thực hiện mặc định hơn là thực hiện một. Điều đó sẽ có ý nghĩa hơn và sẽ không phanh bất kỳ luật tự nhiên nào mà tôi có thể thấy.

Vì vậy, để trả lời câu hỏi của bạn, tôi nghĩ khái niệm của Qi4j cho phép bạn suy nghĩ OO trong thời trang sạch hơn, nơi Spring có cấu trúc và thậm chí không thể so sánh về mặt khái niệm. Bạn có thể suy nghĩ tiêm phụ thuộc và không được suy nghĩ mùa xuân và được suy nghĩ Qi4j và không được suy nghĩ tiêm chích.

Answer 4

Khi tôi đọc qua Qi4j trong 2 phút, 10 phút vv hướng dẫn (câu cuối cùng chưa hoàn thành), một câu hỏi rõ ràng mà tôi nghĩ đến là làm cách nào để tích hợp điều này với các thực thể được quản lý JPA/Hibernate? Tôi muốn thấy một giải pháp tích hợp liền mạch với JPA. Không có JPA ngụ ý không có sự chấp nhận Qi4j theo ý kiến ​​của tôi. Tôi rất muốn thấy một bài báo của tác giả cho thấy sự tích hợp với JPA và Spring, hai thứ có sự thâm nhập sâu trong thế giới Java Enterprise. Nếu sự tích hợp là đơn giản, việc áp dụng nhanh sẽ theo sau.

Answer 5

Bozho; Đối với bạn câu hỏi về Mixins được khai báo trên giao diện,

Việc triển khai Mixin có thể được ghi đè, hoặc trong giao diện "cao hơn" (nghĩa là phụ), như lệnh tìm kiếm để thực hiện "trên mỗi phương thức" và đi từ giao diện được khai báo , từ trái qua phải, và sau đó đến từng giao diện siêu (cũng từ trái sang phải trong mệnh đề mở rộng). HOẶC, bạn có thể ghi đè trong Assembly of a composite;

public void assemble(ModuleAssembly module) 
{ 
    module.entities(Account.class).withMixins(LdapAuthenticatorMixin.class); 
    : 
} 

nơi LdapAuthenticatorMixin có thể trừu tượng và chỉ ghi đè lên một phương pháp duy nhất.

Answer 6

Kabram; Tích hợp với JPA đã được thử nhiều lần. Nếu chúng ta có hai công nghệ chồng chéo nhưng không hoàn toàn có thể kết hợp, bạn sẽ chỉ kết thúc với giao điểm của các khả năng. Vì vậy, có hai cách tiếp cận cơ bản để tích hợp Qi4j với JPA.

1. Để giới hạn tùy chọn JPA, sao cho cấu trúc dữ liệu linh hoạt hơn mà Qi4j cần có thể được sử dụng đầy đủ. Làm điều đó không có ý nghĩa gì, vì việc truy cập trực tiếp vào SQL có hiệu quả hơn nhiều, và đó là những gì chúng tôi đã chọn.

2. Để hạn chế mô hình dữ liệu của Qi4j để phù hợp với mô hình dữ liệu JPA hiện có. Làm điều này sẽ lấy đi hầu hết những ưu điểm của việc tại sao mọi người chọn Qi4j ngay từ đầu. Chúng tôi đã quyết định không dành thời gian để thực hiện việc này. Tuy nhiên, tôi nghĩ rằng khả năng mở rộng của Qi4j là đủ tốt để thực hiện tích hợp như vậy mà không cần hack trong Core Runtime, và đơn giản là tạo ra một EntityStore.