Làm thế nào để tránh một số lượng lớn các giao diện trong UI với nội xạ phụ thuộc?

Vấn đề
gần đây tôi đã đọc rất nhiều về Singletons là xấu và cách tiêm phụ thuộc (mà tôi hiểu là "sử dụng giao diện") là tốt hơn. Khi tôi thực hiện một phần của điều này với các cuộc gọi lại / giao diện / DI và tuân thủ nguyên tắc phân tách giao diện, tôi đã kết thúc với một mớ hỗn độn.

Sự phụ thuộc của cha mẹ UI trong đó về cơ bản là tất cả các phần tử con của nó kết hợp với nhau, do đó, phân cấp của một thành phần UI càng cao, thì hàm tạo của nó càng phình to hơn.

Tất cả các cách trên đỉnh của hệ thống phân cấp UI là một lớp Ứng dụng, giữ thông tin về lựa chọn hiện tại và tham chiếu đến mô hình 3d cần phản ánh các thay đổi. Lớp ứng dụng đã triển khai 8 giao diện và đây chỉ là một phần năm của các sản phẩm (/ giao diện) sắp ra mắt!

Tôi hiện đang làm việc với một singleton giữ lựa chọn hiện tại và các thành phần UI có chức năng tự cập nhật. Hàm này đánh lừa các thành phần cây UI và UI sau đó truy cập vào đĩa đơn lựa chọn hiện tại nếu cần. Mã này có vẻ sạch hơn đối với tôi theo cách này.

Câu hỏi
Là một singleton có thể thích hợp cho dự án này?
Nếu không, có một lỗ hổng cơ bản trong suy nghĩ của tôi và / hoặc việc thực hiện DI khiến nó trở nên cồng kềnh không?

Thông tin bổ sung về dự án
Loại: Giỏ mua sắm căn hộ, có chuông và còi
Kích thước: 2 tháng cho mã và
Bảo trì giao diện người dùng : Không chạy cập nhật, nhưng có thể "phiên bản 2.0" sau
Môi trường: Sử dụng C # trong Unity, sử dụng Thực thể Hệ thống thành phần

Trong hầu hết các trường hợp, tương tác người dùng kích hoạt một số hành động. Ví dụ: khi người dùng chọn một mục

phần UI hiển thị mục đó và mô tả của nó cần được cập nhật. Đối với điều này, nó cũng cần có được một số thông tin từ mô hình 3d để tính giá.
hơn nữa giao diện người dùng, tổng giá cần phải được cập nhật
một hàm tương ứng trong một lớp trên mô hình 3d cần được gọi để hiển thị các thay đổi ở đó

c# dependency-injection singleton

— R. Schmitz
nguồn

DI không chỉ là về việc sử dụng các giao diện, đó là khả năng trao đổi các bê tông hóa đặc biệt hữu ích trong phạm vi thử nghiệm đơn vị ...

— Robbie Dee

Ngoài ra, tôi vẫn chưa thấy một vấn đề trong đó singleton là giải pháp ưa thích. Ví dụ kinh điển mà mọi người dường như luôn nêu là một người viết nhật ký nhưng ngay cả ở đây bạn có thể muốn ghi vào một số nhật ký khác nhau (lỗi, gỡ lỗi, v.v.).

— Robbie Dee

@RobbieDee Vâng, DI nói về nhiều hơn, nhưng tôi không thể thấy tình huống sử dụng giao diện không phải là DI. Và nếu một singleton không phải là giải pháp ưa thích - mà tôi cũng giả định - thì tại sao giải pháp ưa thích lại quá lộn xộn? Đó là câu hỏi chính của tôi, nhưng tôi muốn giữ cho nó mở, vì đôi khi quy tắc chung không được áp dụng.

— R. Schmitz

Sự sắp xếp giao diện cũng là một tính năng của khung mô phỏng. Họ cũng đã sử dụng ngôn ngữ OO trong một vài thập kỷ qua ...

— Robbie Dee

Tôi không nhận được quan điểm của bạn.

— R. Schmitz

Câu trả lời:

Tôi nghĩ rằng câu hỏi là một triệu chứng, không phải là một giải pháp.

Gần đây tôi đã đọc rất nhiều về Singletons là xấu và cách tiêm phụ thuộc (mà tôi hiểu là "sử dụng giao diện") là tốt hơn. Khi tôi thực hiện một phần của điều này với các cuộc gọi lại / giao diện / DI và tuân thủ nguyên tắc phân tách giao diện, tôi đã kết thúc với một mớ hỗn độn.

Một giải pháp tìm kiếm một vấn đề; điều đó và hiểu lầm nó có thể làm hỏng thiết kế của bạn. Bạn đã đọc câu hỏi SO này về DI vs Singleton, các khái niệm khác nhau hay chưa? Tôi đọc nó chỉ đơn giản là gói một singleton để khách hàng không phải đối phó với một singleton. It.is.just.good.old.encapsulation. Tôi nghĩ đó là vị trí.

càng nhiều thứ bậc của một thành phần UI, thì hàm tạo của nó càng phình to hơn.

Xây dựng các bit nhỏ hơn trước sau đó chuyển chúng vào hàm tạo của vật mà chúng thuộc về và chuyển thứ lớn hơn đó vào hàm tạo của vật lớn hơn tiếp theo ...

Nếu bạn gặp sự cố xây dựng phức tạp, hãy sử dụng mẫu nhà máy hoặc nhà xây dựng. Điểm mấu chốt là việc xây dựng phức tạp được kéo vào lớp riêng để giữ cho các lớp khác gọn gàng, sạch sẽ, dễ hiểu, v.v.

Lớp ứng dụng đã triển khai 8 giao diện và đây chỉ là một phần năm của các sản phẩm (/ giao diện) sắp ra mắt!

Điều này nghe có vẻ như không có khả năng mở rộng. Thiết kế cốt lõi bị thiếu và mọi thứ đang được nhồi nhét từ trên xuống. Cần có thêm từ dưới lên xây dựng, thành phần, và kế thừa đang diễn ra.

Tôi tự hỏi nếu thiết kế của bạn là "nặng hàng đầu." Âm thanh như chúng ta đang cố gắng để làm cho một lớp là tất cả mọi thứ hoặc bất cứ điều gì nó có thể. Và thực tế rằng nó là một lớp UI, không phải là một lớp miền doanh nghiệp, điều đó thực sự khiến tôi băn khoăn về việc tách các mối quan tâm.

Xem lại thiết kế của bạn ngay từ đầu và chắc chắn rằng có một sự trừu tượng hóa sản phẩm cơ bản, vững chắc có thể được xây dựng để tạo ra các sản phẩm danh mục phức tạp hơn hoặc khác biệt hơn. Sau đó, tốt hơn bạn nên có các bộ sưu tập tùy chỉnh những thứ này để bạn có một nơi nào đó để đặt chức năng "cấp độ bộ sưu tập" - như "mô hình thứ 3" mà bạn đề cập.

... Mô hình 3d cần phản ánh những thay đổi.

Phần lớn điều này có thể phù hợp với các lớp thu thập tùy chỉnh. Nó cũng có thể là cấu trúc lớp độc lập với chính nó do độ sâu và độ phức tạp. Hai điều này không loại trừ lẫn nhau.

Đọc về mô hình khách truy cập. Đó là ý tưởng về việc có toàn bộ các chức năng được kết nối trừu tượng với các loại khác nhau.

Thiết kế và DI

90% của tất cả các phép tiêm phụ thuộc mà bạn sẽ làm là truyền tham số constructor. Vì vậy, quy người đã viết cuốn sách . Thiết kế các lớp học của bạn tốt và tránh gây ô nhiễm quá trình suy nghĩ đó với một số khái niệm mơ hồ về việc cần phải sử dụng một thùng chứa DI. Nếu bạn cần nó, thiết kế của bạn sẽ gợi ý cho bạn để nói.

Tập trung vào mô hình miền mua sắm căn hộ.

Tránh cách tiếp cận của Jessica Simpson để thiết kế : "Tôi hoàn toàn không biết điều đó có nghĩa là gì, nhưng tôi muốn nó."

Sau đây là sai:

Tôi phải sử dụng giao diện
Tôi không nên sử dụng một singleton
Tôi cần DI (bất kể đó là gì)
Tôi phải sử dụng thành phần, không phải thừa kế
Tôi phải tránh kế thừa
Tôi cần sử dụng các mẫu

— radarbob
nguồn

Tôi đã cố gắng loại bỏ tất cả các singletons tôi đã sử dụng và một số điều bạn nói đã xảy ra ít nhiều tự động. Phần còn lại cũng rất có ý nghĩa và tôi sẽ lấy lời khuyên của bạn và đọc về mẫu khách truy cập, v.v ... Tất cả trong một câu trả lời được viết tốt, cảm ơn bạn!

— R. Schmitz

Chỉ cần một điểm, và tôi không cố gắng để là một trợ giúp ma cà rồng ở đây, nhưng nó là loại một phần của câu hỏi ban đầu: Sự đồng thuận chung (và nó được dựa trên lý do chính đáng) có vẻ là rằng bạn đang thực sự không được phép sử dụng một đơn Bạn viết "'Tôi không được phép sử dụng một singleton' là sai" - trong trường hợp nào thì nó sẽ phù hợp để sử dụng nó?

— R. Schmitz

Tất cả tôi đang nói là, "nó phụ thuộc." Tôi thường thấy câu châm ngôn được thực hiện theo đúng nghĩa đen.

— radarbob

"Gia truyền đẳng cấp" là một chút cờ đỏ. Giả thuyết: một trang web với 5 widget. Trang này không phải là tổ tiên của bất kỳ vật dụng nào. Nó có thể giữ một tham chiếu đến các vật dụng. Nhưng nó không phải là tổ tiên. Thay vì bá quyền giai cấp, hãy xem xét sử dụng thành phần. Mỗi trong số 5 widget có thể được xây dựng riêng mà không cần tham khảo các widget khác hoặc trang trên cùng. Trang đầu sau đó được xây dựng với đủ thông tin để xây dựng một trang cơ bản và bố trí các đối tượng widget (Bộ sưu tập) được truyền cho nó. Trang chịu trách nhiệm về bố cục, v.v., nhưng không phải về cấu trúc và logic của các widget.

Một khi bạn sử dụng thành phần, DI là người bạn tốt nhất của bạn. DI cho phép bạn trao đổi từng widget cho bất kỳ phiên bản hoặc loại widget nào bạn xác định trong DI. Xây dựng các vật dụng được chụp trong DI và tách biệt với trang trên cùng. Có lẽ ngay cả thành phần của Bộ sưu tập cũng có thể được định nghĩa trong DI của bạn. Trang trên cùng thực hiện bố cục dựa trên các vật dụng được truyền cho nó. Không có thay đổi đối với các nhà xây dựng trang hàng đầu cần thiết. Trang đầu chỉ cần logic để thực hiện bố trí các widget và truyền thông tin đến / từ widget dựa trên các giao diện đã xác định.

Thay vì chuyển người nghe lên xuống chuỗi sáng tác, hãy đưa một bộ sưu tập người nghe vào những vật dụng cần nó. Tiêm bộ sưu tập vào một nhà xuất bản để họ có thể xuất bản vào bộ sưu tập. Tiêm bộ sưu tập vào người nghe để họ có thể tự thêm vào bộ sưu tập. Bộ sưu tập cắt ngang tất cả các đối tượng trong chuỗi thành phần.

— bọ cạp
nguồn

Xin lỗi, "hệ thống phân cấp lớp" đã sai từ ngữ ở đây; nó thực sự không phải là hệ thống phân cấp lớp, mà là hệ thống phân cấp UI. Các 'widget' không phải là các lớp con của lớp ứng dụng, nhưng 'trang' chứa các tham chiếu đến chúng để xuất bản các cập nhật UI. Nó rất có thể thử nghiệm với cấu trúc này, nhưng cũng có rất nhiều chi phí đặc biệt là trong các nhà xây dựng, chỉ truyền lại rất nhiều người nghe cho con cái (UI) của họ.

— R. Schmitz

@ R.Schmitz: Có phải vấn đề trên không? Giao diện người dùng có chậm chạp không, và có phải là thiết kế mà bạn mô tả để đổ lỗi?

— Robert Harvey

@ R.Schmitz Bạn có thể nói rõ hơn về "truyền nhiều người nghe" không? Có thể trải nghiệm của tôi với DI trong C # là thấp, nhưng một cái gì đó cho tôi biết rằng sẽ không cần thiết (ít nhất là trong nhà xây dựng) với thiết kế phù hợp.

— Katana314

@RobertHarvey Không mất hiệu năng, nó chỉ là về khả năng đọc.

— R. Schmitz

@ Katana314 Ví dụ: khi một mục được thêm vào, 3dmodel cần được cập nhật và nó không thuộc bất kỳ danh mục sản phẩm nào, do đó, nó được tham chiếu trong lớp ứng dụng, trong đó lắng nghe các mục được thêm / xóa / thay đổi. Cuối cùng, điều đó sẽ khá giống nhau cho mọi loại sản phẩm. Các phần UI khác cũng phản ứng (và lắng nghe), nhưng thông báo cần phải di chuyển lên đầu vì đó là nơi tham chiếu 3dmodel và dữ liệu thực tế (sau đó cũng được cập nhật).

— R. Schmitz