Bagaimana menentukan apakah Pola Desain diterapkan dengan benar?

13

Saya berhasil mengatur semua aplikasi lama saya yang tidak menggunakan Pola Desain yang terdokumentasi. Pola apa pun itu, aku tidak tahu. Untuk sebagian besar, saya hanya merasa perlu menggunakan konsep OOP sederhana.

Konsep Pola Desain rumit dan sulit dipahami. Ketika diimplementasikan, bagaimana menentukan apakah implementasinya benar dan aplikasi memiliki kopling longgar nyata?

design-patterns

— RPK
sumber

49

Ada kesalahpahaman serius tentang apa pola desain. Mereka bukan debu peri ajaib yang Anda taburkan di aplikasi Anda untuk membuatnya lebih baik. Mereka terutama adalah kosakata umum untuk dapat berbicara tentang cara yang biasa digunakan untuk menyelesaikan masalah. Saya cukup yakin ada banyak orang yang "menerapkan pola dengan benar" sepanjang hari tanpa pernah mendengar kata "pola".

— Joachim Sauer

2

@ JoachimSauer Apa yang baru saja Anda katakan adalah hal-hal yang harus diajarkan universitas teknis ... Karena saya saat ini masih mahasiswa, ini adalah hal yang paling membuat saya kesal.

— Radu Murzea

1

@ JoachimSauer Sebenarnya kesalahpahaman ini muncul karena ada berbagai teknik implementasi untuk pola yang sama. Ambil contoh MVC dan MVP, ada variasi sebanyak proyek, dengan pola yang sama.

— RPK

@RPK +1, fakta bahwa ada sejumlah pola MVX (MVC, MVP, MVA, MVVM dll) harus menjadi indikasi yang jelas bahwa ada banyak cara yang sama-sama layak untuk melakukan sesuatu.

— MattDavey

kemungkinan rangkap dari Kapan saya harus menggunakan — dan tidak menggunakan — pola desain?

— nyamuk

3

Untuk menjaga jawaban tetap ringkas, saya akan mengatakan jika karakteristik berikut ini terlihat dalam kode Anda, Anda dapat yakin bahwa polanya sudah ada bahkan jika Anda belum melakukan upaya yang disengaja (yang bukan masalah) ke arah itu.

Karakteristik yang Diinginkan:

Basis kode Anda dapat diuji pada tingkat unit
Setiap kali Anda menerapkan permintaan perubahan apa pun maka Anda membuat perubahan hanya untuk kelas yang relevan yang saling terkait dalam domain.
Basis kode Anda tidak menunjukkan entropi perangkat lunak .

Jika Anda masih penasaran untuk mengidentifikasi dan menandai kode Anda dengan nama-nama pola nyata, saya akan merekomendasikan untuk melakukan tindakan berikut untuk mendapatkan bola bergulir.

Merekayasa balik basis kode Anda untuk menghasilkan beberapa daigram UML.
Bandingkan secara visual diagram dengan referensi siap bahan referensi pola.

Ini seharusnya memberi Anda ide yang adil.

— Sameer Patil
sumber

Bisakah Anda menguraikan lebih lanjut tentang yang ketiga?

— Niing

19

Anda menyebutkan kedua pola desain dan kopling. Ini adalah konsep yang terpisah jadi saya akan membahasnya secara terpisah. Satu-satunya hubungan nyata adalah bahwa pola desain cenderung mempromosikan kopling longgar (karena ini merupakan aspek utama dari desain yang baik).

Pola desain

Konsep Pola Desain sebenarnya cukup sederhana: Mereka hanya seperangkat template tentang cara menangani berbagai masalah umum. Ada 2 alasan utama mengapa mereka populer:

Mereka 'terbukti': mereka telah digunakan sebelumnya berkali-kali dan manfaat / kelemahan dari masing-masing umumnya diketahui, khususnya setiap masalah halus yang mungkin menyebabkan masalah besar diketahui.
Mereka menyediakan seperangkat istilah umum, dan dengan demikian memungkinkan komunikasi yang lebih mudah. Jika seseorang mengatakan "kelas X memainkan peran pengamat dalam pola pengamat" maka pengembang yang terbiasa dengan pola tersebut dapat segera memahami apa yang terjadi.

Bagaimana Anda tahu bahwa Anda telah menerapkannya dengan benar? Itu rumit. Untuk sebagian besar pola itu sederhana - Anda telah mengguncangnya atau belum. Beberapa pola kurang terdefinisi dengan jelas daripada yang lain - misalnya model-view-controller . Pola seperti itu lebih baik digunakan sebagai pedoman umum. Spesifik bagaimana Anda menerapkannya kurang penting daripada memahami alasan bahwa pola itu ada dan apa yang ingin dicapai.

Pola desain bukan 'satu-satunya jalan yang sebenarnya'. Seringkali Anda perlu menyesuaikannya untuk tujuan spesifik Anda, atau kadang-kadang tidak ada pola yang sesuai dengan persyaratan. Memaksa pola desain yang tidak cocok adalah ide yang buruk; itu seperti menggunakan palu yang sangat bagus ketika apa yang Anda inginkan sebenarnya adalah obeng.

Kopel

Ini adalah ide yang sangat penting dalam ilmu komputer. Karena persyaratan untuk sebagian besar proyek perangkat lunak berubah seiring waktu (kadang-kadang secara signifikan) maka kemampuan desain untuk mengatasi perubahan adalah penting. Coupling pada dasarnya adalah ukuran "seberapa sulitkah untuk menukar komponen ini dengan yang lain?" 'Komponen' dapat berupa metode, kelas, paket, pustaka, dll.

Ada berbagai jenis sambungan yang tercantum dalam artikel Wikipedia ini .

— vaughandroid
sumber

2

Jawabannya sebenarnya adalah tujuan Anda ingin menulis pola desain dari awal. Mengapa Anda menginginkan fleksibilitas?

Itu adalah perubahan; persyaratan berubah. Cobalah untuk mengubah sesuatu dalam persyaratan Anda yang tercermin dalam perubahan kode dan lihat betapa mudah / sulitnya melakukannya.

— m3th0dman
sumber

-1

Menggunakan pola desain adalah tindakan pencegahan. Anda menggunakan pola desain untuk memudahkan pekerjaan Anda saat Anda menskala aplikasi nanti. Tentu saja, untuk memudahkan pekerjaan Anda nanti, Anda harus melakukan lebih banyak pekerjaan sekarang. jadi pertanyaan sebenarnya adalah berapa banyak perubahan yang dapat Anda harapkan di masa depan dan apa perubahan ini. Jika Anda tidak membutuhkan skalabilitas dan fleksibilitas, Anda dapat menghapusnya dengan pola desain.

Pola desain sendiri merupakan implementasi dari Prinsip Desain Berorientasi Objek. Selama Anda mengikuti prinsip-prinsip ini aplikasi Anda akan menjadi fleksibel dan terukur; bahkan jika Anda tidak benar-benar memiliki pola desain yang sebenarnya. Seperti yang dikatakan oleh Joachim Sauer di atas, mereka adalah solusi umum untuk masalah umum.

— DPD
sumber

2

IMO, menggunakan pola desain tidak ada hubungannya dengan skalabilitas. Ini hanya kosakata untuk mengenali pola umum dalam kode sehingga kita bisa membicarakannya. Seringkali, aplikasi penskalaan dapat berarti bertentangan dengan desain yang baik demi kinerja.

— Adrian Schneider