Tại sao nên tránh hình thức thừa kế?

Tôi nhớ việc học VB4 và kéo một nút vào một biểu mẫu, nhấp đúp vào nút đó và nhập mã vào trình xử lý sự kiện mà tôi vừa được ban phước một cách kỳ diệu. Đến từ QBASIC, tôi đã rất phấn khích với chữ "V" trong "VB", nhà thiết kế hình ảnh thực sự là điều tuyệt vời nhất kể từ khi cắt lát bánh mì.

Tất nhiên bạn có thể làm tất cả những điều đó theo lập trình nhưng phép thuật của chữ "V" rất hấp dẫn, bạn không thể không kéo nút đó. Chúng tôi được khuyến khích đi theo con đường đó.

Nhưng sau đó vài năm, tôi bắt đầu tìm hiểu về C # và khung .net và bị mê hoặc bởi cách mọi thứ tôi nghĩ tôi biết vừa mới ra khỏi cửa sổ. Có rất nhiều phép thuật đang diễn ra trong VB6, điều đó hoàn toàn được tiết lộ trong .net: lấy các hàm tạo và InitializeComponentsphương thức làm ví dụ. Sau này, bạn sẽ tìm thấy tất cả các phiên bản điều khiển mà bạn đã kéo từ hộp công cụ, tất cả các sự kiện bạn đã đăng ký và các thuộc tính bạn đã đặt trong trình thiết kế.

Và nó ổn ... tôi đoán thế. Chỉ là, tôi cảm thấy như mình không "sở hữu" những gì đang diễn ra, mã này mà tôi chỉ có thể sửa đổi thông qua nhà thiết kế làm phiền tôi. Mỗi khi bạn sao chép một nút có chữ "Ok" từ dạng này sang dạng khác (đôi khi cùng với anh trai của nó là "Hủy"), bạn thực sự đang sao chép mã, và đó có phải là một tội lỗi không? DRY, đừng lặp lại chính mình, Giáo hoàng nói .

Các tôn giáo và trường phái tư tưởng sang một bên, trong tất cả các khách quan, chúng ta không nên lấy các hình thức từ các hình thức cơ sở thay vào đó và có nút "Ok" (và tất cả bạn bè của nó) sống ở dạng cơ sở? Một cái gì đó giống như FormBasetừ đó xuất phát a DialogFormBase; tất cả các lớp được tạo trong thời gian ngắn ... bằng cách gõ mã. Các nút được tạo tùy thuộc vào cách lớp được tạo ra (ví dụ: đối số enum của hàm tạo xác định nút nào sẽ được tạo), các điều khiển được đặt bên trong một sự sắp xếp của các bảng phân chia và bảng bố trí luồng, được đưa vào biểu mẫu nhưContentphù hợp với bảng nội dung chính. Đây không phải là những gì ASP.net làm với các trang chính và giữ chỗ nội dung? Tôi đã lấy được một biểu mẫu khi tôi cần một "trang chính" mới, nhưng "trang chính" mới này vẫn xuất phát từ một lớp biểu mẫu cơ sở để hình ảnh nhất quán trên toàn bộ ứng dụng.

Đối với tôi đó là nhiều tái sử dụng mã hơn bất cứ thứ gì khác mà tôi từng thực hiện với các nhà thiết kế trong WinForms, và nó thậm chí còn không chăm chỉ, và mã không lộn xộn với một phương pháp 200 dòng mà tôi không kiểm soát được, tôi có thể Đặt bình luận ở nơi tôi thích, họ sẽ không bị ghi đè bởi nhà thiết kế. Tôi đoán đó chỉ là vấn đề về hoa văn và kiến ​​trúc, đó là điều đã đưa tôi đến liên kết này: Thiết kế tốt nhất cho các biểu mẫu Windows sẽ chia sẻ chức năng chung , nơi tôi nhận ra mình đã phát hiện ra, ngoại trừ câu trả lời ở đó, gợi ý chính xác những gì tôi làm, nhưng nó khuyên chống lại sự kế thừa hình thức vì những cân nhắc của nhà thiết kế. Đó là phần tôi không nhận được .bởi vì các cân nhắc về cấu trúc mã, đặc biệt là liên quan đến kế thừa hình thức và kiểm soát, mà tôi thấy không có lý do gì để tránh ngoài việc nó phá vỡ nhà thiết kế .

Tất cả chúng ta không thể lười biếng, vậy tôi còn thiếu phần nào?

Tôi sẽ phản đối bạn với mô hình khác nhau: Thành phần ủng hộ kế thừa.

Ngay cả khi bạn bắt đầu viết mã GUI bằng tay và sử dụng tính kế thừa để chia sẻ hành vi và hình ảnh giữa các biểu mẫu, bạn sẽ gặp vấn đề tương tự như thiết kế OOP bình thường. Hãy nói rằng bạn có DialogForm, có các nút OK / Hủy và GridForm, có lưới. Bạn lấy được tất cả các hộp thoại từ DialogForm và tất cả các biểu mẫu với Grid từ GridForm. Và sau đó bạn tìm ra bạn muốn hình thức với cả hai. Làm thế nào bạn sẽ giải quyết nó? Nếu bạn đang sử dụng kế thừa biểu mẫu, thì không có cách nào giải quyết nó. Mặt khác, nếu bạn đang sử dụng UserControls, thì bạn chỉ cần đặt GridControl vào biểu mẫu của mình và thực hiện với nó. Và bạn vẫn có thể sử dụng trình thiết kế với UserControls, vì vậy bạn không phải lãng phí thời gian để viết mã GUI tẻ nhạt.

Phần lớn trong số này được gắn với ngăn xếp công nghệ lựa chọn.

WinForms và WPF đều có thể là các khung .NET UI nhưng khác nhau rất nhiều về cách bạn đạt được mục tiêu cuối cùng. Một số mô hình nhất định di chuyển giữa các công nghệ tốt nhưng những mô hình khác thì không và bạn không nên cố gắng tạo ra một mô hình đơn giản chỉ vì bạn cảm thấy nó tồn tại trong mọi khuôn khổ. Có một lý do mà MVVM hướng đến WPF / SL và MVC là một khái niệm riêng biệt trong ASP.NET từ WebForms, v.v. Một số công nghệ làm việc tốt hơn với các mô hình nhất định.

Hãy nhớ rằng mã được tạo thường phải được loại bỏ khỏi mối quan tâm DRY của bạn. Trong khi áp dụng trong một số trường hợp, thường xuyên hơn không nên bỏ qua. Các khái niệm DRY chắc chắn vẫn là một trọng tâm bên ngoài lớp Trình bày của bạn nhưng ở lớp Trình bày, mã được tạo thường xuyên hơn không phải là sản phẩm phụ của khung bạn đang làm việc. Điều này không có nghĩa là bạn không thể áp dụng các nguyên tắc DRY trong cách tiếp cận của mình. dè dặt. Bạn có thể tạo một Mẫu cơ sở và kế thừa từ nó vô thời hạn không? Đúng. Bạn có thể kéo và thả các thành phần trên Biểu mẫu mới mỗi lần khi cần không? Đúng. Hãy tập trung vào mục tiêu cuối cùng, tránh các khiếm khuyết tiềm ẩn, giúp dễ dàng cấu trúc lại hạ lưu và khả năng mở rộng trong khi làm việc trong giới hạn của nhóm công nghệ lựa chọn.

Bạn có thể sử dụng tính kế thừa cung cấp cho bạn đóng gói chính xác các trường của bạn và điền vào tương ứng. Nếu bạn muốn sử dụng tính kế thừa, đề xuất của tôi sẽ là có biểu mẫu cơ sở và Mô hình tương ứng cho biểu mẫu đó và cho mỗi đạo hàm xuất phát cả biểu mẫu và Mô hình.

Một sự thay thế tốt hơn nhiều sẽ là nhóm các điều khiển liên quan thành một hoặc nhiều điều khiển UserControl. Bạn chỉ cần một chút logic để đưa dữ liệu liên quan vào đó.

Tôi hoàn toàn đồng ý với Mason Wheeler, mặc dù trong ba năm, có lẽ chính anh ta cũng đã thay đổi quyết định.

Tôi đang cố gắng tìm kiếm các lựa chọn thay thế để di chuyển từ các tệp thực thi Delphi sang WEB.

Cho đến bây giờ tôi đã quyết định cho UNIGUI, bởi vì tôi vẫn có thể sử dụng hình thức thừa kế. Tôi muốn Delphi có Mixins như Dart, vì nó sẽ cho phép tôi có ít tổ tiên hơn. Nhưng tôi cảm thấy mọi người viết mã nhiều hơn trong MVC so với Visual Form thừa kế, vì hầu hết các điều hướng, gọi đến các quy tắc xác thực trong cơ sở dữ liệu (áp dụng), tiêu chí lọc sql, tìm kiếm tập dữ liệu khách hàng, mọi thứ được viết trong 5 có thể 6 Hình thành tổ tiên.

Ngay cả "Với MVC, bạn sẽ dễ dàng để Delphi trong Tính năng" hơn đối với tôi, vì Don dont hoạt động như một đối số, vì mọi người đã mời OOP, mọi thứ đều là các lớp, thuộc tính, phương thức. Vì vậy, tất cả những gì tôi cần là một dịch giả. Thực sự không thể tìm thấy bất kỳ lợi thế nào, có thể đối với các trang web ít phức tạp hơn nhưng thay đổi trong cơ sở hàng ngày.