Làm thế nào để giải thích cho ai đó rằng một cấu trúc dữ liệu không nên tự vẽ, giải thích sự tách biệt các mối quan tâm?

Question

Tôi có một lập trình viên khác, tôi đang cố giải thích tại sao thành phần giao diện người dùng cũng không phải là cấu trúc dữ liệu. Ví dụ:

Ví dụ: giả sử bạn nhận cấu trúc dữ liệu chứa tập bản ghi từ "cơ sở dữ liệu" và bạn muốn hiển thị bộ bản ghi đó trong thành phần giao diện người dùng trong ứng dụng của mình.

Theo lập trình viên này (người sẽ vẫn không tên, anh ấy trẻ và tôi đang dạy anh ấy ...), chúng ta nên phân lớp cấu trúc dữ liệu thành lớp sẽ vẽ thành phần giao diện người dùng trong ứng dụng của chúng tôi !!!! !!

Và do đó theo logic này, bộ bản ghi phải quản lý bản vẽ giao diện người dùng.

****** Trưởng Bàn *****

Tôi biết rằng yêu cầu một kỷ lục thiết lập để vẽ chính nó là sai, bởi vì, nếu bạn muốn làm cho cùng một cấu trúc dữ liệu trên hơn một loại thành phần trên giao diện người dùng của bạn, bạn sẽ có một mớ hỗn độn thực sự trên tay của bạn; bạn sẽ cần mở rộng thêm một lớp khác cho mỗi thành phần UI mà bạn render từ lớp cơ sở của tập bản ghi của bạn;

Tôi biết rõ về "độ sạch" của mẫu MVC (và điều đó thực sự có nghĩa là bạn không nhầm lẫn dữ liệu của mình (Mô hình) với giao diện người dùng (chế độ xem) hoặc hành động diễn ra trên dữ liệu (Bộ điều khiển nhiều hơn hoặc ít hơn ... không thực sự là API thực sự xử lý điều đó ... và Bộ điều khiển chỉ nên thực hiện một vài cuộc gọi đến nó vì nó có thể, cho biết chế độ xem nào sẽ hiển thị)) Nhưng nó chắc chắn rất nhiều sạch hơn so với sử dụng cấu trúc dữ liệu để hiển thị các thành phần giao diện người dùng!

Có lời khuyên nào khác mà tôi có thể gửi theo cách khác với ví dụ trên không? Tôi hiểu rằng khi bạn lần đầu tiên học OOP bạn đi qua "một sân khấu", nơi bạn chỉ muốn mở rộng mọi thứ.

Tiếp theo là một giai đoạn khi bạn cho rằng Mẫu thiết kế là giải pháp cho mỗi vấn đề duy nhất ... không hoàn toàn chính xác ... thanks Jeff.

Có cách nào để tôi có thể nhẹ nhàng di chuyển đứa trẻ này đi đúng hướng không? Bạn có thêm bất kỳ ví dụ nào có thể giúp giải thích quan điểm của tôi với anh ấy không?

Answer 1

Bạn đã nghe nói về Martin Fowler chưa?

Separating User Interface Code

Dù sao, nếu anh muốn đi xa hơn theo hướng đó thêm làm phương pháp để kiểm soát dữ liệu của mình, có anh ta nhìn vào "khớp nối lỏng lẻo". Bạn có thể tạo một số kiểu giao diện chung để đưa anh ta nửa chừng ở đó, nhưng thành phần giao diện người dùng nên dùng phần còn lại của đường đi.

Answer 2

Điều này phù hợp với trách nhiệm chức năng và phi chức năng. Cấu trúc dữ liệu làm gì và cách nó được hiển thị trực quan là hai điều hoàn toàn riêng biệt - về cơ bản là gốc của mẫu MVC.

Ngoài ra còn có khái niệm về phụ thuộc vòng tròn tại đây. Vì giao diện người dùng phải biết về cấu trúc dữ liệu, nếu bạn cho phép các cấu trúc dữ liệu sau đó phụ thuộc vào giao diện người dùng, bạn đã có cho mình một quả bóng nhỏ đẹp của bùn.

Answer 3

chung về quan điểm tách:

1. Không chỉ có thể có các thành phần khác nhau của giao diện người dùng vẽ các cấu trúc dữ liệu tương tự. Bạn thậm chí có thể có các giao diện người dùng hoàn toàn khác nhau (Web, Ứng dụng Desktop, ...) Bây giờ tất nhiên, bạn có thể phân lớp Person với WebPerson và DesktopPerson(điều này nghe có vẻ sai, phải không? Người - đó là về cái gì khác).

2. Mỗi giao diện người dùng có thể hoạt động trên các loại người khác nhau, ví dụ: Teacher và Student. Vì vậy, chúng tôi nhận được WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher và DesktopStudent.

Bây giờ giả sử phương thức "drawAddressFields()" để vẽ phiên bản web của trường địa chỉ. Nhưng kể từ khi WebTeacher phải lấy được từ Teacher để sử dụng trường dữ liệu bổ sung "tiền lương" (và giả sử thừa kế đơn), nó phải thực hiện "drawAddressFields()" một lần nữa!

Vì vậy, có lẽ lập luận của "này sẽ gây ra nhiều công việc hơn" sẽ giúp tạo ra một số động lực :-)

BTW, nó sẽ tự động dẫn đến việc tạo ra một số đại biểu mà thực hiện các quy tắc ứng drawAddressField(), mà sau đó sẽ phát triển để tạo ra một thành phần thực hiện bản vẽ tách biệt với cấu trúc dữ liệu.