Tidak dapat memahami pola desain pemrograman

16

Saya telah bekerja dengan javascript selama 4 tahun terakhir. Saya sangat yakin dengan kemampuan memecahkan masalah saya dan saya dapat melihat bahwa kualitas kode saya meningkat. Saya mencoba untuk tetap mengikuti perkembangan komunitas dan saat ini saya bekerja dengan ES2015 dan React.js. Namun, saya merasa tidak bisa memahami pola desain pemrograman sama sekali. Saya tahu di mana menemukan sumber daya tentang ini dan saya sudah membaca buku tentang itu. Saya mengandalkan rekan kerja senior saya untuk membuat keputusan tentang struktur proyek tetapi saya tidak punya masalah untuk mengatasinya.

Setiap kali saya perlu memulai sesuatu sendiri, saya mencari dua jalur ini: Jika saya menggunakan perpustakaan besar / kerangka kerja seperti React.js, saya cenderung menyalin apa yang dilakukan komunitas; Jika saya menggunakan sesuatu yang lebih kecil saya akan menggunakan pola modul. Saya tahu bahwa begitu saya mendapatkan pemahaman yang lebih baik tentang hal ini saya akan dapat membuat keputusan yang lebih baik, tetapi untuk sekarang saya benar-benar bingung.

Haruskah saya mencari pendidikan yang unggul tentang ini? Apakah saya perlu seorang mentor tentang hal ini? Apakah saya bodoh? Apakah ini benar-benar sulit dimengerti?

design-patterns javascript Abensur
sumber
6
Menurut pendapat saya beberapa bahasa lebih 'memaafkan' daripada yang lain ketika datang ke perlunya menggunakan pola desain. Bahasa dikompilasi yang diketik dengan kuat (seperti Java dan C #) lebih dipengaruhi oleh desain yang buruk daripada bahasa scripting yang diketik dengan lemah seperti JavaScript dan PHP. Bukan untuk mengatakan pola desain tidak berguna untuk keduanya, tentu saja.
Matius
3
Ukuran proyek juga memainkan peran penting juga.
Matius
2
@Matthew nitpick Saya tidak akan selalu memanggil Java / C # sangat diketik ...
Jared Smith
2
@ JaredSmith benar, saya sering lupa perbedaan antara sangat diketik dan diketik secara statis.
Matius
6
Jika Anda mencoba untuk menguraikan pola dan secara umum , Stop! Tidak ada apa-apa di sana! Pola adalah solusi populer untuk masalah yang biasa terjadi, dan seseorang memberinya nama. Itu semua yang ada untuk itu. Anda mungkin merasa sulit untuk memahami beberapa pola tertentu - Saya sendiri kesulitan mengingat cara efektif menggunakan pola "pengunjung" untuk meniru pengiriman ganda di Jawa - Tetapi jika Anda mencari saus rahasia yang menghubungkan "pengunjung" untuk, katakan "objek transfer data," Anda tidak akan menemukannya. Itu hanya dua solusi populer untuk dua masalah umum, seseorang memberi mereka nama, dan nama itu macet.
Solomon Slow

Jawaban:

34

Pola Desain Perangkat Lunak adalah solusi terkenal untuk masalah terkenal. Cara Anda memahaminya adalah dengan mempelajari polanya, memahami cara kerjanya, dan mengetahui kapan waktu yang tepat untuk menerapkannya pada desain perangkat lunak Anda.

Cara Anda mempelajari pola desain perangkat lunak adalah dengan mempelajarinya, satu per satu. Ini adalah proses pendidikan berkelanjutan. Jika Anda ingin mengurangi jejak pembelajaran, pelajari pola-pola yang berhubungan langsung dengan teknologi yang Anda gunakan saat ini.

Beberapa hal penting yang perlu diketahui tentang pola desain:

  1. Beberapa pola desain bersifat arsitektur. MVC dan MVVM adalah contoh pola tersebut. Anda menggunakan pola seperti itu ketika Anda membutuhkan manfaat organisasi dan struktural yang mereka berikan.

  2. Beberapa pola desain adalah solusi untuk kekurangan dalam bahasa pemrograman. Anda tidak akan memerlukan pola-pola ini jika Anda menggunakan bahasa pemrograman yang lebih ekspresif, tetapi seringkali Anda tidak bisa membuat pilihan ini. Mayoritas pola GoF termasuk dalam kategori ini .

  3. Gunakan pola perangkat lunak hanya ketika Anda mencoba menyelesaikan masalah yang pola itu secara khusus dirancang untuk dipecahkan. Jika Anda menulis aplikasi dengan menyatukan pola perangkat lunak, Anda salah melakukannya.

  4. Tidak ada pola perangkat lunak yang ada untuk setiap masalah komputasi yang ada. Kalau begitu, pemrograman hanya akan menjadi latihan pencocokan pola.

  5. Beberapa pola sebenarnya anti-pola. Kompleksitas tambahan yang diperkenalkan oleh pola-pola ini melebihi manfaat yang mereka berikan. Anda harus memutuskan sendiri, berdasarkan pola-demi-pola, pola mana yang akan Anda hindari.

Robert Harvey
sumber
Jawaban yang bagus, meskipun saya tidak setuju dengan pernyataan bahwa sebagian besar pola GoF adalah solusi untuk kekurangan dalam bahasa pemrograman. Seringkali, beberapa pola lebih baik diterapkan pada bahasa tertentu, ya, karena bahasa cenderung dirancang dengan masalah dan solusi tertentu.
Polygnome
1
Pola Gof berusia 20 tahun. Kebanyakan dari mereka diciptakan untuk memperbaiki masalah dengan C ++, masalah yang diwariskan Java karena Java didasarkan pada C ++.
Robert Harvey
Paradoks dalam jawaban ini adalah bagian "masalah yang diketahui". Sulit untuk memahami "masalah-masalah terkenal" ini jika Anda belum pernah mengalaminya.
Fuhrmanator
2
Java tidak didasarkan pada C ++. Javas sintaks yang terinspirasi oleh C ++, tapi tentu tidak berdasarkan itu. kedua bahasa bekerja sangat berbeda. Dari fakta bahwa Java abstact hardware, mengelola memori dengan sendirinya, bukan karena tidak memiliki Template tetapi lebih pada generik dll.
Polygnome
4

Pendekatan setiap orang untuk belajar sedikit berbeda, dan saya tidak tahu apa pendekatan umum Anda, tetapi saya yakin Anda melakukan hal yang merugikan diri sendiri dengan menyebut diri Anda "bodoh".

Secara pribadi, dari pengamatan saya tentang apa yang oleh banyak orang disebut insinyur perangkat lunak "sukses", desainer dll semua memiliki tema yang sama untuk pembelajaran mereka: "pengalaman". Saya percaya ini menjadi "pendidikan superior" Anda dan Anda akan belajar lebih cepat darinya daripada membeli banyak buku di amazon dan membacanya (kebiasaan buruk saya).

Jadi, misalnya, ambil pola GOF seperti pola perintah dan implementasikan dalam pilihan bahasa Anda. Pahami apa manfaatnya bagi Anda dan kelemahannya. Berbagai buku tentang pola desain akan menjelaskan hal ini kepada Anda, tetapi saya merasa lebih baik untuk menerapkan pengetahuan itu secara praktis dan belajar darinya. Jangan mengabaikan bahan bacaan, mereka memiliki tujuan, tetapi dunia IT bukanlah latihan buku teks. Yang sedang berkata, itulah pendapat dan pandangan saya tentang dunia TI dan sebagian, mewakili perjuangan sendiri ketika memulai karir saya di bidang rekayasa perangkat lunak. Juga, masalah utama yang saya lihat, bahkan dengan pengembang perangkat lunak yang sangat berpengalaman adalah ketidaksabaran dan lupa untuk menikmati apa yang mereka lakukan. Jadi luangkan waktu Anda dengan apa yang Anda pelajari dan ingat untuk benar-benar menikmati apa yang Anda lakukan, jika tidak, mengapa repot-repot menginvestasikan waktu di dalamnya?

Selain itu, manfaatkan pengalaman praktis orang lain. Ada sejumlah besar solusi open source, baik yang buruk maupun yang baik dan Anda bisa belajar darinya. Lihatlah bagaimana mereka menerapkan pola dan pikirkan bagaimana Anda akan mengatasinya secara berbeda.

Jadi, saran umum saya adalah jika Anda merasa pendekatan Anda salah, ubahlah. Lihatlah orang-orang di sekitar Anda yang Anda rasa sedang mempelajari materi yang Anda rasa tidak Anda pahami dan lihat apa yang mereka lakukan atau bahkan tanyakan pada mereka.

Planet terpencil
sumber
1
Saya benar-benar berpikir bahwa pemrograman itu seperti permainan catur. Anda mungkin memiliki beberapa bakat asli di dalamnya, Anda mungkin memainkannya sepanjang hari, tetapi jika Anda tidak membaca beberapa buku tentang catur, Anda tidak dapat melakukan kemajuan apa pun dan yang lebih penting Anda tidak bisa menghargai keindahan permainan.
Adrian Iftode
@AdrianIftode - setuju. Seperti yang disebutkan, saya tidak akan mengabaikan buku, blog, atau bahan bacaan apa pun, tetapi ini adalah masalah umum yang saya temukan dengan orang-orang yang berjuang untuk penguasaan dalam bahasa pemrograman / platform / kerangka kerja dll dan tampaknya mereka telah melakukan sedikit pengkodean dan / atau praktis usaha, tetapi telah membaca setiap buku yang bisa Anda goyang.
Desolate Planet
@AdrianIftode Yah, tidak tepat. Bermain catur tanpa membaca buku, Anda masih bisa belajar banyak tentang permainan. Satu-satunya perbedaan adalah, bahwa Anda tidak belajar secepat mungkin dengan menggambar beberapa pengalaman dan pemikiran catur. Di sisi lain, dengan memikirkan diri sendiri tentang hal-hal tertentu, Anda mungkin menemukan satu atau dua solusi yang telah diabaikan oleh orang-orang yang hanya belajar dari catur, dan yang mungkin Anda gunakan untuk keuntungan Anda. Pada akhirnya, saya percaya campuran dari kedua jenis pembelajaran memberikan manfaat terbaik. Dalam catur maupun dalam pemrograman.
cmaster - mengembalikan monica
1

Jawaban singkatnya adalah Anda tidak membutuhkannya . Anda dapat menulis kode tanpa mereka. Seperti yang dikatakan Matius dalam komentar, ini terutama benar dalam JavaScript di mana bahasanya cukup fleksibel dan proyek cenderung lebih kecil. Tetapi jika Anda telah memprogram selama 4 tahun, saya merasa sulit untuk percaya bahwa Anda belum menemukan hal-hal yang terasa berulang atau canggung. Ini adalah area yang Anda temukan kembali atau hilang pola desain.

Contoh: Sistem acara JavaScript seringkali tidak memadai untuk tugas yang dihadapi. Pernahkah Anda menemukan diri Anda ingin dapat menggabungkan atau mengubah aliran acara? Atau bahwa serangkaian acara adalah nilai kelas satu dalam hak mereka sendiri? Anda membutuhkan pola Mediator dan / atau Pengamat. Perlu pengikatan data 2 arah? Cerita yang sama.

Hirarki prototipe getas turun? Pola Mixin / Trait / Subclass Factory untuk penyelamatan.

Jared Smith
sumber
4
Hampir tidak mungkin untuk menulis program non-sepele tanpa menggunakan pola desain apa pun, biasanya Anda akan menggunakan banyak yang umum juga. Yang tidak Anda butuhkan adalah bisa mengenali pola yang Anda gunakan dengan nama. Anda dapat menulis kode kerja bahkan jika Anda tidak dapat menyebutkan semua pola desain yang Anda gunakan di seluruh kode.
Servy
Pola desain @Servy adalah abstraksi, abstraksi tidak sepenuhnya diperlukan. Anda selalu dapat menulis implementasi ad-hoc satu kali dari perilaku yang mendasarinya ... lagi dan lagi dan lagi. Misalnya dalam contoh yang saya berikan tentang acara, mungkin untuk secara manual menghubungkan semua pihak yang berkepentingan dan kemudian mengubahnya setiap kali persyaratan berubah, itu hanya menyebalkan dibandingkan dengan menggunakan pub / sub. Untuk subkelas mungkin (jika boros) untuk secara manual kode dalam setiap kemungkinan dengan sekelompok kelas satu kali, itu tidak sebagus.
Jared Smith
1
Pola desain bisa menjadi sangat luas. Seringkali pola desain yang lebih luas begitu jelas sehingga kita bahkan tidak menganggapnya sebagai pola desain (terutama ketika mereka memiliki dukungan bahasa khusus). Loop adalah pola desain. Fungsi adalah pola desain. Objek adalah pola desain.
Servy
@Servy jika itu bagaimana Anda menggunakan istilah tersebut, maka saya tidak setuju, tapi saya mendapat kesan bahwa OP secara khusus berarti pola GOFish.
Jared Smith
1
Pola Desain @JaredSmith bukan abstraksi. Bahkan jika Anda menerapkannya lagi dan lagi dan lagi untuk masalah konkret yang Anda miliki, mereka masih pola . Anda tidak perlu menulis kelas Observer generik dan menggunakannya untuk menggunakan pola Observer . Menulis konkret Pengamat dan metode konkret untuk mendaftar dan memberi tahu mereka masih menggunakan pola. yang sulit adalah mengenali polanya. Kadang-kadang Anda menggunakan pola tanpa mengetahui namanya,
Polygnome
1

Temukan seorang mentor, seseorang dengan pengalaman yang sangat baik untuk belajar. Ajukan dia pertanyaan perhatikan kodenya, kirim beberapa ulasan kode dan coba berkolaborasi dengannya. Ini adalah cara terbaik untuk meningkatkan keterampilan pengkodean Anda.

tambahan:

  • Berkolaborasi dengan beberapa proyek OSS sederhana yang Anda suka

  • Ketika ada dua cara untuk memecahkan masalah yang sama, selalu pilih yang lebih sederhana

  • Bangun pengalaman ekstra dengan proyek sampingan tempat Anda bebas melakukan semua jenis kesalahan aneh, dan Anda akan mempelajari pola desain "jalan yang sulit" (tm)

Motocarota
sumber