Pola Desain Non-OOP? [Tutup]

70

Saya hanya mendengar istilah "pola desain" yang digunakan untuk kode berorientasi objek, dan pola GoF hanya mencakup pola desain OOP, tetapi pola desain adalah solusi elegan untuk masalah pemrograman yang biasa terjadi, bukan? Tidak ada apa-apa di sana yang mengatakan bahwa mereka harus dibatasi OOP, kan?

Saya ingin melihat beberapa contoh pola desain di luar bidang pemrograman berorientasi objek. Apakah Anda memiliki? Apakah bahkan ada (tidak ada buku, seperti buku GoF, yang harus ditulis, mereka hanya boleh digunakan; itu sudah cukup)?

Mereka dapat spesifik untuk beberapa bahasa pemrograman, tetapi pola umum (level paradigma) lebih disukai, dari paradigma lain daripada yang berorientasi objek.

design-patterns

— Anto
sumber

8

Saya pikir kerugian terbesar yang dilakukan oleh buku-buku pola desain populer adalah menciptakan banyak orang yang percaya bahwa pola-pola itu hanya berlaku untuk bahasa yang berorientasi objek. Pola penciptaan masih bisa diperdebatkan, tetapi hampir semua yang lain dapat dan diimplementasikan dalam bahasa yang tidak berorientasi objek sepanjang waktu. Saya yakin efek samping ini bukan niat penulis, tetapi efek sampingnya.

— Pemdas

14

Nah, objek adalah pola desain dalam bahasa non-OO :)

— back2dos

1

lebih buruk lagi, buku-buku pola menciptakan seluruh kelas orang-orang yang percaya setiap masalah harus diselesaikan dengan menerapkan pola tertentu (biasanya yang terakhir mereka diajarkan oleh beberapa guru sekolah yang dirinya percaya sama).

— jwenting

25

Lihatlah seri Pola Desain Kernel Linux. Artikel-artikel tersebut terkait dengan bahasa yang tidak berorientasi objek (C) dan saya percaya bahwa mereka ditulis dengan baik:

— sakisk
sumber

Mereka menggunakan pendekatan berorientasi objek.

— Kais

12

Sebenarnya ini paradoks - salah satu pola Non-OO yang paling populer adalah ... "Kelas".

Karena OO ditemukan dalam bahasa non-OO, pengembang harus mensimulasikannya (dan mereka melakukannya bahkan sekarang) - sehingga pola lahir. LISP dan C adalah contohnya.

Tapi terima saran saya: Jangan melakukan kesalahan umum - jangan menggunakan pola hanya karena itu keren , Anda perlu alasan serius untuk membenarkan penggunaan pola (setidaknya yang OO).

Ambil pola Perintah misalnya - walaupun bagus & memisahkan pemanggil dari penerima, itu tidak boleh digunakan kecuali Anda benar-benar membutuhkannya - karena operasi harus diekspresikan menggunakan kata kerja - yang berarti metode. Dan menggunakan perintah di semua tempat Anda akan berakhir dengan sekelompok OO-lambda yang sepenuhnya terdesentralisasi - yang sama akan berlaku untuk banyak Strategi.

— Kamil Tomšík
sumber

11

"Pola desain" sebenarnya adalah eufemisme untuk "solusi". Pola desain diciptakan untuk mengatasi kekurangan dan kekurangan dalam bahasa OO . Misalnya ambil pola iterator yang akhirnya mengarah pada pengenalan koleksi di Jawa. Groovy menyingkirkan lebih banyak pola dengan mengubahnya menjadi fitur bahasa: Anda tidak lagi membutuhkan pola dekorator karena Anda dapat menambahkan metode ke kelas yang ada di Groovy.

Ini berarti Anda dapat menemukan pola desain di mana-mana. Bahkan setiap "praktik terbaik" dapat dianggap sebagai bentuk sederhana dari pola desain.

— Aaron Digulla
sumber

9

Sepakat! Dari Paul Graham : "Sebagai contoh, di dunia OO Anda mendengar banyak tentang" pola ". [...] Ketika saya melihat pola dalam program saya, saya menganggapnya sebagai tanda masalah. Bentuk program harus mencerminkan hanya masalah yang perlu dipecahkan. Keteraturan lain dalam kode adalah pertanda, setidaknya bagi saya, bahwa saya menggunakan abstraksi yang tidak cukup kuat - sering saya hasilkan sendiri dengan ekspansi dari beberapa makro yang perlu saya tulis. "

— Andres F.

7

Saya tidak setuju dengan pola desain sebagai solusi. Keduanya bertentangan. Solusi adalah tambalan jangka pendek yang disatukan untuk memotong rintangan tertentu. Pola desain adalah solusi jangka panjang yang dapat digunakan kembali. Tujuan pola dekorator adalah untuk menambahkan secara fungsional 'tanpa' memodifikasi kelas. Anda dapat menempatkan dekorator yang berbeda pada suatu objek tanpa objek menyadarinya.

— Despertar

Alasan mengapa pola dianggap sebagai "solusi" adalah karena mendekorasi objek harus menjadi fitur bahasa. Sebaliknya, kita harus menulis banyak, banyak baris kode untuk mengimplementasikan ini. Sebagai contoh, pola iterator telah menjadi bagian dari banyak bahasa modern. Untuk bahasa OO yang lebih lama, Anda harus melewati beberapa simpai untuk mensimulasikannya.

— Aaron Digulla

@ AaronDigulla Saya tidak melihat mengapa Anda berpikir pola seperti dekorator adalah implementasi yang sangat berat; Anda sedang berbicara tentang beberapa baris kode. Kelas berisi kelas lain dan meneruskan permintaan ke sana dengan beberapa fungsi tambahan. Ia menggunakan pewarisan dan komposisi dengan cara yang membuat panggilan objek yang didekorasi sama dengan memanggil objek itu sendiri. Saya menganggap transparansi ini sebagai kekuatan. Ini memungkinkan Anda untuk menukar dekorator saat runtime. Ketika Anda mengatakan bahwa asyik tidak membutuhkan dekorator karena dapat menambahkan metode ke kelas, sepertinya Anda tidak mengerti.

— Despertar

2

Pola Iterator belum digantikan oleh fitur bahasa baru dalam bahasa modern. Itu hanya datang dengan implementasi standar untuk koleksi umum. Hanya karena memiliki implementasi standar tidak berarti polanya tidak digunakan. Jika Anda menulis koleksi sendiri, Anda harus mengimplementasikannya sendiri.

— Despertar

10

LtU menyebutkan bahwa Jeremy Gibbons sedang menulis buku tentang pola dalam pemrograman fungsional. Lihat Pola Pak Gibbon di blog Pemrograman Fungsional untuk beberapa permainan asah. Perhatikan ia merekomendasikan membaca posting-postingnya dari terlama hingga terbaru.

Makalahnya Desain Pola sebagai Program Generasi Tinggi Datatype-Generik (pdf) secara fungsional memodelkan pola Geng Empat: Komposit, Iterator, Pengunjung, dan Pembuat. Dia menjelaskan pola pemrograman dengan persamaan rekursif dalam Origami Programming (lipatan dan lipatan).

— Corbin March
sumber

9

Ada pola desain SQL .

Dan beberapa pola desain fungsional juga ada - lihat di sini untuk scala.

— Oded
sumber

Tautan scala rusak

— corvus_192

7

Alih-alih menamai pola desain non-oo, saya ingin memberi Anda beberapa contoh buku yang memiliki banyak pola desain (di dalamnya beberapa pola masih akan spesifik OO):

Lihatlah Buku POSA untuk contoh dalam arsitektur perangkat lunak
- Komputasi terdistribusi
- Pola untuk Objek Bersamaan dan Jaringan
- Pola untuk Manajemen Sumber Daya
Pola Fowlers arsitektur perusahaan dengan katalog on-line
xUnit Pola pengujian dengan situs web
Dan tentu saja dari mana pola berasal: cara bangunan abadi Christopher Alexander

Semoga ini membantu

— KeesDijk
sumber

Ini adalah yang akan saya rekomendasikan juga, ditambah Pola Integrasi Perusahaan Hohpe & Woolf .

— TMN

Pola Fowler sangat OO :)

— David Conde

@ David Conde :) Kebanyakan dari mereka adalah OO murni, Semuanya ditulis dengan cara OO, tetapi beberapa dari mereka juga berlaku untuk non OO: lihat "pola presentasi Web", "pola status sesi", "pola status sesi", "pola distribusi" "

— KeesDijk

2

Dalam pemrograman fungsional (terutama Haskell), ada banyak pola dan idiom yang tidak dapat dipetakan dengan baik ke OOP. Jenis hantu adalah contoh terkenal, dan Anda dapat menemukan lebih banyak di halaman wiki haskell di Idioms .

— yatima2975
sumber

1

Pemrograman modular cukup populer untuk perpustakaan numerik dan aplikasi matematika-berat (perangkat lunak numerik terkenal sulit untuk memodelkan menggunakan pola-pola Berorientasi Objek, terutama karena ada sangat sedikit Anda dapat merangkum).

— quant_dev
sumber

Digunakan dalam JS & "pure C": en.wikipedia.org/wiki/Module_pattern

— umlcat

1

Contoh yang baik dari pola non-OOP adalah katalog pola favorit mutlak saya: Pola Organisasi Pengembangan Perangkat Lunak Agile, oleh James O. Coplien . Buku ini bukan tentang pola perangkat lunak, tentang orang, katalog untuk menciptakan tim yang sukses. Setiap manajer harus membaca buku ini!

— JuanZe
sumber

0

Saya suka memikirkan Strucutres Data seperti Antrian, Daftar tertaut, Pohon, grafik, dll sebagai pola. Mereka menentukan pola tertentu untuk menyimpan data dan memprosesnya. Mereka mungkin tampak primitif dibandingkan dengan patters Gang of Four yang lebih tinggi tetapi mereka adalah pola namun demikian. Maksud saya, apa yang akan terjadi jika seseorang menerapkan stack sebagai FIFO alih-alih LIFO dan sebaliknya untuk antrian dan menamakannya sebaliknya?

— DPD
sumber