Pola desain apa yang paling buruk atau paling sempit? [Tutup]


28

Untuk setiap proyek pemrograman, manajer dengan pengalaman pemrograman masa lalu mencoba bersinar ketika mereka merekomendasikan beberapa pola desain untuk proyek Anda. Saya suka pola desain ketika mereka masuk akal atau jika Anda membutuhkan solusi scalable. Saya telah menggunakan pola Proxy, Pengamat dan Komando dalam cara yang positif misalnya, dan melakukannya setiap hari. Tetapi saya benar-benar ragu untuk menggunakan katakan pola Pabrik jika hanya ada satu cara untuk membuat objek, karena pabrik mungkin membuat semuanya lebih mudah di masa depan, tetapi menyulitkan kode dan overhead murni.

Jadi, pertanyaan saya adalah sehubungan dengan karier masa depan saya dan jawaban saya untuk tipe manajer yang melemparkan nama-nama pola acak:

Pola desain mana yang Anda gunakan, yang membuat Anda kembali secara keseluruhan? Mana pola desain terburuk , yang harus Anda pertimbangkan kecuali dalam satu situasi tunggal di mana mereka masuk akal (baca: pola desain mana yang didefinisikan dengan sangat sempit)? (Sepertinya saya mencari ulasan negatif dari keseluruhan produk bagus Amazon untuk melihat apa yang paling disadap orang dalam menggunakan pola desain.) Dan saya tidak berbicara tentang Anti-Pola di sini, tetapi tentang Pola yang biasanya dianggap sebagai pola "baik".

Sunting: Seperti yang dijawab oleh beberapa orang, masalahnya paling sering adalah bahwa pola tidak "buruk" tetapi "salah digunakan". Jika Anda tahu pola, yang sering disalahgunakan atau bahkan sulit digunakan, mereka juga cocok sebagai jawaban.


Kebanyakan pola membuat perubahan di masa depan mudah pada beberapa sumbu perubahan, tetapi mereka dapat membuat perubahan lebih sulit pada sumbu perubahan lainnya. Geng empat buku sangat pandai mengatakan kapan suatu pola berlaku. Banyak buku tentang pola yang ketinggalan titik ini. Ambil pola Pengunjung sebagai contoh. Itu membuatnya mudah untuk menambahkan algoritma traversal pohon baru, tetapi membuatnya lebih sulit untuk menambahkan jenis node baru ke pohon. Ini juga memungkinkan algoritma traversal berada di lapisan yang lebih tinggi daripada pohon. Anda perlu mempertimbangkan sumbu perubahan mana yang paling tidak stabil dan desain untuk membuat perubahan di sepanjang sumbu itu mudah.
Theodore Norvell

Semua itu ada di buku 'Gang Empat'.
Miles Rout

Jawaban:


40

Saya tidak percaya pada pola yang buruk, saya percaya bahwa pola dapat diterapkan dengan buruk!

  • IMHO singleton adalah pola yang paling banyak disalahgunakan dan diterapkan secara salah. Orang-orang tampaknya mendapatkan penyakit tunggal dan mulai melihat kemungkinan untuk lajang di mana saja tanpa mempertimbangkan alternatif.
  • Pola pengunjung IMHO memiliki penggunaan yang paling sempit dan hampir tidak akan ada kompleksitas tambahan yang dibenarkan. PDF yang bagus dapat diperoleh di sini . Benar-benar hanya ketika Anda memiliki struktur data yang Anda tahu akan dilalui saat melakukan operasi yang berbeda pada struktur data tanpa mengetahui semua cara di muka, berikan kesempatan kepada pengunjung pola pertempuran. Sangat cantik :)

Untuk jawaban ini saya hanya mempertimbangkan pola GOF. Saya tidak tahu semua pola yang mungkin cukup baik untuk dipertimbangkan juga.


Saya melihat sangat sedikit kegunaan untuk Pengunjung. Lajang ... jangan mulai saya. Jika situasinya tidak sempurna, jangan gunakan itu.
Michael K

1
Mungkin ada sedikit kegunaan untuk Pengunjung, tetapi ketika ada itu pasti memecahkan masalah. Pemahaman saya adalah bahwa Vistor sangat penting untuk LINQ.
quentin-starin

12
Pola Pengunjung sangat penting untuk mengurangi (atau menghilangkan) kompleksitas siklomatik dalam program perangkat lunak. Kapan pun Anda memiliki pohon if / else atau pernyataan beralih, kemungkinan besar seorang Pengunjung dapat menggantinya, menawarkan eksekusi yang dijamin dan pemeriksaan waktu kompilasi. Pengunjung adalah salah satu pola paling kuat yang saya tahu, dan kami menggunakannya secara teratur dengan efek yang luar biasa. Itu membuat pengujian mimpi juga.
Les Hazlewood

@LesHazlewood Bukankah Pengunjung hanya merupakan solusi untuk bahasa pemrograman yang tidak memadai? Bahasa seperti ML (Haskell, SML, OCaml, dll.) Memiliki tipe data aljabar ("penyatuan steroid") dan pencocokan pola ("aktifkan steroid") yang menghasilkan kode lebih sederhana daripada Pengunjung, namun sepenuhnya diperiksa oleh kompiler. Dibandingkan dengan pengunjung, Anda tidak memiliki banyak metode yang status pembagiannya Anda perlukan untuk mengelola secara manual melalui properti objek. Dalam bahasa seperti ML, dan semua perbedaan huruf harus lengkap, jika tidak, tidak akan dikompilasi.
vog

14

Terlepas dari Singleton dan Pengunjung yang telah disebutkan oleh penjawab lain, saya tidak tahu pola desain "terkenal". IMHO masalah terbesar tidak berasal dari pola desain tertentu yang "salah", melainkan dari pengembang yang menerapkan pola terlalu bersemangat.

Hampir semua orang melewati fase "pola demam" ketika berkenalan dengan pola. Berpikir bahwa pola adalah hal terbaik sejak memotong roti, awalnya seseorang mencoba menerapkannya kapan saja dia melihat kemungkinan. Ini menghasilkan kode yang terkubur di bawah pola, di mana pola itu sendiri tidak membantu lagi, hanya membuat kode lebih sulit untuk dipahami dan dipelihara dalam jangka panjang.

Akhirnya, sebagian besar dari kita melewati fase ini dan mulai belajar bagaimana menggunakan pola untuk menyelesaikan masalah nyata, bukan untuk kepentingan mereka sendiri. Pola memiliki harganya, yang merupakan kompleksitas tambahan, dan menerapkan pola spesifik apa pun hanya dibenarkan ketika membayar kompleksitas tambahan dengan membantu menyederhanakan beberapa bagian lain dari sistem, sehingga membuat kode / konfigurasi secara keseluruhan lebih mudah untuk dipahami dan dipelihara. Jika bukan ini masalahnya, sering kali lebih baik menjauhi pola, bertahan dengan solusi paling sederhana yang mungkin bisa berhasil.


Benar. Pola-pola itu tidak baik atau jahat, mereka diterapkan dengan baik atau salah diterapkan.

Saya lebih suka mengajar orang seperti yang saya pelajari: OO pertama, memahami bagaimana objek berhubungan, dan kemudian belajar nama-nama pola. Terlalu mudah untuk berpikir dalam hal pola daripada apa yang perlu dilakukan. Mereka adalah alat komunikasi.
Michael K

Pola adalah sarana untuk berkomunikasi, bukan daftar preskriptif. Jika Anda mulai dengan pola dalam pikiran, Anda mungkin salah menerapkannya. Jika Anda menemukan satu, atau petunjuk dari satu, dalam desain Anda, maka katalog pola dapat membantu Anda memahami apa lagi yang Anda butuhkan.
Rob Crawford

14

Saya akan mengambil risiko di sini dan menyarankan penggunaan warisan yang berlebihan. Jelas paling berlaku dalam bahasa tanpa dukungan polimorfisme waktu kompilasi yang solid, seperti Java. Warisan run-time adalah alat, bukan semacam keajaiban satu fitur yang cocok untuk semua.

Orang lain telah menyatakan hal yang serupa dengan kebencian pribadi saya terhadap Singletons, jadi saya tidak akan membahasnya di sini.


10

Singleton. Ini adalah salah satu dari pola GOF yang sekarang lebih sering disebut sebagai anti-pola. Salah satu alasan untuk itu adalah Singleton membuat kode lebih sulit untuk diuji.


4
Ada banyak kelemahan mendasar dalam pola singleton, sebagian besar diilustrasikan dengan baik dalam artikel ini oleh Steve Yegge - Singleton Dianggap Bodoh
ocodo

Slomojo: Artikel bagus. Saya akan menyebutnya 'pola simpel' mulai sekarang:-)
Tidak ada

2
Ya, karena beberapa orang bodoh menyalahgunakan suatu pola dan benar-benar merindukan perahu tentang apa yang dimaksud dengan OO (dilihat dari semua kelas Manajer yang ia buat), Tentu saja itu adalah kesalahan pola dan bukan pengembang.
Dunk

Mengapa semua orang mengaitkan implementasi umum (dan merepotkan) Singleton dengan pola Singleton? Yang satu hampir selalu buruk, yang lain tidak.
quentin-starin

1
@qes> Singleton menimbulkan masalah implementasi penting (terutama dengan threading). Ini sudah merupakan poin yang buruk. Tapi, Anda juga akan mengetahui bahwa singleton adalah pola tentang bagaimana kelas digugat, dan bukan cara kerjanya. Bagaimana kelas digunakan harus ditangani oleh kode menggunakan kelas, jadi Singleton adalah pemecahan pemisahan masalah.
deadalnix

7

Jika Anda tahu pola, yang sering disalahgunakan atau bahkan sulit digunakan, mereka juga cocok sebagai jawaban.

Mengikuti pola MVVM untuk WPF terlalu ketat, seperti ditunjukkan misalnya dengan pertanyaan ini . Beberapa orang mencoba mengikuti panduan bahwa tidak boleh ada kode yang dimasukkan ke dalam kode terlalu ketat dan menghasilkan semua jenis peretasan yang eksotis.

Dan tentu saja, MVVM sulit sekali, dan tidak layak untuk proyek jangka pendek kecil.

WPF melakukan posting ironis tentang hal itu dalam artikelnya MV-poo .


@ Akku: Kamu tentu harus tahu bagaimana menggunakannya, jadi kamu bisa memutuskan apakah itu cocok untuk proyekmu. Jadi ya, itu penting untuk pengembangan WPF, dan sangat berguna.
Steven Jeuris

Salah satu masalah adalah bahwa orang-orang salah paham pola MVVM. Itu tidak "sulit sekali." Orang-orang membuatnya seperti itu dengan berpikir bahwa semua pola lain seperti Pola Perintah dan Pola Mediator adalah bagian darinya. Menurut saya sendiri, MVVM adalah salah satu pola paling sederhana. Saya setuju, bahwa mengikuti apa pun ke dunia itu konyol.
BK

5

Beberapa pola dalam buku GOF adalah spesifik C ++, dalam arti mereka kurang berlaku dalam bahasa dengan refleksi, misalnya pola Prototipe kurang signifikan di Jawa.

Saya menganggap pola Juru Bahasa sebagai 'sempit'. Anda harus memiliki masalah umum yang layak dikembangkan pemecah masalah umum. Ini hanya berfungsi untuk masalah khusus di mana Anda dapat menciptakan bahasa, mendefinisikan tata bahasa dan menulis juru bahasa. Contoh masalah harus dinyatakan sebagai kalimat dalam tata bahasa. Saya tidak berpikir Anda sering menemukan situasi seperti itu.


1
sebagian besar GOF hanya berlaku untuk OOP berbasis kelas statis. menyimpang sedikit dari bahasa-bahasa semacam itu dan buku itu menjadi sekadar anekdot hiburan.
Javier

5

Yang saya sesali paling sering (meskipun tidak paling keras): Ketika saya seharusnya baru saja membuat fungsi tetapi saya mengimplementasikan solusi OOP.


1
Mengapa? Apa yang membuatmu menyesal? Perluas jawaban Anda dan tambahkan pengalaman Anda.
Walter

Memang, saya pikir kelas dengan variabel lokal dan metode yang jelas JAUH lebih mudah untuk digunakan kembali daripada fungsi 200 baris tunggal yang hanya dapat diterapkan kembali melalui copy paste dan kemudian tidak hanya memiliki satu tempat untuk terlihat jelek dan tidak komprehensif.
Akku

2
KISS menyiratkan Anda menjadikannya fungsi terlebih dahulu, lalu refactor ke kelas jika diperlukan.
Eva

5

Pabrik. Saya telah melihat kode mengimplementasikannya yang hanya membuat satu jenis. Itu sama sekali kode IMO yang tidak berguna. Itu tidak membantu bahwa banyak contoh daring sepenuhnya dibuat-buat. Pabrik pizza?

Mungkin pabrik lebih mudah untuk diuji karena injeksi ketergantungan. Tetapi untuk menambahkan kode itu ketika Anda tidak membutuhkannya tidak ada gunanya bagi saya, dan argumen pengujian menghilang ketika Anda dapat menggunakan kerangka kerja tiruan seperti JMockit. Semakin mudah Anda membuat program, semakin baik. Pabrik hanya benar-benar masuk akal dengan jumlah tipe yang lebih besar (lebih besar, maksud saya setidaknya lebih dari 2).


Ya, pabrik Pizza, terima kasih untuk Head First Design Pattern ~
Niing

2

Singleton

Saya setuju dengan yang lain tentang Singleton. Bukan berarti Anda tidak boleh menggunakannya, hanya saja itu harus dibatasi untuk beberapa kasus. Mereka sering digunakan sebagai global malas.

Thread-safety adalah salah satu masalah dengan lajang. Penanganan pengecualian adalah hal lain - jika singleton gagal dibuat dengan benar - Anda tidak selalu tahu apakah Anda dapat menangkap kesalahan dengan aman, terutama jika itu salah satu objek yang dibuat "sebelum main". Dan kemudian ada masalah membersihkan setelah itu.

Saya cenderung lebih suka menggunakan satu singleton dan meminta semua lajang "wannabe" lainnya "berlangganan" untuk Anda. Penggunaan tunggal saya yang paling umum adalah penanganan "acara berteriak": Anda hanya "menyiarkan ke seluruh dunia" bahwa suatu peristiwa telah terjadi dan siapa pun yang mendengarkan yang akan menangani acara tersebut melakukannya. Dengan begitu Anda memisahkan peristiwa yang sebenarnya terjadi dengan apa yang mendengarkannya. (Logging, sinyal, dll.)

Pengunjung

Hal buruk yang saya temukan tentang hal ini, terlepas dari fakta bahwa pengembang tidak dapat memikirkan nama yang bermakna dan hanya memanggil metode kunjungan (), adalah bahwa hal itu menambah ekstensibilitas dalam satu arah sementara menghapusnya di yang lain, yaitu menambahkan fungsionalitas tambahan tetapi membatasi jumlah objek yang perlu diketahui pengunjung tentang semua jenis objek yang mungkin dikunjungi.

Dimungkinkan, meskipun berantakan, untuk memungkinkan ekstensi di kedua arah tetapi ini tidak sepenuhnya menggunakan pola pengunjung dalam bentuk regulernya. Aplikasi yang paling umum untuk ini adalah mencetak objek: Anda memiliki berbagai cara untuk mencetak objek dan objek berbeda yang perlu dicetak. Anda harus dapat memperpanjang ini di kedua arah. (Mencetak berarti segala jenis benda yang berubah menjadi aliran: menyimpan dalam file / menulis ke konsol / GUI .. dll).

(Catatan: Anda tidak harus membingungkan ini dengan arsitektur tampilan dokumen, yang merupakan pola yang sedikit berbeda).


2
Solusi Anda menggunakan argumen lama yang memisahkannya. Secara khusus, Anda memposting suatu acara dan beberapa orang lain menangani acara tersebut dan mencatatnya. Itu hal yang baik, karena semua orang dipisahkan! SALAH! Saya biasa melakukan itu, betapa menyakitkannya kerajaan itu. Saya menyadari bahwa jika saya ingin sesuatu dicatat, saya ingin secara eksplisit mengatakan mencatat hal yang tepat ini, di sini, sekarang, dalam kode pada titik terjadinya. Tidak memiliki objek lain yang mencari tahu apa yang harus dicatat, dengan kemungkinan peristiwa lain disela oleh penangan lain, jika bahkan dicatat sama sekali. Itu tidak lain adalah desain yang berbelit-belit.
Dunk

2

Saya pikir masalah dengan beberapa pola yang lebih kompleks adalah bahwa ada begitu banyak variasi pada mereka sehingga mereka kehilangan banyak nilainya sebagai alat komunikasi.

Pelaku terburuk yang bisa saya pikirkan dalam kategori ini adalah pola MVC. Bahkan jika kita mengabaikan MVP, ada begitu banyak variasi dalam peran masing-masing item ini sehingga Anda harus menghabiskan waktu satu jam di setiap kerangka kerja baru untuk mencari tahu di mana letak batas-batasnya.


Saya juga berpikir bahwa MVC harus digunakan di mana-mana, tetapi tidak diimplementasikan dengan cara yang sama di mana-mana. Dan banyak orang tidak memahaminya. Ketika saya pertama kali ingin menggunakannya, saya membuat tiga kelas bernama Model, View (bentuk windows) dan Controller. Itu berantakan, karena formulir tidak dibuat untuk MVC.
Akku

1

Tidak ada pola buruk hanya orang jahat.

Saya lebih suka mewarisi kode yang mudah dibaca yang melakukan sesuatu yang jelas tetapi sedikit verbose atau tidak (antrian musik villian jahat) dapat digunakan kembali (terkesiap!) Daripada beberapa mash mash of InheritAbstractTemplateFaucetSink<Kitchen> .

Kode yang dapat digunakan kembali bagus! Kemungkinan Anda tidak menulis kode yang akan digunakan kembali atau menulis ulang logika serupa untuk aplikasi lain akan membawa Anda lebih sedikit waktu daripada beberapa upaya gila untuk menggunakan kembali beberapa kode aplikasi lain.

Untuk membaca lebih lanjut, buka beberapa kode C di implementasi waras dari header posix atau clibs dan mainkan polanya. Kode ini ditulis oleh beberapa programmer paling cerdas dan paling berdedikasi di dunia. Apakah Anda tahu berapa banyak Pola Pabrik Abstrak yang akan Anda lihat? ... TIDAK ADA !. Peluang yang lebih baik adalah jika Anda memahami bagian lain dari apa yang terjadi, Anda akan menemukan logika yang sangat mudah dipahami dan dilacak.

Maksud saya adalah ini sebagian besar "pola" tidak dibuat untuk membuat kode lebih baik mereka diciptakan untuk menjual buku dan perangkat lunak pemodelan. Jika Anda pandai pemrograman Anda mungkin akan menghindari sebagian besar dari ini dan menulis kode yang dirancang jelas, ringkas, dan cerdik yang memecahkan masalah Anda. Ketika Anda memiliki masalah lain, Anda akan menulis kode yang jelas, ringkas, dan cerdik untuk memecahkan masalah itu. Jika tujuan Anda adalah untuk menulis lebih sedikit kode daripada yang saya kira Anda tidak cocok menjadi seorang programmer. Saya suka menulis kode dan ingin menulis sebanyak mungkin. Ketika saya menulis ulang sesuatu yang sudah saya tulis, saya melakukannya puluhan kali lebih cepat dan bisa menyingkirkan semua hal yang tidak saya sukai dengan pertama kali saya melakukannya.

Dengan itu saya akan meninggalkan Anda mungkin dengan kutipan (relevan) terbaik dalam ilmu komputer.

" Ada dua cara membangun desain perangkat lunak: Salah satu caranya adalah membuatnya begitu sederhana sehingga jelas tidak ada kekurangan, dan cara lainnya adalah membuatnya sangat rumit sehingga tidak ada kekurangan yang jelas. Metode pertama jauh lebih sulit." . "

  • Tony Hoare (penemu quicksort, bapak desain OS modern, pencipta logika Hoare, dan penerima penghargaan Turing)

0

Saya setuju bahwa ada waktu untuk sebagian besar pola, dan Anda dapat menyalahgunakan banyak pola. Saya tahu salah satu yang paling banyak saya lecehkan di masa lalu adalah pola Template Abstrak. Diambil sepenuhnya itu dikenal sebagai ASP.NET webforms.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.