it-swarm-id.com

Kapan saya harus menggunakan — dan tidak menggunakan — pola desain?

Di pertanyaan saya sebelumnya tentang Stack Overflow , FredOverflow disebutkan dalam komentar:

Perhatikan bahwa pola tidak secara ajaib meningkatkan kualitas kode Anda.

dan

Ukuran kualitas apa pun bisa Anda bayangkan. Pola bukanlah obat mujarab. Saya pernah menulis permainan Tetris dengan sekitar 100 kelas yang menggabungkan semua pola yang saya tahu pada saat itu. Mengapa menggunakan simple if/else jika Anda bisa menggunakan sebuah pola? OO bagus, dan polanya bahkan lebih baik, bukan? Tidak, itu omong kosong yang mengerikan, rekayasa berlebihan.

Saya cukup bingung dengan komentar-komentar ini: Saya tahu pola desain membantu membuat kode dapat digunakan kembali dan dibaca, tetapi kapan saya harus menggunakan pola desain yang digunakan dan mungkin yang lebih penting, kapan saya harus menghindari terbawa olehnya?

57
ashmish2

CIUMAN pertama, pola nanti, mungkin jauh kemudian. Sebagian besar pola adalah keadaan pikiran. Jangan pernah mencoba memaksakan kode Anda ke dalam pola tertentu, lebih baik perhatikan pola mana yang mulai mengkristal dari kode Anda dan bantu mereka sedikit.

Memutuskan "ok, saya akan menulis sebuah program yang tidak menggunakan pola Y" adalah resep untuk bencana. Ini mungkin bekerja untuk halo program kelas dunia yang cocok untuk menunjukkan konstruksi kode untuk pola, tetapi tidak lebih.

99
jwenting

Saya pikir perhatian utama adalah bahwa orang sering memiliki kecenderungan untuk menyalahgunakan pola desain. Mereka belajar sedikit, melihat manfaatnya, dan tanpa disadari mengubah beberapa pola itu menjadi semacam palu emas yang kemudian mereka terapkan pada semuanya.

Kuncinya tidak harus mempelajari pola itu sendiri. Kuncinya adalah belajar mengidentifikasi skenario dan masalah yang dimaksudkan untuk mengatasi pola tersebut. Maka menerapkan pola itu hanyalah masalah menggunakan alat yang tepat untuk pekerjaan itu. Ini adalah pekerjaan yang harus diidentifikasi dan dipahami sebelum alat dapat dipilih.

Dan terkadang ini adalah pengaturan yang aneh dan tidak ada pola potong dan kering untuk menyelesaikannya langsung dari kotak. Pada saat itu perhatian lebih perlu diberikan pada masalah daripada solusinya. Pecah ke dalam masalah komponen, identifikasi bidang masalah yang memiliki sifat yang sama dengan masalah yang ditangani oleh pola yang diketahui, sesuaikan pola agar sesuai dengan masalah, dll.

52
David

Pola desain bekerja paling baik bila digunakan sebagai bahasa umum di tim Anda.

Maksud saya, Anda dapat mengatakan sesuatu seperti "kelas ini adalah Singleton yang mengimplementasikan IHairyWidget kami Pabrik Abstrak " dan semua orang di tim Anda memahami apa artinya itu tanpa harus masuk ke penjelasan terperinci.

Di mana Pola Desain gagal adalah ketika tim tidak memahaminya, atau ketika mereka terlalu sering digunakan sehingga mereka berhenti membuat desain lebih jelas dan malah membuatnya lebih sulit untuk memahami apa yang sebenarnya terjadi.

24
GrahamS

mungkin sedikit keluar dari topik, tapi saya pikir itu mencakup pertanyaan Anda juga: Saya akan menyarankan Anda buku yang bagus Refactoring to Patterns :

Buku ini memperkenalkan teori dan praktik refactoring terarah-pola: urutan refactoring tingkat rendah yang memungkinkan desainer untuk dengan aman memindahkan desain ke, ke arah, atau jauh dari implementasi pola . Menggunakan kode dari proyek dunia nyata, Kerievsky mendokumentasikan pemikiran dan langkah-langkah yang mendasari lebih dari dua lusin transformasi desain berbasis pola. Sepanjang jalan ia menawarkan wawasan tentang perbedaan pola dan bagaimana menerapkan pola dengan cara yang paling sederhana.

anda akan menemukan contoh ketika pola desain yang baik untuk digunakan, serta ketika Anda harus pergi dari mereka, bukan untuk membuat aplikasi terlalu rumit. Dan ya, ide utamanya adalah menjaga semuanya sesederhana mungkin.

Jawaban/saran yang bagus untuk pertanyaan Anda ada di artikel Apakah Anda Mengenali 4 Tanda Peringatan Dini dari Penyalahgunaan Pola Desain? , tapi saya tidak dapat memuatnya sekarang, galat 500. Itu tidak besar, jadi saya baru saja menggunakan cache Google untuk mendapatkannya:

Pola desain perangkat lunak dapat dan memang mengarah ke rekayasa berlebihan

Rekayasa berlebihan adalah proses menyulitkan sesuatu. Dalam hal pemrograman, membuat kode Anda lebih kompleks dan mungkin lebih fleksibel daripada yang seharusnya. Lebih khusus lagi, menerapkan pola desain perangkat lunak yang kompleks pada masalah sederhana.

1. Mulai sederhana, tidak rumit

Bagaimana ini bisa terjadi? Biasanya Anda memprogram dalam fungsionalitas tambahan yang Anda antisipasi akan digunakan atau terbukti bermanfaat nantinya. Tetapi apa yang terjadi jika kebutuhan ini tidak pernah terwujud? Dalam kebanyakan kasus, cruft dibiarkan di sana. Itu tidak bisa dihapus. Jadi sistem perangkat lunak terus tumbuh dalam ukuran dan kompleksitas dengan semua fitur ini yang tidak pernah digunakan.

2. Waspadai tanda-tanda

Ini mungkin berbeda untuk semua orang, tetapi saya menduga dalam banyak kasus, ini bukan upaya yang sadar. Melainkan, itu adalah sesuatu yang disebabkan oleh rasa takut akan terjebak dengan desain yang canggung, tidak pantas, tidak pantas atau sederhananya,; terjebak dengan sesuatu yang tidak cukup fleksibel. Ironisnya, jika Anda sampai pada titik over engineering atau menerapkan pola Anda segera kembali ke tempat Anda memulai.

Pola desain perangkat lunak menarik bagi programmer atau pengembang karena memungkinkan mereka untuk mengekspresikan dan membuat arsitektur yang indah secara alami. Itu adalah bagian dari menikmati pemrograman kreatif.

3. Pertimbangkan refactoring ke suatu pola daripada mulai dari satu

Apa yang mungkin menjadi cara yang baik untuk menghindari penyalahgunaan pola desain ini? Pertimbangkan refactoring ke suatu pola daripada mulai dari satu. Jangan mulai mencoba memaksakan suatu pola ke dalam desain Anda. Kemungkinan desain Anda bisa lebih sederhana tanpa itu. Jika Anda menemukan pada tahap selanjutnya bahwa desain Anda benar-benar dapat mengambil manfaat dari pola terstruktur, maka refactor untuk memungkinkannya. Saat Anda mendesain, selesaikan masalah dengan cara sesederhana mungkin. Perangkat lunak ringan sederhana selalu merupakan hal yang baik. Ada cara yang lebih baik untuk menghindari alternatif yang kurang direkayasa di mana Anda terjebak dengan desain atau solusi yang tidak cukup fleksibel atau tidak sesuai dengan masalah.

4. Jangan memaksakan diri Anda untuk memperbaikinya pertama kali

Memaksa pola atau struktur desain perangkat lunak ke dalam desain bukan jawabannya, itu hanya desain yang buruk. Tetapi membuat prototipe atau membangun build0 awal (bukti konsep build sebelum produksi pada produk yang sebenarnya dimulai) dapat membantu menghindari hal ini dan masalah over-engineering. Karena Anda tidak merasa harus melakukannya dengan benar pertama kali.

URL asli (sekarang mati): http://codelines.net.au/article/do-you-recognise-the-4-early-warning-signs-of-design-pattern-abuse/

14
Maxym

kapan harus berhenti melakukan semuanya menggunakan pola?

Pertanyaannya adalah kapan Anda mulai melakukan semuanya menggunakan pola? Tidak semua solusi cocok dengan pola desain yang ada dan mengadopsi pola dapat berarti bahwa Anda memperkeruh kebersihan solusi Anda. Anda mungkin menemukan bahwa alih-alih pola desain memecahkan masalah Anda, Anda menghasilkan masalah lebih lanjut dengan mencoba memaksa solusi Anda agar sesuai pola desain.

Jelas, jika Anda memilih pola desain yang benar untuk skenario tertentu maka Anda tidak akan memiliki masalah, namun memilih yang benar lebih mudah diucapkan daripada dilakukan.

Saya telah melihat terlalu banyak pola dalam proyek di mana mereka benar-benar tidak perlu.

Saya pikir kuncinya adalah - Cobalah untuk menjaga kode Anda bersih, modular dan mudah dibaca dan pastikan kelas Anda tidak digabungkan dengan erat =. Akhirnya Anda mungkin melihat bahwa Anda secara tidak sengaja menggunakan variasi pada pola desain standar. Mungkin Anda akan menyadari ini pada awal proyek Anda sebelum Anda mulai coding. Jika Anda kode seperti kebanyakan orang yang saya kenal (termasuk saya), maka mungkin tidak :)

9
El Ronnoco

Nah, yang terpenting adalah mengetahui masalah yang sedang Anda pecahkan. Daripada Anda perlu memutuskan apakah memperkenalkan beberapa pola akan memberi Anda beberapa keuntungan daripada tidak menggunakannya (mendapatkan kinerja, kesederhanaan atau apa pun). Pertanyaan terkait: https://stackoverflow.com/questions/85272/how-do-you-know-when-to-use-design-patterns

5
sinek

Tidak. dari desain-pola yang disebutkan dalam teks asli/de-facto go-to pada subjek, yaitu GoF membutuhkan cukup banyak pengalaman dan sering membaca ulang, dan menyerbu otak dengan kolega yang kompeten untuk dikuasai. Pasca tahap itu, diberi masalah, diberikan arsitektur, seringkali pola desain yang paling alami keluar dengan cara yang cukup jelas. Namun, setiap upaya untuk memaksa-menyesuaikan desain-pola dengan masalah, atau memetakan masalah-pola-desain penuh dengan bahaya, dalam hal ini yang terbaik adalah berkonsultasi dengan para ahli, sedikit-badai otak dan menganggapnya sebagai pengalaman belajar. Kecuali Anda cukup nyaman dengan pola desain 10-aneh yang biasa digunakan, ini akan tetap sedikit rumit, dan AFAIK, tidak ada pintasan.

Saya telah menemukan jutaan proyek kode SLOC C++ dengan banyak contoh pola desain force-fit, jadi kesalahan s.a. terlalu sering tidak terlalu umum.

4
icarus74

Agak seperti ini dengan topik apa pun yang mengharuskan Anda untuk mempelajari dan menerapkan aturan :

  1. Jika Anda seorang pemula, Anda harus mengikuti aturan karena Anda tidak tahu yang lebih baik.
  2. Jika Anda seorang amatir, Anda mengikuti peran karena Anda tahu mengapa Anda membutuhkannya.
  3. Jika Anda seorang profesional, Anda bekerja dengan aturan daripada menentangnya, tahu benar apa yang harus digunakan di mana dan kapan mereka tidak berlaku.
  4. Jika Anda seorang ahli, Anda mengabaikan aturan.
  5. Jika Anda menguasai seni Anda, Anda lebih suka aturan karena kode Anda harus dilihat oleh kategori 1-3 orang juga. :)

Ini sama dengan seni bela diri, melukis, menulis, sepak bola, mekanik, balap, dll ...

Sebagai seorang pria # 5, Anda biasanya mengajarkan orang-orang # 1 - 4 cara untuk menjadi yang teratas, jadi itu selalu berlaku, bahkan dalam konteks kompetitif.

( Cara Melampaui dan Mengabaikan Aturan menjelaskan hal ini secara umum, tetapi mungkin ada esai yang lebih baik di luar sana.)

4
Macke

Aturannya adalah tidak ada aturan. Pengalaman Anda (sukses lebih dari kegagalan) akan memberi tahu Anda kapan harus menggunakannya murni, kapan harus menyesuaikannya atau kapan tidak menggunakannya sama sekali.

Ada presentasi oleh Dan North di mana ia berbicara sedikit tentang pembelajaran dan pola

3
Augusto

Buat semuanya sesederhana mungkin. Namun, jika Anda harus menyelesaikan masalah, Anda mungkin ingin menggunakan pola desain, daripada menciptakan kembali roda, karena banyak pola desain memberikan solusi untuk masalah umum. Tapi seperti yang saya katakan: gunakan saja saat benar-benar dibutuhkan.

2
Puce

Mungkin menggunakan KISS DRY SoC pola (ya, mungkin itu bukan pola, tapi kedengarannya menyenangkan)).

Tetap Sederhana, Bodoh.
Jangan Ulangi Diri Anda Sendiri.
Pemisahan Kekhawatiran.

Saya pikir ketiga poin ini harus menjadi inspirasi bagi setiap programmer.

2
Fredrik Norlin

Masalah dengan "pola" adalah bahwa apa pun dapat dianggap sebagai pola, dan sering kali demikian.

Saya telah mengembangkan kode secara profesional sejak lama sebelum saya pertama kali mendengar seseorang berbicara tentang 'pola', dan saya berhasil dengan baik selama bertahun-tahun. Bahkan, ketika saya melihat ke belakang, banyak hal yang saya tulis sebenarnya mengikuti beberapa pola yang terkenal, setidaknya sampai batas tertentu.

Maksud saya adalah mengikuti suatu pola tertentu dengan kaku bukanlah jawabannya. Belajar tentang pola-pola baru, tetapi jangan membuat Anda terikat pada mereka: Mereka akan berubah. Praktik pengkodean yang baik hari ini tidak sama dengan praktik pengkodean yang baik sepuluh tahun yang lalu, dan tidak peduli seberapa pintar programmer saat ini, Anda dapat yakin bahwa sepuluh tahun ke depan, hal-hal yang dianggap praktik pengkodean yang baik hari ini akan terlampaui.

Di luar topik: Pada catatan pribadi, saya sangat membenci penggunaan 'pola' Kata dalam konteks ini. Ini berbau jargon yang tidak perlu.

1
Spudley

Biasanya pola desain digunakan untuk menjelaskan kepada khalayak luas apa kode Anda sebenarnya. Dengan cara ini memudahkan orang untuk memahami apa yang Anda lakukan. Orang jarang menggunakannya sebagai referensi untuk mencari solusi, karena sebuah pola dapat diimplementasikan dengan berbagai cara.

0
Gaurav Sehgal

Cara Anda menyusun logika kode harus memungkinkan pendatang baru ke kode tersebut untuk dapat menafsirkannya dan memodifikasinya. Memiliki pola hanya karena ini adalah praktik terbaik tidak akan membawa Anda ke mana pun jika Anda tidak sepenuhnya memahami konteks tentang bagaimana, siapa, dan di mana kode itu dan berpotensi digunakan.

Pola "Tetap sederhana" lebih merupakan hal yang masuk akal daripada pola dan harus menjadi bagian dari proses berpikir pengembang saat membuat kode. Dengan asumsi bahwa setiap orang mendapatkan pola tertentu juga tidak benar juga. Idealnya Anda menginginkan pola yang dapat dibaca dan diidentifikasi tanpa begitu banyak pengetahuan tentangnya.

0
Oscar Villarreal

Aku akan tahu saja. Maksudku, aku bahkan menggunakan pola desain sebelum aku tahu definisi pola desain. Itu hanya coding yang bagus. Kadang-kadang Anda akan dapat mengenalinya saat menulis perbaikan proyek dan kadang-kadang Anda harus memperbaiki kode Anda.

jwenting berkata KISS dulu, pola kemudian . Saya pikir pola adalah cara untuk [~ # ~] mencium [~ # ~] proyek karena Anda dapat menerapkan sesuatu yang Anda tahu itu berfungsi dan akan menyimpan waktu Anda di masa depan.

Satu-satunya hal yang bisa salah adalah bahwa ada banyak cara untuk menerapkan pola desain tunggal, bahkan dalam bahasa yang sama, jadi Anda perlu mengerti sepenuhnya apa masalah Anda.

0
dierre