Namun, selama Anda percaya bahwa Prinsip Pergantian Liskov akan diikuti, lalu mengapa Anda tidak membiarkannya diganti?
Sebagai contoh, karena saya ingin implementasi kerangka suatu algoritma diperbaiki, dan hanya memungkinkan bagian-bagian tertentu untuk didefinisikan kembali oleh subkelas. Ini secara luas dikenal sebagai pola Metode Templat (penekanan di bawah oleh saya):
Metode template dengan demikian mengelola gambaran yang lebih besar dari semantik tugas, dan detail implementasi yang lebih baik dari pemilihan dan urutan metode. Gambar yang lebih besar ini memanggil metode abstrak dan non-abstrak untuk tugas yang dihadapi. Metode non-abstrak sepenuhnya dikendalikan oleh metode templat tetapi metode abstrak, diimplementasikan dalam subclass, memberikan kekuatan ekspresif pola dan tingkat kebebasan. Beberapa atau semua metode abstrak dapat dikhususkan dalam subkelas, memungkinkan penulis subkelas untuk memberikan perilaku tertentu dengan modifikasi minimal ke semantik yang lebih besar. Metode template (yang non-abstrak) tetap tidak berubah dalam pola ini, memastikan bahwa metode non-abstrak bawahan dan metode abstrak dipanggil dalam urutan yang dimaksudkan semula.
Memperbarui
Beberapa contoh nyata proyek yang telah saya kerjakan:
- berkomunikasi dengan sistem mainframe lama melalui berbagai "layar". Setiap layar memiliki banyak bidang, dengan nama tetap, posisi dan panjang, berisi bit data tertentu. Permintaan mengisi bidang tertentu dengan data tertentu. Respons mengembalikan data dalam satu atau beberapa bidang lainnya. Setiap transaksi mengikuti logika dasar yang sama, tetapi detailnya berbeda di setiap layar. Kami menggunakan Metode Templat di beberapa proyek yang berbeda untuk menerapkan kerangka tetap logika penanganan layar, sambil memungkinkan subkelas untuk menentukan detail khusus layar.
- mengekspor / mengimpor data konfigurasi dalam tabel DB ke / dari file Excel. Sekali lagi, skema dasar pemrosesan file Excel dan memasukkan / memperbarui catatan DB, atau membuang catatan ke Excel adalah sama untuk setiap tabel, tetapi detail setiap tabel berbeda. Jadi Metode Templat adalah pilihan yang sangat jelas untuk menghilangkan duplikasi kode dan membuat kode lebih mudah dipahami dan dipelihara.
- Membuat dokumen PDF. Setiap dokumen memiliki struktur yang sama, tetapi isinya berbeda setiap kali, tergantung banyak faktor. Sekali lagi, Metode Templat memudahkan untuk memisahkan kerangka tetap dari algoritme pembangkitan dari perincian khusus kasus yang dapat diubah. Faktanya. bahkan berlaku pada beberapa level di sini, karena dokumen terdiri dari beberapa bagian , yang masing-masing terdiri dari nol atau lebih bidang . Metode Templat diterapkan pada 3 tingkatan berbeda di sini.
Dalam dua kasus pertama, implementasi warisan asli menggunakan Strategi , menghasilkan banyak kode duplikat, yang tentu saja selama bertahun-tahun tumbuh perbedaan halus di sana-sini, mengandung banyak bug yang digandakan atau sedikit berbeda, dan sangat sulit untuk dipelihara. Refactoring ke Metode Templat (dan beberapa perangkat tambahan lainnya, seperti menggunakan anotasi Java) mengurangi ukuran kode sekitar 40-70%.
Ini hanya contoh terbaru yang muncul di benak saya. Saya bisa mengutip lebih banyak kasus dari hampir setiap proyek yang saya kerjakan sejauh ini.