Phong cách lập trình trong Perl

Tôi làm việc trong Java nên về cơ bản tôi sử dụng mô hình OOP trong quá trình mã hóa. Tôi sắp bắt đầu làm việc ở Perl và tôi đã tự hỏi mô hình mà các nhà phát triển Perl làm theo là gì. Trong wiki nó đề cập rằng nó hỗ trợ nhiều mô hình nhưng tôi không chắc tôi hiểu điều này vì nó là một ngôn ngữ kịch bản.

Vì vậy, câu hỏi của tôi là: Các mẫu hướng đối tượng mà tôi quen thuộc trong thành ngữ Java trong Perl, hoặc tôi sẽ cần thay đổi đáng kể cho phong cách thiết kế của mình để viết Perl hiệu quả?

Lưu ý: Đây không phải là một câu hỏi để phê bình Perl. Tôi thực sự phải làm việc ở Perl và muốn hiểu cách thức hiện tại mà chương trình của tôi sẽ thay đổi.

Triết lý của Perl có xu hướng là "làm những gì thiết thực bây giờ." Nếu bạn cần sử dụng OOP, nó ở đó. Không cần thiết trong tất cả các giải pháp và buộc một người phải viết mã OOP khi đó là một vấn đề kiểu "làm điều này sau đó thì điều này" thường phản tác dụng.

Bản chất đa mô hình của perl có thể được nhìn thấy trong những thứ như phép biến đổi Schwartzian có các khía cạnh rất chức năng của nó (trong Lisp, nó được gọi là "trang trí-sắp xếp-không trang trí"). OOP tồn tại, cũng như thủ tục (C như lập trình) và mệnh lệnh (bash như "làm cái này rồi cái này").

Mẫu thiết kế là giải pháp định kỳ cho các vấn đề phổ biến. Chúng tồn tại trong mọi ngôn ngữ. Đôi khi những mẫu này được gọi là thành ngữ, mặc dù điều này cũng có thể đề cập đến những thứ đơn giản hơn nhiều so với một mẫu.

Khi cần thiết, nhiều Mẫu thiết kế GOF cổ điển có thể được triển khai trong perl. Các mẫu thiết kế Perl sẽ có nhiều tên phổ biến mà mọi người quen thuộc với GOF. Không cần thiết trong trường hợp tất cả chúng đều là thành ngữ perl.

Khi khám phá các mẫu thiết kế theo perl, vui lòng lưu ý "Mẫu thiết kế" Không phải của Mark Dominus .

Nhiều người cho rằng các Mẫu thiết kế là sự thiếu sót trong ngôn ngữ . Theo quan điểm đó, các Mẫu thiết kế như Iterator thường không cần thiết trong perl. Không phải luôn luôn - nhưng thường xuyên.

Đầu tiên, viết thành ngữ perl. Đừng cố viết C bằng perl, hoặc lisp in perl hoặc java bằng perl. Perl là perl. Nếu có một vấn đề lớn hơn thành ngữ perl có thể xử lý và bạn bắt đầu cần các cấu trúc lớp phức tạp hơn, thì hãy viết chúng. Biết các mẫu thiết kế để có thể nhận ra "vấn đề này đã phát triển đến mức cần một nhà máy trừu tượng" - nhưng đừng bắt đầu thử tạo một nhà máy trừu tượng trong perl nếu bạn không cần.

Một số thư viện tồn tại trong cả OOP và các hình thức truyền thống hơn. Xem Tôi nên sử dụng giao diện CGI hướng đối tượng hoặc hướng đối tượng? cho một câu hỏi SO cũ trong đó người ta hỏi cách sử dụng thư viện.

Lập trường của Perl về mô hình là TMTOWTDI (có nhiều hơn một cách để làm điều đó). Đây là một trong những lý do rất nhiều người gọi đùa Perl là ngôn ngữ chỉ viết . Viết nó có thể dễ dàng hơn rất nhiều so với đọc nó, bởi vì phong cách của người khác có thể hoàn toàn khác với bạn.

Điều đó đang được nói, OOP chắc chắn được hỗ trợ trong Perl. Nếu bạn đang sử dụng nhiều mã của bên thứ ba, nó có thể hoặc không phải là OOP, nhưng đối với mã của riêng bạn, bạn có thể thực hiện OOP cho nội dung trái tim của bạn. Lần đầu tiên tôi học OOP ở Perl. Tôi đã thử C ++ trước và nó không "nhấp" vì một số lý do.

Tôi cũng ở trong tình trạng tương tự, tôi đã sử dụng Java trong một thời gian ngắn,

Chuyển đến Perl là một cú sốc và nhẹ nhõm, nhưng, tôi đã sử dụng một cuốn sách có tên 'Thực tiễn tốt nhất Perl' Nó giúp ích rất nhiều và nếu bạn hiểu các khái niệm cơ bản của ngôn ngữ lập trình thì mọi thứ đều dễ dàng trôi qua.

Chỉ cần nhớ với perl có nhiều cách để làm điều đó, tôi đã dành vô số giờ để xem một số mã nhất định và sửa đổi nó, nhưng cuối cùng nó đã hoàn thành công việc với một lỗi cú pháp đơn giản.

Có nhiều cách để xử lý việc tái sử dụng mã trong Perl. Rất nhiều ví dụ không làm rõ sự khác biệt giữa các cách tiếp cận và nhiều lớp sử dụng ít nhất hai.

Tôi khuyên bạn nên sử dụng kiểu OO càng nhiều càng tốt và chỉ sử dụng XUẤT KHẨU khi bạn có ít nhất ba hoặc nhiều lớp cần một cụm chức năng tiện ích tương đối nhỏ.

Vì thế:

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;

Tôi thích trực quan hóa cách tiếp cận OO và EXPORTERcách tiếp cận như hai chiều khác nhau của tính khả dụng của mã, như thể các hàm đang đi vào gói hiện tại từ trục x hoặc y.

Trong ví dụ trên:

Foo::Barphương pháp xuất phát foo()từ lớpFoo

Foo::Barđịnh nghĩa một bar()phương thức để phương thức đa hình bar()không xuất phát từ lớpFoo

Cả hai lớp FoovàFoo::BarEXPORTED chức năng nhận ( không phải phương thức ) util()từ gói ( không phải lớp )Foo::Util

Hai hệ thống có vẻ phức tạp nhưng có một tiện ích rất thực tế. Truy tìm nhiều kế thừa có thể nhận được khó khăn nhanh chóng. Vì vậy, có kích thước thứ hai của tính khả dụng của mã, cho phép bạn giữ cây thừa kế của mình nhỏ và có thể quản lý được.

Nói chung nếu một hàm là nguyên khối và tương đối ngu ngốc, hãy sử dụng XUẤT KHẨU, nếu không thì sử dụng tính kế thừa. Nhưng đừng bận tâm sử dụngEXPORTER tất cả trừ khi những gì bạn sẽ làm có khả năng liên quan đến hơn 3 hoặc 4 gói.