Apakah biasa menggunakan kelas parsial untuk mencapai 'modularitas'?


24

Saya baru-baru ini menghadapi situasi di basis kode kami di mana tim yang berbeda menciptakan 'kelas dewa' yang berisi sekitar 800 metode, dibagi menjadi 135 file sebagai kelas parsial.

Saya bertanya kepada tim lain tentang ini. Sementara reaksi saya adalah untuk mengeluarkannya dari orbit, mereka bersikeras bahwa itu adalah desain yang baik, praktik umum, dan mempromosikan 'modularitas' dan 'kemudahan implementasi' karena pengembang baru dapat meningkatkan fungsionalitas dengan hampir tanpa pengetahuan tentang sisanya. dari sistem.

Apakah ini sebenarnya praktik yang umum atau dalam cara apa pun merupakan ide yang baik? Saya cenderung mengambil langkah-langkah segera untuk menjatuhkan hewan buas ini (atau setidaknya mencegahnya tumbuh lebih jauh) tetapi saya bersedia percaya bahwa saya salah.


6
matikan dengan api! Tapi serius, bisakah tim lain memberikan kutipan untuk praktik umum yang diduga ini?
MattDavey

1
Tidak ada Saya yakin mereka menghembuskan asap tetapi saya berusaha melakukan uji tuntas saya sebelum saya menjatuhkan palu.
Joshua Smith

Apa alasan mereka untuk tidak melakukan ini sepanjang waktu?
JeffO

3
Minta mereka untuk menjelaskan, dalam satu kalimat, apa 800 metode di 135 file semua memiliki kesamaan satu sama lain. Seharusnya dimungkinkan untuk menjawabnya untuk kelas yang waras dan masuk akal.
Carson63000

3
@ Carson63000 "Ini melakukan semua fungsi yang diperlukan proyek." ada satu kalimat Anda.
Ryathal

Jawaban:


39

Ini bukan ide yang bagus.

Kelas parsial ada untuk membantu perancang formulir. Menggunakannya untuk alasan lain (dan bisa dibilang untuk tujuan yang dimaksudkan, tetapi itu masalah yang berbeda) adalah ide yang buruk, karena itu mengarah ke kelas yang membengkak yang sulit dibaca dan dipahami.

Lihatlah seperti ini: Jika kelas dewa dengan 800 metode dalam satu file, di mana Anda tahu di mana semuanya berada, adalah hal yang buruk - dan saya pikir semua orang akan setuju bahwa itu adalah - lalu bagaimana bisa kelas dewa dengan 800 metode tersebar di 135 file, di mana Anda tidak tahu di mana semuanya mungkin menjadi hal yang baik?


1
Saya sebagian besar setuju, tapi saya pikir mungkin ada beberapa kasus langka di mana partialdapat berguna bahkan tanpa kode yang dihasilkan. Mungkin ketika Anda memiliki sesuatu seperti kelas bersarang?
svick

1
@vick: Kelas parsial menarik, tetapi biasanya tidak diperlukan. Saya tidak yakin mengapa memecah kelas menjadi file yang terpisah akan berguna ketika ada kelas bersarang. Kecuali Anda ingin kelas bersarang di file fisiknya sendiri. Dalam hal ini ... mungkin tidak apa-apa. ;)
FrustratedWithFormsDesigner

5
Saya kadang-kadang menggunakan kelas parsial untuk implementasi antarmuka eksplisit - terutama sesuatu seperti System.IConvertible. Entah bagaimana tampaknya lebih bersih daripada meletakkan #region besar di kelas saya.
MattDavey

1
Komentar kelas bersarang sebenarnya adalah ide yang sangat bagus, saya bahkan tidak pernah memikirkan itu. Meskipun ... itu lebih berkaitan dengan organisasi, daripada 'modularitas'
Sheldon Warkentin

1
"Kelas parsial ada untuk membantu perancang formulir." Benar secara umum, tetapi saya akan menambahkan "... dan generator kode lainnya.". Saya setuju dengan sisa jawaban Anda;)
Silas

14

Jadi pertanyaannya adalah:

Apakah ini sebenarnya praktik yang umum atau dalam cara apa pun merupakan ide yang baik?

Di antara jawaban yang tersedia saat ini adalah no . Jadi ada beberapa hal lain yang bisa saya ikuti seperti; bahkan kode prosedural dapat dibuat modular dan termasuk semuanya tetapi kitchen sink bukanlah cara Anda mencapai modularitas. Yang dilakukan oleh satu kelas raksasa menjadi parsial, semuanya bertambah menjadi satu kekacauan besar.

Namun pertanyaan itu adalah ikan haring merah ke bagian kritis nyata apa yang telah terjawab; karena OP juga memiliki pendapat berikut tentang situasi tersebut:

(...) Sementara reaksi usus saya adalah untuk mengeluarkannya dari orbit, mereka bersikeras ...

(...) Saya cenderung mengambil langkah segera untuk menjatuhkan makhluk buas ini (atau setidaknya mencegahnya agar tidak bertambah besar) tetapi saya bersedia percaya bahwa saya salah.

PEGANG KUDAMU!

Ini di sini adalah sesuatu yang akan membuat monocle kiasan saya berbicara jatuh ke dalam cangkir teh kiasan saya.

Saya pernah berada dalam situasi yang sama dan biarkan saya memberi tahu Anda: JANGAN jatuh hati pada dorongan untuk melakukannya. Tentu, Anda dapat menjatuhkan Nuke Hammer of Justice ke dalam tim, tetapi sebelum melakukannya, silakan humor sendiri dengan sedikit teka-teki berikut:

Apa yang akan terjadi jika Anda memberi tahu tim bahwa kode mereka menyebalkan dan turun ?

(... atau sesuatu seperti itu tetapi tidak terlalu ofensif, itu tidak masalah karena mereka akan tersinggung terlepas dari apa yang kamu lakukan jika kamu memutuskan untuk memaksakan diri pada mereka)

Bagaimana situasi saat ini dengan basis kode? Apakah ini berhasil? Maka Anda akan memiliki masalah besar menjelaskan kepada klien mereka bahwa kode mereka pada dasarnya payah . Apa pun alasan mereka: selama itu berhasil, sebagian besar klien tidak peduli tentang bagaimana kode tersebut disusun.

Juga menempatkan diri Anda pada posisi mereka, apa yang akan mereka lakukan? Biarkan saya menghibur Anda dengan hasil yang sangat mungkin berikut:

Anggota Tim # 1: "Jadi ada orang ini yang memberi tahu kami bahwa kami telah melakukan kesalahan selama beberapa tahun terakhir."

Anggota Tim # 2 dan # 3: "Dasar brengsek."

Anggota Tim Influential # 4: "Jangan khawatir tentang itu, saya akan pergi ke manajemen dan melaporkannya sebagai pelecehan."

Lihat apa yang Pengaruh Anggota Tim # 4 lakukan di sana? Dia pergi ke manajemen dan mengurangi karma Anda di perusahaan. Dia mungkin orang Amerika-Italia, menyuruh semua orang untuk tidak khawatir tentang hal itu, tapi kemudian aku akan rasis tentang hal itu.

Melukis tim yang menyinggung ke sudut dengan membiarkan mereka mengakui bahwa mereka melakukan kesalahan begitu lama juga merupakan ide yang buruk dan mengarah ke hal yang sama. Anda akan kehilangan rasa hormat dan beberapa karma politik kantor.

Bahkan jika Anda berhasil membuat banyak orang untuk menandatangani ini, untuk "mengajar tim pelajaran", ingat bahwa Anda melakukan ini kepada orang-orang yang cukup pintar yang tampaknya menyelesaikan beberapa hal. Setelah kode akan ditulis ulang / refactored / ditangani / apa pun dengan dan masalah muncul bahwa Anda akan bertanggung jawab karena Anda adalah firestarter .

Menjadi lawan tentang situasi seperti ini sebagian besar merupakan permainan kalah / kalah karena berisiko menjadi lingkaran setan permainan menyalahkan. Ini adalah hasil yang kurang optimal untuk situasi ini. Bahkan jika Anda menang, Anda tiba-tiba diserahkan kekacauan yang orang lain lakukan.

Ada Cara Lain (Banyak Dewasa)

Saya berada dalam situasi yang sama sekali, tetapi kemudian saya mengambil panah di lutut. Jadi setelah beberapa saat dengan karir yang tiba-tiba mengubah panah dalam pikiran saya, saya mendapatkan buku Driving Technical Change oleh Terrence Ryan . Ini mencantumkan beberapa pola skeptis, jenis orang yang tidak bertindak berdasarkan ide-ide bagus. Mereka semua kemungkinan besar berlaku dalam kasus OP:

  • The Uninformed - Mereka benar-benar tidak tahu ada cara lain atau hanya tidak mengerti. Pengembang junior biasanya cocok dengan kategori ini tetapi tidak harus. (Sejujurnya: Saya sudah bertemu pengembang junior yang akan lebih cerah dari ini.)
  • The Herd - Mereka tahu teknik yang lebih baik daripada menggunakan kelas parsial tetapi tidak tahu bahwa mereka diizinkan.
  • The Cynic - Mereka hanya suka berdebat bahwa memiliki kelas parsial lebih baik daripada ide Anda hanya untuk berdebat. Sangat mudah untuk melakukannya di tengah orang banyak daripada berdiri di depan orang banyak.
  • The Burned - Untuk beberapa alasan aneh mereka tidak suka membuat kelas baru, kemungkinan besar mereka menganggapnya terlalu sulit.
  • The Time Crunched - Mereka begitu sibuk sehingga mereka tidak bisa repot-repot memperbaiki kode mereka.
  • Bos - Mereka berpikir: "Ya itu berhasil; jadi mengapa repot-repot?"
  • The Irrational - Ok, mereka benar-benar gila.

Buku ini berlanjut dengan daftar strategi dan seterusnya, tetapi dalam kasus OP itu masalah persuasi. Akan kuat dengan fakta-fakta tentang pola-anti saja tidak cukup.

Jika Anda berminat untuk meningkatkan kualitas kode, setidaknya berikan kesempatan kepada tim yang menyinggung untuk mengulangi dan memperbaiki kekacauan mereka sendiri . Secara pribadi saya akan mencoba untuk mempengaruhi mereka dengan mendengarkan dan mengajukan pertanyaan-pertanyaan terkemuka, biarkan mereka menceritakan kisah mereka:

  • Apa sebenarnya yang dilakukan kelas dewa mereka?
  • Apakah mereka mengalami masalah? Apakah mereka punya bug? Sarankan perbaikan waras tanpa menyuruh mereka melakukannya.
  • Jika Anda pengguna kelas dewa ini sebagai API: Apakah ada cara yang lebih sederhana untuk menggunakan kode daripada menggunakan semuanya? Sarankan contoh yang lebih sederhana, lihat bagaimana mereka bereaksi.
  • Bisakah Anda mengganti beberapa fungsi dengan yang lain, tanpa harus menulis fungsinya?
  • Apakah mereka membutuhkan pelatihan? Dapatkah Anda meyakinkan manajemen untuk memberikannya kepada mereka atau mengadakan pertemuan makan siang tentang pola dan praktik?

... dan seterusnya. Beri mereka saran kecil agar mereka dapat bergerak maju. Butuh waktu dan akan membutuhkan minyak siku kelas politik kantor tetapi kesabaran dan kerja keras adalah kebajikan kan?


Ini jawaban yang sangat mendalam. Jika Anda adalah pengembang baru, Anda perlu memahami ini. Kebanyakan pengembang berpengalaman menyadari hal ini setelah beberapa tahun, beberapa tidak pernah melakukannya.
FishySwede

6

Halaman Kelas dan Metode Partial MSDN menyarankan dua situasi untuk menggunakan kelas parsial:
1. Untuk membagi kelas raksasa menjadi beberapa file terpisah.
2. Untuk memiliki tempat untuk meletakkan kode sumber yang dibuat secara otomatis.

2 banyak digunakan oleh Visual studio (misalnya, untuk file aspx dan untuk winforms). Ini adalah penggunaan kelas parsial yang wajar.

1 adalah apa yang dilakukan tim Anda. Saya akan mengatakan bahwa menggunakan kelas parsial adalah cara yang sangat masuk akal untuk mencapai modularitas ketika Anda memiliki kelas raksasa, tetapi memiliki kelas raksasa itu sendiri tidak masuk akal. Dengan kata lain, memiliki kelas raksasa adalah ide yang buruk, tetapi jika Anda akan memiliki kelas raksasa, kelas parsial adalah ide yang bagus.

Meskipun jika Anda dapat secara cerdas membagi kelas menjadi file terpisah untuk dikerjakan oleh pengguna yang berbeda, tidak bisakah Anda membaginya menjadi kelas yang terpisah saja?


+1 untuk "tidak bisakah Anda membaginya menjadi kelas yang terpisah saja?". Inilah yang kami sarankan. Sepertinya akal sehat bahwa itu seharusnya dilakukan seperti itu pada awalnya.
Joshua Smith

4

Jadi pada akhirnya, mereka melakukan pengembangan prosedural normal tanpa ada OOP. Mereka memiliki satu namespace global dengan semua metode, variabel, dan yang lainnya.

Entah meyakinkan mereka bahwa mereka melakukan kesalahan atau keluar dari sana.


1

Kelas utilitas berisi metode yang tidak dapat digabungkan dengan metode lain untuk membuat kelas. Jika Anda memiliki 800+ metode, bagi menjadi 135 file, sepertinya seseorang telah berhasil menemukan beberapa metode umum ...

Hanya karena Anda memiliki satu kelas utilitas, tidak berarti Anda tidak dapat memiliki kelas utilitas lain.

Bahkan jika Anda memiliki 800 metode yang sebagian besar tidak terkait, solusinya bukan satu kelas besar dan banyak file. Solusinya adalah namespace, beberapa ruang nama sub dan banyak kelas kecil. Ini sedikit lebih banyak pekerjaan (Anda harus datang dengan nama untuk kelas dan juga metode). Tapi itu akan membuat hidup Anda lebih mudah ketika tiba saatnya untuk membersihkan kekacauan ini, dan sementara itu akan membuat intellisense lebih mudah digunakan (yaitu lebih mudah untuk menemukan di mana metode untuk menggunakannya).

Dan tidak, ini tidak umum (lebih banyak jumlah file daripada jumlah fungsi gratis).


0

Saya tidak suka ini sama sekali. Namun, mungkin kelas parsial masuk akal bagi pengembang selama pengembangan karena memungkinkan pengembangan bersamaan dari sejumlah besar metode ini, khususnya jika tidak ada banyak ketergantungan di antara mereka.

Kemungkinan lain adalah bahwa kelas parsial dibangun untuk mengubah kelas inti yang dihasilkan secara otomatis. Jika ini masalahnya, orang tidak boleh menyentuhnya, jika tidak kode kustom akan dicabut ketika diproduksi ulang.

Saya tidak yakin ada yang bisa mempertahankan ini dengan mudah tanpa belajar. Sekarang jika Anda membunuhnya, jumlah metode tidak akan turun. Jumlah metode dan kompleksitas, bagi saya, adalah masalah sebenarnya. Jika metode ini benar-benar milik kelas, maka memiliki 1 file besar tidak akan membuat hidup Anda lebih mudah, terutama dalam pemeliharaan, bahkan, mungkin lebih rentan kesalahan untuk mengekspos semua kode ini untuk kesalahan konyol seperti pencarian kartu liar dan ganti.

Jadi berhati-hatilah dan benarkan keputusan membunuh. Juga, pertimbangkan pengujian apa yang akan diperlukan.


0

Sangat bagus dari perspektif desain praktis dengan asumsi 135 file sebenarnya mengelompokkan metode yang mirip dengan apa yang akan dilakukan kelas tradisional. Ini hanya rata-rata 6 metode per file. Ini jelas bukan cara paling populer atau tradisional untuk merancang proyek. Mencoba mengubahnya hanya akan menciptakan banyak masalah dan niat buruk tanpa manfaat nyata. Membuat proyek sesuai dengan standar OO akan menciptakan banyak masalah yang diselesaikan. Ini adalah masalah yang sama sekali berbeda jika beberapa file tidak benar-benar memberikan pemisahan yang berarti.


3
Refactoring kode prosedural ke dalam OO umumnya memiliki masalah itu - saya pikir memperbaiki ini akan menjadi tugas besar dan mengajar tim untuk membuat kode dengan lebih baik, bahkan di atas itu, Joshua akan disalahkan atas semua yang terjadi pada tahun berikutnya (dan seterusnya ) jika dia meyakinkan mereka untuk refactor. Inilah sebabnya mengapa tidak ada yang pernah mendorong terlalu keras untuk melakukan refactor seperti ini (setidaknya tidak begitu mereka melihat hasilnya). Juga jika Anda berpikir itu adalah desain yang bagus - baik - tinjau kembali jawaban ini dalam 5 tahun dan beri tahu kami apa yang Anda pikirkan (Sepertinya saya mempelajari kembali semua yang saya ketahui tentang desain setiap 5 tahun atau lebih).
Bill K

@ BillK jika Anda menunggu sepuluh tahun apa yang Anda tahu mungkin akan menjadi filosofi desain "in" saat ini.
Ryathal

135 file umumnya dikelompokkan metode yang terkait, tetapi itu (bagi saya) masih tidak membuat ini ide yang baik. Saya ingin mendapatkan sistem ini diuji tetapi mematikan / mengejek 800 metode hydra akan menjadi sakit yang buruk di pantat.
Joshua Smith

@Ryathal itu bukan apa yang "dalam", itu apa yang Anda anggap desain yang baik (untuk alasan yang baik) dan kemudian, ketika Anda berlatih dan meningkatkan Anda menyadari itu bukan ide yang baik seperti yang Anda pikirkan. Sepertinya itu terjadi setiap 5 tahun atau lebih, dan sekali saya menyadari bahwa hal itu membuat saya marah terhadap komentar beberapa orang karena saya menyadari mereka sebenarnya adalah desainer yang sangat baik yang (seperti kita semua) dalam proses meningkatkan praktik kami selamanya. Satu-satunya programmer yang saya khawatirkan adalah orang yang tidak berpikir mereka dapat memperbaiki kode yang telah mereka tulis 5 tahun yang lalu.
Bill K.

0

Di luar jawaban yang sudah ditunjukkan, sebagian kelas dapat berguna dalam desain berlapis di mana Anda ingin mengatur fungsionalitas yang memotong lintas hierarki kelas Anda menjadi file lapisan khusus yang terpisah. Ini memungkinkan seseorang untuk menggunakan explorer solusi untuk menavigasi fungsionalitas per-lapisan (oleh organisasi file) dan tampilan kelas untuk menavigasi fungsionalitas per-kelas. Saya lebih suka menggunakan bahasa yang mendukung mixin dan / atau sifat-sifat, tetapi kelas parsial adalah alternatif yang masuk akal jika digunakan dengan hemat, dan tidak boleh menjadi pengganti untuk desain hierarki kelas yang baik.

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.