Kedua jawaban saat ini tampaknya hanya mencapai sasaran, dan mereka berfokus pada contoh yang mengaburkan gagasan inti. Ini juga bukan (semata-mata) prinsip OOP tetapi prinsip desain perangkat lunak secara umum.
Hal yang "bervariasi" dalam frasa ini adalah kode. Christophe benar dalam mengatakan bahwa biasanya sesuatu yang mungkin berbeda, itulah yang sering Anda antisipasi . Tujuannya adalah melindungi diri Anda dari perubahan kode di masa mendatang. Ini terkait erat dengan pemrograman terhadap suatu antarmuka . Namun, Christophe salah untuk membatasi ini pada "detail implementasi". Bahkan, nilai nasihat ini sering kali disebabkan oleh perubahan persyaratan .
Ini hanya secara tidak langsung terkait dengan keadaan enkapsulasi, yang saya yakini sedang dipikirkan oleh David Arno. Nasihat ini tidak selalu (tetapi sering) menyarankan keadaan enkapsulasi, dan saran ini juga berlaku untuk objek yang tidak dapat diubah. Faktanya, konstanta penamaan hanyalah bentuk (sangat dasar) dari enkapsulasi yang bervariasi.
CandiedOrange secara eksplisit mengonfigurasi "apa yang bervariasi" dengan "perincian". Ini hanya sebagian benar. Saya setuju bahwa kode apa pun yang bervariasi adalah "perincian" dalam arti tertentu, tetapi "perincian" mungkin tidak berbeda (kecuali jika Anda mendefinisikan "perincian" untuk membuat tautologis ini). Mungkin ada alasan untuk merangkum detail yang tidak beragam, tetapi diktum ini bukan satu. Secara kasar, jika Anda sangat yakin bahwa "anjing", "kucing", dan "bebek" akan menjadi satu-satunya jenis yang perlu Anda tangani, maka diktum ini tidak menyarankan Refactoring yang dilakukan CandiedOrange.
Contoh Casting CandiedOrange dalam konteks yang berbeda, anggap kita memiliki bahasa prosedural seperti C. Jika saya memiliki beberapa kode yang berisi:
if (pet.type() == dog) {
pet.bark();
} else if (pet.type() == cat) {
pet.meow();
} else if (pet.type() == duck) {
pet.quack()
}
Saya mungkin berharap sepotong kode ini akan berubah di masa depan. Saya dapat "merangkum" itu hanya dengan mendefinisikan prosedur baru:
void speak(pet) {
if (pet.type() == dog) {
pet.bark();
} else if (pet.type() == cat) {
pet.meow();
} else if (pet.type() == duck) {
pet.quack()
}
}
dan menggunakan prosedur baru ini alih-alih blok kode (yaitu refactoring "metode ekstrak"). Pada titik ini menambahkan jenis "sapi" atau apa pun yang hanya perlu memperbarui speak
prosedur. Tentu saja, dalam bahasa OO Anda dapat memanfaatkan pengiriman dinamis seperti disinggung oleh jawaban CandiedOrange. Ini akan terjadi secara alami jika Anda mengakses pet
melalui antarmuka. Menghilangkan logika kondisional melalui pengiriman dinamis adalah masalah ortogonal yang merupakan bagian dari mengapa saya membuat tafsiran prosedural ini. Saya juga ingin menekankan bahwa ini tidak memerlukan fitur khusus untuk OOP. Bahkan dalam bahasa OO, merangkum apa yang bervariasi tidak berarti kelas atau antarmuka baru perlu dibuat.
Sebagai contoh yang lebih tipikal (yang lebih dekat tetapi tidak cukup OO), katakanlah kami ingin menghapus duplikat dari daftar. Katakanlah kita menerapkannya dengan mengulangi daftar pencatatan item yang telah kita lihat sejauh ini di daftar lain dan menghapus item yang telah kita lihat. Masuk akal untuk berasumsi bahwa kami mungkin ingin mengubah cara kami melacak item yang dilihat mungkin, setidaknya, untuk alasan kinerja. Diktum untuk merangkum apa yang bervariasi menunjukkan bahwa kita harus membangun tipe data abstrak untuk mewakili set item yang terlihat. Algoritme kami sekarang ditentukan berdasarkan tipe data Set abstrak ini, dan jika kami memutuskan untuk beralih ke pohon pencarian biner, algoritma kami tidak perlu diubah atau dirawat. Dalam bahasa OO, kami dapat menggunakan kelas atau antarmuka untuk menangkap tipe data abstrak ini. Dalam bahasa seperti SML / O '
Untuk contoh yang didorong oleh persyaratan, misalkan Anda perlu memvalidasi beberapa bidang terkait dengan beberapa logika bisnis. Meskipun Anda mungkin memiliki persyaratan khusus sekarang, Anda sangat curiga bahwa mereka akan berkembang. Anda dapat merangkum logika saat ini dalam prosedur / fungsi / aturan / kelasnya sendiri.
Meskipun ini adalah masalah ortogonal yang bukan bagian dari "merangkum apa yang bervariasi", sering alami untuk abstrak, yang diparameterisasi oleh, logika yang sekarang dienkapsulasi. Ini biasanya mengarah pada kode yang lebih fleksibel dan memungkinkan logika diubah dengan mengganti dalam implementasi alternatif daripada memodifikasi logika yang dienkapsulasi.