Mengapa warisan harus dihindari?


9

Saya ingat belajar VB4 dan menyeret tombol ke formulir, mengklik dua kali pada tombol itu, dan mengetik kode ke event handler yang baru saja diberkati secara ajaib. Berasal dari QBASIC saya sangat senang dengan "V" dalam "VB", desainer visual secara harfiah adalah yang terbaik sejak memotong roti.

Tentu saja Anda bisa melakukan semua itu secara terprogram tetapi keajaiban "V" begitu menarik sehingga Anda tidak bisa menahan tombol itu. Kami didorong untuk mengambil rute itu.

Tapi kemudian beberapa tahun yang lalu saya mulai belajar tentang C # dan kerangka kerja. Net dan terpesona oleh cara semua yang saya tahu saya baru saja keluar dari jendela. Ada banyak keajaiban yang terjadi di VB6 yang sepenuhnya diluncurkan di .net: ambil konstruktor dan InitializeComponentsmetode misalnya. Dalam yang terakhir Anda akan menemukan semua contoh kontrol yang Anda seret dari kotak alat, semua acara yang Anda daftarkan dan properti yang Anda atur di perancang.

Dan itu tidak masalah ... kurasa. Hanya saja, saya merasa seperti tidak "memiliki" apa yang terjadi, kode ini yang hanya dapat saya modifikasi melalui perancang mengganggu saya. Setiap kali Anda menyalin tombol yang mengatakan "Oke" dari satu formulir ke yang lain (kadang-kadang bersama dengan saudaranya "Batal"), Anda benar-benar menggandakan kode, dan itu dosa bukan? KERING, jangan ulangi dirimu, kata Paus .

Agama dan aliran pemikiran di samping, dalam semua obyektivitas, bukankah seharusnya kita mengambil bentuk dari bentuk dasar sebagai gantinya, dan apakah tombol "Oke" (dan semua teman-temannya) tinggal di formulir dasar? Sesuatu seperti FormBasedari mana berasal DialogFormBase; semua kelas dibuat dalam waktu singkat ... dengan mengetikkan kode. Tombol-tombol dibuat tergantung pada bagaimana kelas di-instanciated (yaitu argumen konstruktor enum menentukan tombol mana yang akan dibuat), kontrol diletakkan di dalam susunan panel split dan panel tata letak aliran, disuntikkan ke dalam bentuk sebagaiContentyang cocok dengan panel konten utama. Bukankah ini yang ASP.net lakukan dengan halaman master dan placeholder konten? Saya akan mendapatkan formulir ketika saya membutuhkan "halaman master" baru, tetapi "halaman master" baru ini masih berasal dari kelas bentuk dasar sehingga visual konsisten di seluruh aplikasi.

Bagi saya itu lebih banyak menggunakan kembali kode daripada apa pun yang pernah saya lakukan dengan desainer di WinForms, dan itu bahkan tidak sulit, dan kode tidak berantakan dengan metode 200-baris yang saya tidak punya kendali atas, saya bisa letakkan komentar di tempat yang saya suka, mereka tidak akan ditimpa oleh seorang desainer. Saya kira itu hanya masalah pola dan arsitektur, yang membawa saya ke tautan ini: Desain terbaik untuk bentuk Windows yang akan berbagi fungsionalitas umum , di mana saya menyadari saya sangat tepat, kecuali jawaban di sana, menunjukkan dengan tepat apa yang saya lakukan, tapi itu menyarankan terhadap warisan bentuk karena pertimbangan desainer. Itu bagian yang tidak saya dapatkan .karena pertimbangan struktur kode, terutama dalam hal bentuk dan kontrol warisan, yang saya lihat tidak ada alasan untuk menghindari selain itu merusak perancang .

Kita semua tidak bisa hanya malas, jadi bagian apa yang saya lewatkan?


Saya tidak mengerti. Apakah Anda menyiratkan bahwa kita tidak boleh menggunakan desainer visual dan menulis semua kode GUI dengan tangan?
Euforia

Pra .NET di mana kode yang mengontrol semua objek diseret pada formulir?
JeffO

1
@ Jeff menilai dari kode warisan saya telah berurusan dengan, saya akan mengatakan tepat pada formulir, di suatu tempat antara ad-hoc inline SQL dan logika bisnis. Intinya adalah, WinForms adalah .net; jadi jika desainer bekerja dengan baik dengan apa yang sekarang berbau seperti "kode buruk" dan "kebiasaan pengkodean yang buruk" dan benar-benar rusak ketika Anda mulai menyusun hal-hal, saya katakan jatuhkan desainer dan perlakukan bentuk seperti apa adanya (kelas!) .. dan bagaimana cara pengkodean lapisan UI di C # begitu berbeda dari pengkodean lapisan UI di ExtJS? Itu "membosankan" untuk melakukan itu di WinForms karena "hei lihat ada desainer"? Apakah pengkodean UI ExtJS membosankan?
Mathieu Guindon

Saya akan mengutip pengguna lain: CodeCaster; Pengatur kejadian dimaksudkan untuk menghubungkan GUI ke logika bisnis Anda. Jika Anda memiliki kotak teks untuk memasukkan nama pengguna dan tombol Tambah, mengklik tombol Tambah hanya harus memanggil _userRepository.AddUser (UsernameTextbox.Text). Anda tidak ingin logika bisnis di penangan acara. stackoverflow.com/questions/8048196/…
Pieter B

@Pieter tidakkah itu menempatkan ketergantungan DAL ke dalam lapisan presentasi Anda?
Mathieu Guindon

Jawaban:


9

Saya akan menentang Anda dengan paradigma yang berbeda: Komposisi nikmat daripada warisan.

Bahkan ketika Anda mulai menulis kode GUI dengan tangan dan menggunakan warisan untuk berbagi perilaku dan visual antar formulir, Anda akan mendapatkan masalah yang sama dengan desain OOP normal. Katakanlah Anda memiliki DialogForm, yang memiliki tombol OK / Batal dan GridForm, yang memiliki kisi. Anda memperoleh semua dialog dari DialogForm dan semua formulir dengan Grid dari GridForm. Dan kemudian Anda mengetahui bahwa Anda menginginkan formulir dengan keduanya. Bagaimana Anda mengatasinya? Jika Anda menggunakan pewarisan formulir, maka tidak ada cara menyelesaikannya. Di sisi lain, jika Anda menggunakan UserControls, maka Anda cukup meletakkan GridControl di formulir Anda dan selesai dengan itu. Dan Anda masih dapat menggunakan perancang dengan UserControls, sehingga Anda tidak perlu membuang waktu untuk menulis kode GUI yang membosankan.


Yah bentuk dasar hanya memiliki SplitContainer dengan Panel2 diperbaiki, berisi FlowLayoutPanel dipanggil BottomPaneldan hosting perilaku Ok / Batal / Terapkan / Tutup yang umum; Panel1 berisi SplitContainer dengan Panel1 diperbaiki (untuk meng-host label "instruksi" umum, atau menu, toolbar, apa pun yang terjadi di atas) dan Panel2 memegang Panel yang dilindungi disebut MainContent; setiap implementasi aktual memutuskan bagaimana mengisinya. Semua konten dapat disuntikkan ke dalam implementasi dan ya, ini bisa menjadi kontrol pengguna yang dibuat dengan perancang untuk menghemat waktu, poin bagus .. tapi bagaimana dengan formulir itu sendiri?
Mathieu Guindon

Masalahnya di sini adalah skala. Ketika Anda mengambil aplikasi dengan 10 formulir, maka memiliki formulir umum tunggal bukanlah masalah besar. Masalahnya dimulai ketika Anda memiliki aplikasi dengan puluhan atau ratusan formulir. Kemudian, Anda akan memiliki formulir yang memiliki potongan umum, tetapi tidak pernah cukup untuk membuat formulir dasar. Dalam kasus Anda, itu mungkin terjadi Anda ingin menggunakan tata letak yang berbeda atau tombol yang berbeda, tetapi tetap semuanya sama. Dan saat itulah masalahnya mulai.
Euforia

2
'Masalah dengan skala "tidak ada jika Anda memiliki desain yang layak setengah jalan. Kami memiliki proyek tempat saya bekerja dengan beberapa ratus formulir. Kami menggunakan warisan formulir dengan berat untuk memberikan konsistensi dan fungsi umum, dan kami tidak pernah memiliki masalah dengan itu
Mason Wheeler

2
@MasonWheeler Saya memiliki pengalaman yang sangat berlawanan. Kami mencoba menggunakan pewarisan formulir di salah satu aplikasi kami, dan setiap kali kami melakukan sedikit perubahan pada formulir dasar, semuanya rusak dan kami harus memperbaiki semua formulir lainnya secara manual. Selain itu, perancang berperilaku aneh ketika Anda bekerja dengan formulir yang diwarisi.
Euforia

1
@ Euphoric: Desainer mana? Kami menggunakan Delphi, dan perancangnya bekerja dengan baik dengan formulir yang diwarisi. Dan lagi, Anda tidak memiliki masalah ini jika Anda memiliki desain yang bagus . Jika Anda tidak merencanakan apa pun, tentu saja semuanya akan rapuh dan pecah kapan saja Anda menyentuhnya, tetapi itu tidak berbeda dengan kode lainnya.
Mason Wheeler

2

Banyak dari ini terkait dengan tumpukan teknologi pilihan.

WinForms dan WPF mungkin keduanya .NET UI frameworks tetapi sangat bervariasi dalam cara Anda mencapai tujuan akhir. Paradigma tertentu bergerak di antara teknologi baik-baik saja tetapi yang lain tidak dan Anda tidak boleh mencoba dan memaksakan paradigma hanya karena Anda merasa itu ada di setiap kerangka kerja. Ada alasan mengapa MVVM diarahkan pada WPF / SL dan MVC adalah konsep terpisah dalam ASP.NET dari WebForms dan sebagainya. Teknologi tertentu bekerja lebih baik dengan paradigma tertentu.

Ingatlah bahwa kode yang dibuat umumnya harus dihapus dari masalah KERING Anda. Sementara berlaku dalam beberapa kasus, lebih sering tidak harus diabaikan. Konsep KERING tentu harus tetap menjadi fokus di luar lapisan Presentasi Anda tetapi pada lapisan Presentasi dihasilkan kode lebih sering daripada bukan produk sampingan dari kerangka kerja Anda bekerja. Ini bukan untuk mengatakan Anda tidak dapat menerapkan prinsip KERING dalam pendekatan Anda tetapi tetap waspada. Bisakah Anda membuat Formulir dasar dan mewarisi darinya tanpa batas? Iya. Bisakah Anda seret dan jatuhkan komponen pada Formulir baru setiap saat sesuai kebutuhan? Iya. Tetap fokus pada tujuan akhir, menghindari cacat potensial, membuatnya mudah untuk refactor hilir, dan skalabilitas saat bekerja dalam batas-batas tumpukan teknologi pilihan.


0

Anda dapat menggunakan warisan dengan menyediakan Anda dengan benar merangkum bidang Anda dan mengisi yang sesuai. Jika Anda ingin menggunakan warisan, saran saya adalah memiliki formulir dasar dan Model yang sesuai untuk formulir itu, dan untuk setiap derivasi diperoleh baik formulir dan Model.

Alternatif yang jauh lebih baik adalah mengelompokkan kontrol terkait menjadi satu atau lebih kontrol UserControl. Anda hanya perlu sedikit logika untuk memasukkan data yang relevan ke dalamnya.


0

Saya sepenuhnya setuju dengan Mason Wheeler, walaupun dalam tiga tahun mungkin bahkan dirinya sendiri telah berubah pikiran.

Saya mencoba mencari alternatif untuk bermigrasi dari executable Delphi ke WEB.

Hingga sekarang saya memutuskan sendiri untuk UNIGUI, karena saya masih dapat menggunakan warisan bentuk. Saya ingin Delphi memiliki Mixin seperti Dart, karena akan membuat saya memiliki lebih sedikit leluhur. Tapi saya merasa orang menulis lebih banyak kode dalam MVC daripada dengan Visual Form Inheritance, karena sebagian besar navigasi, panggilan ke aturan validasi dalam datamodule (applyupdates), kriteria penyaringan sql, mencari dataset klien, mencari set data klien, semuanya ditulis dalam 5 mungkin 6 Bentuk leluhur.

Bahkan "Dengan MVC akan lebih mudah bagi Anda untuk meninggalkan Delphi di Fitur" bagi saya jangan bekerja sebagai argumen, karena orang mengundang OOP, semuanya kelas, properti, metode. Jadi yang saya butuhkan adalah seorang penerjemah. Benar-benar tidak dapat menemukan keuntungan, mungkin untuk situs web yang jauh lebih mudah tetapi berubah dalam basis harian.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.