Apa perbedaan antara kohesi dan kopling?
Bagaimana kopling dan kohesi dapat menyebabkan desain perangkat lunak baik atau buruk?
Apa saja contoh yang menguraikan perbedaan antara keduanya, dan dampaknya terhadap kualitas kode secara keseluruhan?
Apa perbedaan antara kohesi dan kopling?
Bagaimana kopling dan kohesi dapat menyebabkan desain perangkat lunak baik atau buruk?
Apa saja contoh yang menguraikan perbedaan antara keduanya, dan dampaknya terhadap kualitas kode secara keseluruhan?
Jawaban:
Kohesi mengacu pada apa yang dapat dilakukan oleh kelas (atau modul). Kohesi rendah akan berarti bahwa kelas melakukan berbagai tindakan - kelas luas, tidak fokus pada apa yang seharusnya dilakukan. Kohesi tinggi berarti bahwa kelas difokuskan pada apa yang seharusnya dilakukan, yaitu hanya metode yang berkaitan dengan niat kelas.
Contoh Kohesi Rendah:
-------------------
| Staff |
-------------------
| checkEmail() |
| sendEmail() |
| emailValidate() |
| PrintLetter() |
-------------------
Contoh Kohesi Tinggi:
----------------------------
| Staff |
----------------------------
| -salary |
| -emailAddr |
----------------------------
| setSalary(newSalary) |
| getSalary() |
| setEmailAddr(newEmail) |
| getEmailAddr() |
----------------------------
Adapun kopling , mengacu pada seberapa terkait atau tergantung dua kelas / modul terhadap satu sama lain. Untuk kelas berpasangan rendah, mengubah sesuatu yang utama dalam satu kelas tidak boleh memengaruhi kelas lainnya. Kopling tinggi akan membuat sulit untuk mengubah dan mempertahankan kode Anda; karena kelas erat kaitannya, membuat perubahan bisa memerlukan seluruh perombakan sistem.
Desain perangkat lunak yang baik memiliki kohesi yang tinggi dan kopling yang rendah .
set
& get
menggambarkan fungsionalitas yang lebih spesifik untuk konteks "Staf" - spesifisitas yang lebih tinggi memberikan contoh bahwa kohesi yang lebih tinggi.
Kohesi adalah indikasi hubungan dalam suatu modul.
Kopling adalah indikasi hubungan antar modul.
Kohesi
Kopel
periksa tautan ini
Kohesi tinggi dalam modul dan kopling rendah antar modul sering dianggap terkait dengan kualitas tinggi dalam bahasa pemrograman OO.
Sebagai contoh, kode di dalam setiap kelas Java harus memiliki kohesi internal yang tinggi, tetapi sedapat mungkin digabungkan dengan kode di kelas Java lainnya.
Bab 3 Konstruksi Perangkat Lunak Berorientasi Objek Meyer (edisi ke-2) adalah deskripsi yang bagus tentang masalah ini.
Kohesi adalah indikasi bagaimana terkait dan fokus tanggung jawab elemen perangkat lunak.
Coupling mengacu pada seberapa kuat elemen perangkat lunak terhubung ke elemen lain.
Elemen perangkat lunak dapat berupa kelas, paket, komponen, subsistem, atau sistem. Dan ketika merancang sistem, disarankan untuk memiliki elemen perangkat lunak yang memiliki kohesi tinggi dan mendukung kopling rendah .
Kohesi rendah menghasilkan kelas-kelas monolitik yang sulit untuk dipertahankan, dipahami dan mengurangi penggunaan kembali. Demikian pula Kopling Tinggi menghasilkan kelas-kelas yang tergabung erat dan perubahannya cenderung non-lokal, sulit untuk diubah dan mengurangi penggunaan kembali.
Kita dapat mengambil skenario hipotetis di mana kami merancang monitor yang khas ConnectionPool
dengan persyaratan berikut. Perhatikan bahwa, itu mungkin terlihat terlalu banyak untuk kelas sederhana seperti ConnectionPool
tetapi maksud dasarnya adalah hanya untuk menunjukkan kopling rendah dan kohesi tinggi dengan beberapa contoh sederhana dan saya pikir akan membantu.
Dengan kohesi yang rendah, kita dapat merancang ConnectionPool
kelas dengan secara paksa memasukkan semua fungsi / tanggung jawab ini ke dalam satu kelas seperti di bawah ini. Kita dapat melihat bahwa kelas tunggal ini bertanggung jawab untuk manajemen koneksi, berinteraksi dengan basis data serta mempertahankan statistik koneksi.
Dengan kohesi yang tinggi, kita dapat menetapkan tanggung jawab ini di seluruh kelas dan membuatnya lebih dapat dipertahankan dan digunakan kembali.
Untuk menunjukkan kopling rendah, kami akan melanjutkan dengan ConnectionPool
diagram kohesi tinggi di atas. Jika kita melihat diagram di atas meskipun mendukung kohesi yang tinggi, ConnectionPool
ini sangat erat dengan ConnectionStatistics
kelas dan PersistentStore
berinteraksi dengan mereka secara langsung. Alih-alih mengurangi kopling, kita bisa memperkenalkan ConnectionListener
antarmuka dan membiarkan dua kelas ini mengimplementasikan antarmuka dan membiarkan mereka mendaftar dengan ConnectionPool
kelas. Dan ConnectionPool
akan mengulangi melalui pendengar ini dan memberi tahu mereka tentang koneksi dapatkan dan lepaskan acara dan memungkinkan lebih sedikit sambungan.
Catatan / Kata atau Perhatian: Untuk skenario sederhana ini mungkin terlihat seperti kerja keras tetapi jika kita membayangkan skenario real-time di mana aplikasi kita perlu berinteraksi dengan beberapa layanan pihak ketiga untuk menyelesaikan transaksi: Langsung menyatukan kode kita dengan layanan pihak ketiga akan berarti bahwa setiap perubahan dalam layanan pihak ketiga dapat mengakibatkan perubahan pada kode kami di banyak tempat, sebagai gantinya kami dapat Facade
berinteraksi dengan beberapa layanan ini secara internal dan setiap perubahan pada layanan tersebut menjadi lokal bagi Facade
dan menerapkan penggandengan rendah dengan pihak ketiga jasa.
Peningkatan kohesi dan penurunan kopling memang menghasilkan desain perangkat lunak yang baik.
Kohesi mem-partisi-kan fungsionalitas Anda sehingga ringkas dan terdekat dengan data yang relevan dengannya, sementara decoupling memastikan bahwa implementasi fungsional terisolasi dari sistem lainnya.
Decoupling memungkinkan Anda untuk mengubah implementasi tanpa mempengaruhi bagian lain dari perangkat lunak Anda.
Kohesi memastikan bahwa implementasi lebih spesifik untuk fungsionalitas dan pada saat yang sama lebih mudah untuk dipertahankan.
Metode yang paling efektif untuk mengurangi kopling dan meningkatkan kohesi adalah desain dengan antarmuka .
Itu adalah objek fungsional utama seharusnya hanya 'saling mengenal' melalui antarmuka yang mereka implementasikan. Implementasi antarmuka memperkenalkan kohesi sebagai konsekuensi alami.
Meskipun tidak realistis dalam beberapa senarios, itu harus menjadi tujuan desain untuk dikerjakan.
Contoh (sangat samar):
public interface IStackoverFlowQuestion
void SetAnswered(IUserProfile user);
void VoteUp(IUserProfile user);
void VoteDown(IUserProfile user);
}
public class NormalQuestion implements IStackoverflowQuestion {
protected Integer vote_ = new Integer(0);
protected IUserProfile user_ = null;
protected IUserProfile answered_ = null;
public void VoteUp(IUserProfile user) {
vote_++;
// code to ... add to user profile
}
public void VoteDown(IUserProfile user) {
decrement and update profile
}
public SetAnswered(IUserProfile answer) {
answered_ = answer
// update u
}
}
public class CommunityWikiQuestion implements IStackoverflowQuestion {
public void VoteUp(IUserProfile user) { // do not update profile }
public void VoteDown(IUserProfile user) { // do not update profile }
public void SetAnswered(IUserProfile user) { // do not update profile }
}
Beberapa tempat lain di basis kode Anda, Anda bisa memiliki modul yang memproses pertanyaan terlepas dari apa mereka:
public class OtherModuleProcessor {
public void Process(List<IStackoverflowQuestion> questions) {
... process each question.
}
}
Penjelasan terbaik tentang Kohesi berasal dari Kode Bersih Paman Bob:
Kelas harus memiliki sejumlah kecil variabel instan. Setiap metode kelas harus memanipulasi satu atau lebih variabel tersebut. Secara umum, semakin banyak variabel yang dimanipulasi metode, semakin kohesif metode itu ke kelasnya . Kelas di mana setiap variabel digunakan oleh masing-masing metode secara maksimal kohesif.
Secara umum tidak disarankan atau tidak mungkin untuk membuat kelas kohesif maksimal; di sisi lain, kami ingin kohesi menjadi tinggi . Ketika kohesi tinggi, itu berarti bahwa metode dan variabel kelas saling tergantung dan menggantung bersama sebagai keseluruhan yang logis.
Strategi menjaga fungsi tetap kecil dan membuat daftar parameter tetap pendek terkadang dapat menyebabkan proliferasi variabel instan yang digunakan oleh subset metode. Ketika ini terjadi, hampir selalu berarti bahwa setidaknya ada satu kelas lain yang berusaha keluar dari kelas yang lebih besar. Anda harus mencoba memisahkan variabel dan metode menjadi dua atau lebih kelas sehingga kelas baru lebih kohesif.
sederhananya, Kohesi mewakili sejauh mana bagian dari basis kode membentuk satu kesatuan atomik secara logis. Coupling , di sisi lain, mewakili sejauh mana satu unit independen dari yang lain. Dengan kata lain, itu adalah jumlah koneksi antara dua atau lebih unit. Semakin sedikit angkanya, semakin rendah kopling.
Intinya, kohesi tinggi berarti menjaga bagian-bagian basis kode yang terkait satu sama lain di satu tempat. Kopling rendah, pada saat yang sama, adalah tentang memisahkan bagian basis kode yang tidak terkait sebanyak mungkin.
Jenis kode dari perspektif kohesi dan kopling:
Ideal adalah kode yang mengikuti pedoman. Ini sangat longgar dan sangat kohesif. Kami dapat mengilustrasikan kode tersebut dengan gambar ini:
Obyek Tuhan adalah hasil dari memperkenalkan kohesi tinggi dan kopling tinggi. Ini adalah anti-pola dan pada dasarnya berarti sepotong kode yang melakukan semua pekerjaan sekaligus: pemilihan yang buruk terjadi ketika batas antara kelas atau modul yang berbeda dipilih dengan buruk
Decoupling destruktif adalah yang paling menarik. Kadang-kadang terjadi ketika seorang programmer mencoba decouple basis kode sehingga kode benar-benar kehilangan fokusnya:
baca lebih lanjut di sini
Kohesi dalam rekayasa perangkat lunak adalah sejauh mana unsur-unsur modul tertentu dimiliki bersama. Dengan demikian, ini adalah ukuran seberapa kuat setiap fungsionalitas terkait yang diekspresikan oleh kode sumber modul perangkat lunak.
Menggabungkan dengan kata-kata sederhana, adalah seberapa banyak satu komponen (sekali lagi, bayangkan sebuah kelas, meskipun tidak harus) tahu tentang cara kerja bagian dalam atau elemen dalam yang lain, yaitu seberapa banyak pengetahuan yang dimiliki komponen lain.
Saya menulis posting blog tentang ini , jika Anda ingin membaca sedikit lebih detail dengan contoh dan gambar. Saya pikir itu menjawab sebagian besar pertanyaan Anda.
kohesi merujuk semua tentang bagaimana kelas tunggal dirancang. Kohesi adalah prinsip Berorientasi Objek yang paling erat terkait dengan memastikan bahwa kelas dirancang dengan tujuan tunggal dan terfokus dengan baik. Kelas yang lebih fokus adalah, keterpaduan kelas itu lebih. Keuntungan dari kohesi tinggi adalah bahwa kelas-kelas seperti itu jauh lebih mudah untuk dipertahankan (dan lebih jarang diubah) daripada kelas-kelas dengan kohesi rendah. Manfaat lain dari kohesi tinggi adalah bahwa kelas dengan tujuan yang terfokus dengan baik cenderung lebih dapat digunakan kembali daripada kelas lain.
Pada gambar di atas, kita dapat melihat bahwa dalam kohesi rendah hanya satu kelas yang bertanggung jawab untuk melakukan banyak pekerjaan yang tidak umum yang mengurangi kemungkinan re-usability dan maintenance. Tetapi dalam kohesi tinggi ada kelas yang terpisah untuk semua pekerjaan untuk melaksanakan pekerjaan tertentu, yang menghasilkan kegunaan dan pemeliharaan yang lebih baik.
Kohesi (Co-hesion): Co yang berarti bersama , hesion yang berarti tetap . Sistem penyatuan partikel-partikel zat yang berbeda.
Contoh nyata: img Courtesy
Seluruh Lebih Besar dari Jumlah Bagian -Aristotle.
Kohesi adalah jenis pengukuran ordinal dan biasanya digambarkan sebagai "kohesi tinggi" atau "kohesi rendah". Modul dengan kohesi tinggi cenderung lebih disukai, karena kohesi tinggi dikaitkan dengan beberapa sifat perangkat lunak yang diinginkan termasuk ketahanan, keandalan, usabilitas ulang, dan pemahaman. Sebaliknya, kohesi rendah dikaitkan dengan sifat-sifat yang tidak diinginkan seperti sulit dipertahankan, diuji, digunakan kembali, atau bahkan dipahami. wiki
Kopling biasanya kontras dengan kohesi . Kopling rendah sering berkorelasi dengan kohesi tinggi, dan sebaliknya. Kopling rendah sering merupakan tanda dari sistem komputer yang terstruktur dengan baik dan desain yang baik, dan ketika dikombinasikan dengan kohesi yang tinggi, mendukung tujuan umum keterbacaan dan pemeliharaan yang tinggi. wiki
Saya pikir perbedaan dapat dimasukkan sebagai berikut:
Dalam posting blog ini saya menulis tentang itu lebih terinci.
Kohesi adalah indikasi kekuatan fungsional relatif dari suatu modul.
Tampilan konvensional:
"single-mindedness" dari sebuah modul
Tampilan OO:
Kohesi menyiratkan bahwa komponen atau kelas merangkum hanya atribut dan operasi yang terkait erat satu sama lain dan dengan kelas atau komponen itu sendiri
ETingkat kerekatan
UnctionalFungsional
AyerLayer
Komunikasi
Equ Penting
Prosedur
EmpTemporal
Kemampuan
Coupling adalah indikasi saling ketergantungan antar modul.
Coupling tergantung pada kompleksitas antarmuka antara modul, titik di mana entri atau referensi dibuat ke modul, dan data apa yang melewati antarmuka.
Pandangan Konvensional: Sejauh mana suatu komponen terhubung ke komponen lain dan ke dunia luar
OO view: ukuran kualitatif dari tingkat di mana kelas terhubung satu sama lain
Tingkat kopling
OntIsi
OmmCommon
Kontrol
Langkah
Data
Panggilan rutin
Tipe penggunaan
Sertakan atau impor
Eksternal #
Coupling = interaksi / hubungan antara dua modul ... Kohesi = interaksi antara dua elemen dalam suatu modul.
Perangkat lunak terdiri dari banyak modul. Modul terdiri dari elemen. Anggap modul adalah program. Fungsi dalam suatu program adalah elemen.
Pada saat dijalankan, output dari suatu program digunakan sebagai input untuk program lain. Ini disebut interaksi modul ke modul atau proses untuk memproses komunikasi. Ini juga disebut Kopling.
Dalam satu program, output dari suatu fungsi diteruskan ke fungsi lain. Ini disebut interaksi elemen dalam modul. Ini juga disebut sebagai Kohesi.
Contoh:
Coupling = komunikasi di antara 2 keluarga yang berbeda ... Kohesi = komunikasi di antara ayah-ibu-anak dalam keluarga.
Sederhananya, kohesi berarti bahwa kelas harus mewakili konsep tunggal.
Antarmuka publik suatu kelas adalah kohesif jika semua fitur kelas terkait dengan konsep yang diwakili kelas. Misalnya, alih-alih memiliki kelas CashRegister, memiliki kohesi fitur CashRegister dan Coin menjadikannya menjadi 2 kelas - kelas CashRegister dan Koin.
Dalam penggabungan , satu kelas tergantung pada yang lain karena menggunakan objek dari kelas.
Masalah dengan kopling tinggi adalah dapat menimbulkan efek samping. Satu perubahan dalam satu kelas dapat menyebabkan kesalahan yang tidak terduga di kelas lain dan dapat merusak seluruh kode.
Umumnya, kohesi tinggi dan kopling rendah dianggap sebagai OOP berkualitas tinggi.
Istilah kohesi memang sedikit kontra intuitif untuk apa artinya dalam desain perangkat lunak.
Makna kohesi yang umum adalah bahwa sesuatu yang saling menempel dengan baik, disatukan, yang ditandai oleh ikatan kuat seperti daya tarik molekul. Namun dalam desain perangkat lunak, itu berarti berjuang untuk kelas yang idealnya hanya melakukan satu hal, sehingga beberapa sub-modul bahkan tidak terlibat.
Mungkin kita bisa memikirkannya dengan cara ini. Suatu bagian memiliki kohesi terbanyak ketika itu adalah satu-satunya bagian (hanya melakukan satu hal dan tidak dapat dirinci lebih lanjut). Inilah yang diinginkan dalam desain perangkat lunak. Kohesi hanyalah nama lain untuk "tanggung jawab tunggal" atau "pemisahan keprihatinan".
Istilah kopling di tangan cukup intuitif yang berarti ketika sebuah modul tidak bergantung pada terlalu banyak modul lain dan yang terhubung dengan itu dapat dengan mudah diganti misalnya mematuhi prinsip substitusi liskov .
1.Comincidental 2.Logical 3.Temporal 4.Procedural 5.Comunication 6.Sequential 7.Functional