Gaya pemrograman dalam Perl


9

Saya bekerja di Jawa jadi pada dasarnya saya menggunakan paradigma OOP selama pengkodean. Saya akan mulai bekerja di Perl dan saya bertanya-tanya apa paradigma yang diikuti pengembang Perl. Dalam wiki disebutkan bahwa ini mendukung banyak paradigma tetapi saya tidak yakin saya mengerti karena ini adalah bahasa scripting.

Jadi pertanyaan saya adalah: Apakah pola berorientasi objek yang saya kenal di Jawa idiomatik dalam Perl, atau akankah saya perlu perubahan signifikan pada gaya desain saya untuk menulis Perl efektif?

Catatan: Ini bukan pertanyaan untuk mengkritik Perl. Saya sebenarnya harus bekerja di Perl dan ingin memahami bagaimana cara saya saat ini program akan berubah.


3
Pada catatan yang lebih serius, lakukan Pencarian Google untuk "filosofi perl", dan lihat di sini: perldesignpatterns.com
Robert Harvey

Perl mendukung OOP. Anda dapat membangun hierarki kelas mengimplementasikan fungsi virtual dll. Bukan penggunaan yang paling umum tetapi bisa dilakukan.
Martin York

"Karena ini adalah bahasa scripting" - itu dapat digunakan seperti itu, tetapi ingat bahwa perl adalah VM sebanyak Java - perl dikompilasi (on the fly) untuk bytecode yang kemudian dieksekusi. Tidak ada JIT, tapi selain itu masih mesin virtual yang menjalankan kode Anda.
Tanktalus

Jawaban:


15

Filsafat Perl cenderung "melakukan apa yang praktis sekarang." Jika Anda perlu menggunakan OOP, itu ada di sana. Itu tidak perlu dalam semua solusi dan memaksa seseorang untuk menulis kode OOP ketika itu sederhana "lakukan ini maka ini maka ini" masalah tipe sering kontra produktif.

Sifat multi-paradigma perl dapat dilihat dalam hal-hal seperti transformasi Schwartzian yang memiliki aspek yang sangat fungsional untuk itu (dalam Lisp itu dikenal sebagai "menghias-semacam-undecorate"). OOP ada, seperti halnya prosedural (pemrograman C like) dan imperatif (bash like "do this then this").

Pola Desain adalah solusi berulang untuk masalah umum. Mereka ada dalam setiap bahasa. Terkadang pola-pola ini disebut idiom, meskipun ini mungkin juga merujuk pada hal-hal yang jauh lebih sederhana daripada sebuah pola.

Bila perlu, banyak Pola Desain GOF klasik dapat diimplementasikan dalam perl. Pola Desain Perl akan memiliki banyak nama umum yang orang kenal dengan GOF. Tidak perlu jika mereka semua perl idiomatik.

Saat menjelajahi pola desain dalam perl, harap perhatikan "Pola Desain" Bukan oleh Mark Dominus .

Banyak yang menganggap bahwa Pola Desain adalah kekurangan dalam bahasa . Dalam perspektif itu, Pola Desain seperti Iterator seringkali tidak perlu dalam perl. Tidak selalu - tetapi sering.

Pertama, tulis perl idiomatik. Jangan mencoba menulis C di perl, atau lisp di perl, atau java di perl. Perl adalah perl. Jika ada masalah yang menjadi lebih besar daripada perl perl idiomatik dapat menangani dan Anda mulai membutuhkan struktur kelas yang lebih kompleks, kemudian tulis mereka. Ketahui pola desain untuk dapat mengenali "masalah ini sekarang telah berkembang ke titik membutuhkan pabrik abstrak" - tetapi jangan mulai mencoba membuat pabrik abstrak dalam perl jika Anda tidak membutuhkannya.

Beberapa perpustakaan ada dalam bentuk OOP dan lebih tradisional. Lihat Haruskah saya menggunakan antarmuka CGI yang berorientasi fungsi atau berorientasi objek? untuk pertanyaan SO lama di mana orang bertanya ke mana harus menggunakan perpustakaan.


4
+ 1.Interesting information. Mempertimbangkan semua ini, mengapa ada banyak posting di SO yang mencoba mempertahankan / menyerang Perl sebagai bahasa lama? Tampaknya kuat dan bermanfaat bagi saya.
user10326

2
Setiap orang memiliki bahasa favorit mereka sendiri. Banyak yang merasa bahwa kecuali suatu bahasa dapat mendukung Hal Baru Minggu Ini, bahasanya sudah tua dan ketinggalan zaman dan semuanya harus dipindahkan darinya. Yang lain memiliki banyak waktu yang diinvestasikan untuk mempelajari bahasa tertentu dan tahu bagaimana membuatnya bekerja di tempat itu. Ini mudah diubah ke bahasa apa pun yang tidak bergerak secepat Bahasa Baru yang Panas. Perl menderita pencabutan hak tertentu ketika waktu yang dibutuhkan untuk mendapatkan Perl 6 (hari apa saja ... err .. tahun sekarang!). Ini seharusnya tidak menghalangi seseorang untuk belajar perl - ini digunakan di banyak tempat.

1
Anda mungkin akan menemukan bahwa perl adalah lingua franca untuk skrip linux yang mengambil banyak peran skrip shell dari masa lalu. Hanya skrip shell yang paling setia yang akan mengeluh jika Anda menulis skrip perl daripada bash ketika melakukan skrip pada sistem * nix. Salah satu hal paling penting untuk perl adalah CPAN - jika seseorang hendak melakukan penulisan perpustakaan dengan ukuran yang masuk akal, cukup periksa untuk melihat apakah orang lain telah menulisnya.

1
Apa pun yang dulunya skrip shell dari beberapa kompleksitas atau lebih besar sering skrip perl sekarang. Perl juga sering berfungsi sebagai lem / lakban antara sistem atau aplikasi. Pemrosesan string-nya juga membuatnya di rumah di beberapa industri lain (khususnya bioinformatika - lihat saja berapa banyak pertanyaan berbasis DNA yang ada dalam label perl pada SO).

4
Perl adalah bahasa pemrograman yang kuat dan lengkap. Dapat digunakan untuk skrip (mengotomatisasi interaksi dengan aplikasi lain termasuk shell), atau untuk membangun utilitas, atau bahkan untuk aplikasi skala yang lebih besar. Kebencian Perl cenderung berfokus pada hal-hal seperti sintaksis yang padat, dan pada tingkat tertentu, pada kesalahpahaman tentang fakta bahwa Perl tidak berusaha untuk memaksakan pola desain spesifik pada penggunanya. Saya menggunakan Perl setiap hari. Saya juga sering menggunakan bahasa lain. Saya menikmati ekspresi dan kekuatan Perl. Lewati tahap pembelajaran yang canggung dan kemungkinan Anda juga akan menyukainya.
DavidO

7

Sikap Perl pada paradigma adalah TMTOWTDI (ada lebih dari satu cara untuk melakukannya). Ini adalah salah satu alasan banyak orang bercanda menyebut Perl bahasa hanya tulis . Menulisnya lebih mudah daripada membacanya, karena gaya orang lain mungkin sama sekali berbeda dengan gaya Anda.

Yang sedang berkata, OOP tentu didukung di Perl. Jika Anda menggunakan banyak kode pihak ketiga, itu mungkin atau mungkin bukan OOP, tetapi untuk kode Anda sendiri, Anda dapat melakukan OOP sesuai isi hati Anda. Saya sebenarnya pertama kali belajar OOP di Perl. Saya mencoba C ++ terlebih dahulu dan itu tidak "klik" untuk beberapa alasan.


1
Mengapa banyak orang menganggap itu sebagai pilihan karir yang buruk? Tampaknya ia kuat dan dapat melengkapi bahasa lain sebagai bagian dari perangkat.
user10326

3
Anggap saja bahasa lain hampir sama kuat dan memiliki struktur yang lebih melekat. Perusahaan menyukai struktur.
Karl Bielefeldt


1
Itu adalah tutorial OOP yang bagus, menjelaskan gaya OO bawaan Perl. Jika Anda menemukan kode itu sedikit bertele-tele, Anda mungkin tertarik pada perpustakaan Perl Moose, yang mengotomatiskan banyak pengodean berulang dalam OO built-in. Tapi yang terbaik untuk memulai (IMH0) dengan gaya bawaan.
matt freake

1
Saya tidak pernah menemukan Perl sebagai pilihan karir yang buruk. Temukan grup Perl Mongers lokal, dan kemungkinannya adalah bahwa di hampir setiap pertemuan seseorang akan menyebutkan lowongan pekerjaan Perl.
DavidO

3

Saya dalam situasi yang sama, saya telah menggunakan Java untuk waktu yang lama,

Setelah pindah ke Perl adalah kejutan dan melegakan tetapi, saya menggunakan buku berjudul 'Perl Best Practices' Sangat membantu dan jika Anda memahami konsep dasar bahasa pemrograman, semuanya mudah mengalir begitu saja.

Hanya ingat dengan perl ada lebih dari satu cara untuk melakukannya, saya telah menghabiskan waktu berjam-jam melihat kode tertentu dan memodifikasinya, tetapi pada akhirnya menyelesaikan pekerjaan dengan kesalahan sintaksis sederhana.


0

Ada beberapa cara untuk menangani penggunaan kembali kode di Perl. Banyak contoh tidak memperjelas perbedaan antara pendekatan dan banyak kelas menggunakan setidaknya dua.

Saya menyarankan menggunakan gaya OO sebanyak mungkin dan hanya menggunakan EXPORTER ketika Anda memiliki setidaknya tiga kelas atau lebih yang membutuhkan sekelompok fungsi utilitas yang relatif kecil.

Begitu:

package Foo; 
use Foo::Util qw(util) ;
use strict ; 

sub foo {
}

sub bar {
}

1; 

package Foo::Bar ;
use Foo ; 
use Foo::Util qw(util) ;
our @ISA = qw(Foo) ; 
use strict ; 

sub bar {
}

1; 

package Foo::Util ; 
use Exporter ; 
our @ISA = qw(Exporter) ; 
our @EXPORT = qw(util) ;
use strict ; 

sub util {
}

1;

Saya lebih suka memvisualisasikan pendekatan OO dan EXPORTERpendekatan sebagai dua dimensi yang berbeda dari ketersediaan kode, seolah-olah fungsi-fungsi itu datang ke paket saat ini dari sumbu x atau y.

Dalam contoh di atas:

Foo::Barberasal foo()dari metode kelasFoo

Foo::Barmendefinisikan bar()metode sehingga metode polimorfik bar()tidak diturunkan dari kelasFoo

Kedua kelas Foodan Foo::Barmenerima EXPORTEDfungsi ( bukan metode ) util()dari paket ( bukan kelas )Foo::Util

Kedua sistem tersebut tampak rumit tetapi memiliki utilitas yang sangat praktis. Melacak banyak pewarisan bisa menjadi rumit dengan cepat. Jadi memiliki dimensi kedua ketersediaan kode, memungkinkan Anda untuk menjaga pohon warisan Anda kecil dan mudah dikelola.

Umumnya jika suatu fungsi bersifat monolitik dan relatif bodoh, gunakan EXPORTER, jika tidak gunakan pewarisan. Tapi jangan repot-repot menggunakan EXPORTERsama sekali kecuali apa yang akan Anda lakukan kemungkinan akan melibatkan lebih dari 3 atau 4 paket.

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.