Apakah ada antipattern untuk menggambarkan metode pengkodean ini? [Tutup]

Saya memiliki basis kode di mana programmer cenderung untuk membungkus hal-hal di area yang tidak masuk akal. Misalnya, mengingat log Kesalahan yang kami miliki, Anda dapat login

ErrorLog.Log(ex, "friendly message");

Dia menambahkan berbagai cara lain untuk menyelesaikan tugas yang sama persis. MISALNYA

SomeClass.Log(ex, "friendly message");

Yang hanya berbalik dan memanggil metode pertama. Ini menambah tingkat kompleksitas tanpa manfaat tambahan. Apakah ada pola anti untuk menggambarkan ini?

Hanya bermanfaat untuk menyebut beberapa kebiasaan pengkodean yang buruk sebagai Antipattern jika itu cukup tersebar luas.

Selebihnya kita sebut "kode sampah" ...

Jika saya menyarankan nama untuk kebiasaan buruk khusus ini, itu akan menjadi "Obsessive Abstraction Disorder" :-)

Tidak, ini bukan pola anti tetapi saya akan mengangkat masalah berikut.

Pelanggaran Prinsip Tanggung Jawab Tunggal

SRP mengatakan bahwa suatu kelas harus memiliki satu alasan untuk berubah. Menambahkan metode logger berarti bahwa kelas juga harus berubah jika log masuk harus diubah.

Pelanggaran a is-a hubungan

Kelas dasar bukan kotak alat tempat Anda dapat menambahkan beberapa metode kenyamanan.

Melakukannya secara efektif memasangkan semua kelas yang diwariskan dengan implementasi yang dimiliki kelas dasar.

Bandingkan dengan komposisi.

Bukan berarti ini membuatnya diterima tetapi ini bisa menjadi refactoring yang belum selesai. Mungkin SomeClass.log () memiliki logikanya sendiri dan diimplementasikan terlebih dahulu. Dan kemudian mereka menyadari bahwa mereka harus menggunakan ErrorLog.Log (). Jadi daripada mengubah 100 tempat di mana SomeClass.Log () dipanggil, mereka hanya didelegasikan ke ErrorLog.Log (). Secara pribadi saya akan mengubah semua referensi untuk ErrorLog.Log () atau setidaknya komentar SomeClass.log () untuk mengatakan mengapa ia mendelegasikan cara itu.

Hanya sesuatu yang perlu dipertimbangkan.

Istilah "Kode Lasagna" muncul di benak saya, meskipun ternyata itu berarti hal yang berbeda untuk orang yang berbeda . Penafsiran saya selalu "berlapis demi menjadi berlapis".

Saya tidak yakin untuk menggambarkan ini sebagai pelanggaran terhadap prinsip tanggung jawab tunggal, karena jika ada perubahan pada tanda tangan metode ErrorLog (metode yang dipanggil oleh SomeClass), setiap kode klien yang memanggil metode ini akan gagal.

Jelas ada cara untuk menggunakan warisan (atau membuat kelas yang perlu logging mengimplementasikan antarmuka logging) di sana.

Atau kita bisa melihat ini sebagai "momen yang bisa diajar" :)

Pengembang Anda mungkin setengah jalan ke ide yang bagus. Misalkan Anda ingin memiliki persyaratan bahwa semua objek bisnis Anda mampu melakukan pencatatan yang cerdas. Anda mungkin mendefinisikan:

   public interface IBusinessObjectLogger
   {
       void Log(Exception ex, string logMessage)
   }

Sekarang internal ke objek Anda, Anda dapat menggunakan objek ErrorLog untuk benar-benar melakukan logging sementara kode SomeClass menambahkan nilai spesifik objek ke pesan log. Selanjutnya Anda dapat memperluas API logging untuk menerapkan fungsionalitas logging berbasis file, berbasis db, atau berbasis pesan tanpa menyentuh objek bisnis Anda.

Saya tidak yakin ini otomatis jahat.

Jika Anda memanggil SomeClass. Log itu tentu saja jahat, tetapi jika Log hanya digunakan dari dalam SomeClass, itu akan memotong kopling dan saya akan menyebutnya dapat diterima.

Ini sebenarnya cukup umum dalam gaya pengkodean tertentu, dan dasar-dasar dari garis pemikiran itu sendiri bukanlah anti-pola.

Ini sangat mungkin hasil dari seseorang yang mengkode berdasarkan kebutuhan tanpa sepengetahuan basis kode yang lebih luas: "OK, kode ini perlu mencatat kesalahan, tetapi fungsi itu bukan tujuan utama kode. Oleh karena itu, saya memerlukan metode / kelas yang akan melakukan itu untuk saya". Itu cara berpikir yang bagus; tetapi, tanpa mengetahui ErrorLog ada, mereka menciptakan SomeClass. Mereka kemudian menemukan ErrorLog di beberapa titik kemudian, dan alih-alih mengganti semua penggunaan metode yang mereka masukkan, mereka membuat metode panggilan mereka ErrorLog. Itu adalah di mana ini menjadi masalah.

Kompleksitas tidak disengaja adalah kompleksitas yang muncul dalam program komputer atau proses pengembangannya yang tidak esensial untuk masalah yang harus dipecahkan. Sementara kompleksitas esensial adalah inheren dan tidak dapat dihindari, kompleksitas tidak disengaja disebabkan oleh pendekatan yang dipilih untuk menyelesaikan masalah.

http://en.wikipedia.org/wiki/Accidental_complexity

Ini mungkin merupakan penyalahgunaan / kesalahpahaman dari Pola Fasad . Saya telah melihat hal-hal serupa dalam basis kode yang telah saya kerjakan. Para pengembang melewati fase ketika mereka tergila-gila dengan pola desain tanpa memahami prinsip-prinsip menyeluruh desain OO.

Penyalahgunaan pola Facade menghasilkan kaburnya tingkat abstraksi di seluruh lapisan aplikasi.

Apa yang dilakukan programmer ini adalah membungkus beberapa kode, sehingga tidak memiliki ketergantungan langsung pada modul logging. Tanpa informasi yang lebih spesifik, tidak mungkin untuk memberikan pola yang lebih spesifik. (Bahwa pembungkus ini tidak berguna adalah pendapat Anda yang tidak mungkin disetujui atau tidak disetujui tanpa informasi lebih lanjut.)

Pola-pola yang mungkin termasuk dalam hal ini adalah Proksi , Delegasi , Dekorator , Komposit atau semacamnya yang berkaitan dengan membungkus, menyembunyikan, atau mendistribusikan panggilan. Mungkin salah satu dari hal-hal seperti itu dalam keadaan perkembangan yang tidak lengkap.

Saya bisa membayangkannya sebagai perbedaan budaya. Mungkin ada alasan bagus untuk memiliki fungsi duplikat dalam basis kode khusus ini. Saya bisa membayangkan kemudahan menulis menjadi alasan seperti itu. Programmer Python dalam diriku masih akan mengatakan itu buruk, karena " Seharusnya ada satu - dan lebih disukai hanya satu - cara yang jelas untuk melakukannya. ", Tetapi beberapa orang Perl mungkin terbiasa dengan kenyataan bahwa " Ada lebih dari satu cara untuk melakukannya ".