Bagaimana saya bisa tahu jika perangkat lunak sangat berpasangan?

Saya akrab dengan istilah "sangat berpasangan" tetapi saya ingin tahu apakah ada tanda-tanda (bau kode) yang dapat menunjukkan bahwa kode sangat berpasangan. Saya saat ini bekerja dengan Java EE tetapi ini dapat diterapkan ke bahasa apa pun.

Edit:

Jika ada yang tertarik, artikel ini kedengarannya membantu: Dalam mengejar kualitas kode: Waspadalah dengan pasangan yang ketat! (IBM)

Indikator nomor satu dari modul yang digabungkan secara buruk menurut saya adalah ketergantungan bilateral. Sebagai contoh, Module1 satu memanggil beberapa fungsi di Module2 dan Module2 memanggil beberapa fungsi di Module1.

Sebagian besar antarmuka harus searah. Jika modul yang dipanggil perlu meneruskan beberapa informasi ke modul panggilan yang tidak dikembalikan sebagai bagian dari panggilan maka harus menggunakan semacam pesan yang lewat atau mekanisme pemicu peristiwa seperti antrian pesan. Idealnya, antarmuka untuk menyampaikan pesan harus diteruskan selama beberapa proses inisialisasi atau pendaftaran. Ini sepenuhnya mengabstraksi antarmuka sedemikian rupa sehingga modul tidak benar-benar peduli untuk siapa acara ini ... karena itu dipisahkan.

Indikasi lain adalah ketika satu modul terus-menerus memanggil beberapa modul lain untuk beberapa set data tertentu. Ini akan membuat Anda mempertanyakan siapa yang sebenarnya memiliki kumpulan data. Mengapa modul ini dipertanyakan selalu perlu melihat data yang dimiliki beberapa modul lainnya?

Alat ketiga untuk berbicara adalah bertanya pada diri sendiri, "Dapatkah saya mengeluarkan modul ini dan menggantinya tanpa memerlukan perubahan pada modul lain.

Ini bukan daftar lengkap, tetapi mereka adalah tiga hal teratas yang saya tanyakan pada diri saya ketika merancang perangkat lunak.

Pepatah desain lama adalah, "Anda dapat menyentuh teman-teman Anda, dan Anda dapat menyentuh kemaluan Anda. Tetapi Anda tidak dapat menyentuh privasi teman-teman Anda." Singkatnya.

Tanda-tanda kode yang sangat berpasangan mencakup antarmuka yang sangat besar yang membuat orang tahu tentang detail pribadi implementasi, dan objek yang tampaknya "tahu banyak tentang satu sama lain". Ada alat untuk analisis otomatis yang akan menandai kode yang terlihat sangat cocok untuk Anda. Lihat http://www.scitools.com/features/metricsintro.php untuk yang acak. (Saya tidak tahu seberapa baik kerjanya. Itu hanya muncul cukup tinggi dalam pencarian Google.)

Coba tulis beberapa tes unit untuk kelas. Jika Anda tidak dapat dengan mudah menguji kelas tanpa perlu membuat / mengejek banyak kelas pendukung atau db / ui apa pun maka itu merupakan pertanda buruk kopling / dependensi.

Ini juga salah satu obat terbaik, tetapi Anda harus melakukannya selama pengkodean (seperti TDD) untuk membuat Anda jujur.

Tanda yang jelas bagi saya adalah bahwa semuanya bersifat publik.

Tanda lainnya adalah pelanggaran Hukum Demeter - berlebihan referensi ini.BeberapaObj.SomeProp.SomeProp pada antarmuka yang tidak lancar.

Saya pernah melihat apa yang sejak itu saya juluki "kelas kepala boneka" yang membuat formulir entri data saat itu juga. Itu beberapa pelanggaran desain perangkat lunak lain sehingga kopling yang berlebihan adalah yang paling perhatian.

Ketika mengambil data dari kontrol yang dibuatnya, ia melakukannya seperti ini:

var control = activeDataEntryControl as CustomTextBox;
if (control != null)
   result = control.NestedTextBox.Text;

/* several other controls */

The Ripple Effect .

Setiap perubahan memiliki efek riak melalui semua modul yang terpasang erat.

Prinsip "Terbuka-Tutup" telah dilanggar karena tidak ditutup dengan benar dan perubahan bocor.

Periksa jumlah # include / import dll di antara kelas / paket / dlls / toples / whatnots. Cobalah untuk menggambar grafik ini, secara mental, manual atau menggunakan beberapa jenis alat.

• Jika grafik itu padat (mis. Banyak koneksi di semua tempat), maka sistem Anda monolitik dan sangat berpasangan.
• Jika itu jelas dibagi menjadi beberapa lapisan, tanpa koneksi melintasi / melalui lapisan, dan koneksi sedikit, Anda memiliki sistem modular dan dipisahkan.

Jika Anda merasa tidak mungkin untuk mengimplementasikan fitur karena Anda tidak tahu ke mana tanggung jawab tertentu terjadi, maka sistem Anda terlalu erat.

Untuk tanda-tanda yang sangat mendasar, Anda dapat mempertimbangkan mencari jumlah antarmuka dan penggunaannya di antara kelas-kelas paket yang berbeda (biasanya kode yang digabungkan secara longgar berisi antarmuka dan ada interaksi langsung terbatas antara kelas-kelas individual dalam paket yang berbeda), jumlah nama kelas yang dapat digunakan untuk mengelompokkan kelas-kelas lain (dalam kode yang longgar digabungkan interaksi aktual antara kelas-kelas yang memiliki pekerjaan berbeda dilakukan oleh fungsi antarmuka atau dengan fungsi kelas yang lebih umum / pengelompokan) atau jumlah variabel publik di dalam kelas (lebih longgar jauh lebih sedikit / bahkan tidak ada variabel publik ).

Hampir semua bau kode menunjukkan kopling berlebihan dalam beberapa cara. Saya kira bau yang paling menunjukkan kopling meskipun mungkin "Intimacy tidak pantas" (bau favorit saya).

Saya kira metode lain yang masuk akal untuk mengukur adalah dengan menghitung garis-garis dalam diagram UML Anda. Jika Anda memiliki N objek, dan N ^ N (atau lebih) garis di antara mereka, maka kode Anda cukup banyak digabungkan secara maksimal. N baris mungkin akan seminimal mungkin.