รูปแบบการเขียนโปรแกรมใน Perl

9

ฉันทำงานใน Java ดังนั้นโดยทั่วไปฉันใช้กระบวนทัศน์ OOP ในระหว่างการเข้ารหัส ฉันกำลังจะเริ่มทำงานใน Perl และฉันสงสัยว่ากระบวนทัศน์ที่นักพัฒนา Perl ติดตามคืออะไร ในวิกินั้นกล่าวว่ามันสนับสนุนกระบวนทัศน์จำนวนมาก แต่ฉันไม่แน่ใจว่าฉันเข้าใจสิ่งนี้เพราะเป็นภาษาสคริปต์

ดังนั้นคำถามของฉันคือ: รูปแบบเชิงวัตถุที่ฉันคุ้นเคยใน Java idiomatic ใน Perl หรือฉันจะต้องเปลี่ยนสไตล์การออกแบบของฉันเพื่อเขียน Perl ที่มีประสิทธิภาพหรือไม่

หมายเหตุ: นี่ไม่ใช่คำถามที่จะวิจารณ์ Perl จริง ๆ แล้วฉันต้องทำงานใน Perl และต้องการที่จะเข้าใจวิธีการที่โปรแกรมปัจจุบันของฉันจะเปลี่ยนแปลง

— user10326
แหล่งที่มา

3

ในหมายเหตุที่จริงจังกว่าให้ทำการค้นหาโดย Google สำหรับ "perl ปรัชญา" และดูที่นี่: perldesignpatterns.com

— Robert Harvey

Perl รองรับ OOP คุณสามารถสร้างลำดับชั้นของคลาสใช้ฟังก์ชั่นเสมือนจริง ฯลฯ ไม่ใช่การใช้งานทั่วไป แต่สามารถทำได้

— Martin York

"เนื่องจากเป็นภาษาสคริปต์" - สามารถใช้งานได้เช่นนี้ แต่โปรดจำไว้ว่า perl นั้นมีค่ามากเท่ากับ VM เช่นเดียวกับ Java - perl ได้รับการคอมไพล์ (ทันที) ไปยัง bytecode ซึ่งถูกเรียกใช้ ไม่มี JIT แต่อย่างอื่นนอกจากนั้นมันยังเป็นเครื่องเสมือนที่ใช้รหัสของคุณ

— Tanktalus

15

ปรัชญาของ Perl มีแนวโน้มที่จะ "ทำสิ่งที่เป็นประโยชน์ในขณะนี้" หากคุณจำเป็นต้องใช้ OOP มันอยู่ที่นั่น มันไม่จำเป็นในการแก้ปัญหาทั้งหมดและบังคับให้คนเขียนรหัส OOP เมื่อมันง่าย "ทำอย่างนี้แล้วปัญหาประเภทนี้" มักจะตอบโต้การผลิต

ธรรมชาติหลายกระบวนทัศน์ของ perl สามารถมองเห็นได้ในสิ่งต่าง ๆ เช่นการเปลี่ยนแปลงชวาร์ตเซียนซึ่งมีลักษณะการทำงานมากไป (ในเสียงกระเพื่อมมันเป็นที่รู้จักกันในชื่อ มี OOP อยู่เช่นเดียวกับขั้นตอน (C เช่นการเขียนโปรแกรม) และจำเป็น (ทุบตีเช่น "ทำสิ่งนี้แล้ว")

รูปแบบการออกแบบเป็นวิธีแก้ไขปัญหาที่พบบ่อย พวกเขามีอยู่ในทุกภาษา บางครั้งรูปแบบเหล่านี้เรียกว่าสำนวนแม้ว่าสิ่งนี้อาจหมายถึงสิ่งที่ง่ายกว่าแบบ

เมื่อจำเป็นรูปแบบการออกแบบ GOF แบบคลาสสิกหลายรูปแบบสามารถนำไปใช้ใน Perl ได้ รูปแบบการออกแบบ Perlจะมีชื่อสามัญมากมายที่คนคุ้นเคยกับ GOF มันไม่จำเป็นในกรณีที่พวกเขาทุกคนเป็นคนบ้า

เมื่อสำรวจรูปแบบการออกแบบใน Perl โปรดรับทราบของ"การออกแบบรูปแบบ" ไม่ได้โดยมาร์ค Dominus

หลายคนคิดว่าการออกแบบรูปแบบมีข้อบกพร่องในภาษา ในมุมมองดังกล่าวรูปแบบการออกแบบเช่น Iterator มักไม่จำเป็นต้องเป็น Perl ไม่เสมอ - แต่บ่อยครั้ง

ก่อนอื่นเขียน Perl แบบใช้สำนวน อย่าพยายามเขียน C เป็น perl หรือ lisp เป็น perl หรือ java เป็น perl Perl เป็น Perl หากมีปัญหาที่ใหญ่กว่า idiomatic perl สามารถจัดการได้และคุณเริ่มต้องการโครงสร้างคลาสที่ซับซ้อนมากขึ้นให้เขียนมัน รู้รูปแบบการออกแบบเพื่อให้สามารถรับรู้ "ปัญหานี้เพิ่มขึ้นจนถึงจุดที่ต้องการโรงงานนามธรรม" - แต่อย่าเริ่มพยายามสร้างโรงงานนามธรรมใน Perl หากคุณไม่ต้องการ

ห้องสมุดบางแห่งมีอยู่ในทั้ง OOP และรูปแบบดั้งเดิม ดูฉันควรใช้อินเทอร์เฟซ CGI สำหรับฟังก์ชันหรือเชิงวัตถุหรือไม่ สำหรับคำถาม SO เก่าที่หนึ่งถามว่าวิธีการใช้ห้องสมุด

— ชุมชน
แหล่งที่มา

4

+ 1. ข้อมูลที่น่าสนใจลองพิจารณาสิ่งเหล่านี้ว่าทำไมมีโพสต์มากมายในการพยายามที่จะปกป้อง / โจมตี Perl เป็นภาษาเก่าดูเหมือนว่ามีประสิทธิภาพและเป็นประโยชน์กับฉัน

— user10326

2

ทุกคนมีภาษาโปรดของตัวเอง หลายคนรู้สึกว่าถ้าภาษาไม่สามารถรองรับสิ่งใหม่ในสัปดาห์นี้ภาษานั้นเก่าและล้าสมัยและทุกอย่างควรจะถูกย้ายจากมัน คนอื่น ๆ มีเวลาที่สำคัญในการเรียนรู้ภาษาใดภาษาหนึ่งและรู้วิธีที่จะทำให้มันทำงานในที่ที่เป็นอยู่ สิ่งนี้จะเปลี่ยนเป็นภาษาใด ๆ ที่ไม่ย้ายเร็วเท่ากับภาษาใหม่ยอดนิยม Perl ทนทุกข์ทรมานจากสิทธิ์พิเศษเมื่อถึงเวลาที่จะได้รับ Perl 6 (วันใด .. .. ผิดพลาด .. ปีนี้!) สิ่งนี้ไม่ควรขัดขวางสิ่งหนึ่งจากการเรียนรู้ perl - มันถูกใช้ในหลาย ๆ ที่

1

คุณอาจจะพบว่า Perl เป็นภาษากลางสำหรับการเขียนสคริปต์ linux ซึ่งมีบทบาทอย่างมากในการเขียนสคริปต์เชลล์ตั้งแต่สมัยก่อน เฉพาะสคริปเชลล์ที่หยุดทำงานส่วนใหญ่เท่านั้นที่จะบ่นถ้าคุณเขียนสคริปต์ Perl แทนที่จะทุบตีเมื่อทำสคริปต์ในระบบ * nix หนึ่งในสิ่งที่สำคัญที่สุดสำหรับ perl คือCPAN - ถ้าหนึ่งอันใกล้จะเขียนไลบรารี่ที่มีขนาดพอเหมาะลองตรวจดูว่ามีคนอื่นเขียนมาแล้วหรือยัง

1

อะไรก็ตามที่เคยเป็นเชลล์สคริปต์ที่มีความซับซ้อนบางอย่างหรือมากกว่านั้นมักจะเป็นสคริปต์ Perl Perl มักจะทำงานเป็นเทปกาว / ท่อระหว่างระบบหรือแอปพลิเคชัน การประมวลผลสตริงของมันยังทำให้มันอยู่ที่บ้านในอุตสาหกรรมอื่น ๆ (โดยเฉพาะอย่างยิ่งชีวสารสนเทศศาสตร์ - เพียงแค่ดูว่ามีคำถามที่ใช้ดีเอ็นเออยู่ภายในแท็ก Perl บน SO)

4

Perl เป็นภาษาโปรแกรมที่สมบูรณ์และสมบูรณ์ สามารถใช้สำหรับการเขียนสคริปต์ (โต้ตอบโดยอัตโนมัติกับแอปพลิเคชันอื่น ๆ รวมถึงเชลล์) หรือสำหรับการสร้างสาธารณูปโภคหรือแม้กระทั่งสำหรับแอปพลิเคชันขนาดใหญ่ ความเกลียดชัง Perl มีแนวโน้มที่จะมุ่งเน้นไปที่สิ่งต่าง ๆ เช่นไวยากรณ์ที่มีความหนาแน่นสูงและในระดับหนึ่งความเข้าใจผิดเกี่ยวกับความจริงที่ว่า Perl ไม่พยายามบังคับรูปแบบการออกแบบเฉพาะให้กับผู้ใช้ ฉันใช้ Perl ทุกวัน ฉันยังใช้ภาษาอื่นบ่อยๆ ฉันสนุกกับการแสดงออกและพลังของ Perl ผ่านช่วงการเรียนรู้ที่น่าอึดอัดใจและโอกาสที่คุณจะรัก

— DavidO

7

จุดยืนของ Perl ในกระบวนทัศน์คือ TMTOWTDI (มีมากกว่าหนึ่งวิธีในการทำ) นี่คือหนึ่งในเหตุผลที่คนจำนวนมากติดตลกเรียก Perl ภาษาเขียนเท่านั้น การเขียนมันง่ายกว่าการอ่านมากเพราะสไตล์ของคนอื่นอาจแตกต่างจากของคุณอย่างสิ้นเชิง

ที่ถูกกล่าวว่า OOP ได้รับการสนับสนุนอย่างแน่นอนใน Perl หากคุณใช้รหัสบุคคลที่สามเป็นจำนวนมากอาจเป็น OOP แต่สำหรับรหัสของคุณเองคุณสามารถทำ OOP กับเนื้อหาในใจได้ จริงๆแล้วฉันได้เรียนรู้ OOP ครั้งแรกใน Perl ฉันลอง C ++ ก่อนและไม่ได้ "คลิก" ด้วยเหตุผลบางอย่าง

— Karl Bielefeldt
แหล่งที่มา

1

ทำไมหลายคนคิดว่ามันเป็นตัวเลือกอาชีพที่ไม่ดีดูเหมือนว่ามันมีประสิทธิภาพและสามารถเติมเต็มภาษาอื่น ๆ เป็นส่วนหนึ่งของชุดเครื่องมือ

— user10326

3

สมมติว่าภาษาอื่นมีพลังเกือบจะเหมือนกันและมีโครงสร้างโดยธรรมชาติมากกว่า บริษัท ที่ชอบโครงสร้าง

— Karl Bielefeldt

สำหรับการสอน Perl OOP ที่ดีตรวจสอบcodeproject.com/Articles/3152/Perl-Object-Oriented-Programming

— Pmarcoen

1

นั่นคือบทช่วยสอน OOP ที่ดีอธิบายสไตล์ OO ที่สร้างขึ้นของ Perl หากคุณพบว่าโค้ดมีความละเอียดมากคุณอาจสนใจห้องสมุด Perl Moose ซึ่งทำการเข้ารหัสซ้ำ ๆ โดยอัตโนมัติใน OO ที่สร้างขึ้น แต่เป็นการดีที่สุดที่จะเริ่ม (IMH0) ด้วยสไตล์ที่สร้างขึ้น

— matt freake

1

ฉันไม่เคยพบว่า Perl เป็นอาชีพที่ไม่ดี ค้นหากลุ่ม Perl Mongers ในท้องถิ่นและโอกาสก็คือในเกือบทุกครั้งที่มีการพบเจอใครบางคนจะพูดถึงการเปิดรับงาน Perl

— DavidO

3

ฉันอยู่ในสถานการณ์เดียวกันฉันใช้ Java เป็นเวลานาน

ต้องย้ายไป Perl เป็นที่น่าตกใจและโล่งอก แต่ฉันใช้หนังสือที่ชื่อว่า 'Perl Best Practices' มันช่วยได้มากและถ้าคุณเข้าใจแนวคิดพื้นฐานของภาษาการเขียนโปรแกรมมันง่ายมากที่จะไหลไปกับมัน

เพียงจำด้วย Perl มีมากกว่าหนึ่งวิธีที่จะทำมันฉันได้ใช้เวลานับไม่ถ้วนดูรหัสและแก้ไข แต่ในที่สุดก็รับงานทำกับข้อผิดพลาดทางไวยากรณ์ง่าย

— Sunny Patel
แหล่งที่มา

0

มีหลายวิธีในการจัดการการใช้รหัสซ้ำใน Perl ตัวอย่างจำนวนมากไม่ได้ทำให้ชัดเจนถึงความแตกต่างระหว่างวิธีการและชั้นเรียนจำนวนมากที่ใช้อย่างน้อยสอง

ฉันแนะนำให้ใช้สไตล์ OO ให้มากที่สุดและใช้ EXPORTER เฉพาะเมื่อคุณมีคลาสอย่างน้อยสามคลาสขึ้นไปที่ต้องการฟังก์ชันกลุ่มยูทิลิตี้ที่ค่อนข้างเล็ก

ดังนั้น:

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;

ฉันชอบที่จะเห็นภาพวิธีการ OO และEXPORTERวิธีการเป็นสองมิติที่แตกต่างกันของความพร้อมใช้งานของรหัสราวกับว่าฟังก์ชั่นเข้ามาในแพคเกจปัจจุบันจากแกน x หรือ y

ในตัวอย่างด้านบน:

Foo::Barได้มาfoo()จากวิธีการเรียนFoo

Foo::Barกำหนดbar()วิธีการเพื่อให้วิธีการ polymorphic bar()ไม่ได้มาจากชั้นเรียนFoo

ทั้งคลาสFooและFoo::BarรับEXPORTEDฟังก์ชั่น ( ไม่ใช่เมท็อด ) util()จากแพ็คเกจ ( ไม่ใช่คลาส )Foo::Util

ระบบทั้งสองดูเหมือนซับซ้อน แต่มียูทิลิตี้ที่ใช้งานได้จริงมาก การติดตามการสืบทอดหลายรายการสามารถทำให้เกิดความยุ่งยากได้อย่างรวดเร็ว ดังนั้นการมีมิติที่สองของความพร้อมใช้งานของรหัสช่วยให้คุณสามารถทำให้แผนภูมิการสืบทอดของคุณเล็กและจัดการได้

โดยทั่วไปถ้าฟังก์ชั่นเป็นเสาหินและเป็นใบ้ให้ใช้ EXPORTER หรือใช้การสืบทอด แต่ไม่ต้องกังวลกับการใช้EXPORTERงานเลยเว้นแต่ว่าคุณจะทำมีแนวโน้มที่จะเกี่ยวข้องกับแพ็คเกจมากกว่า 3 หรือ 4 ชุด

— James Aanderson
แหล่งที่มา