Стиль програмування в Perl

Я працюю на Java, тому в основному я використовую парадигму OOP під час кодування. Я збираюся розпочати роботу в Perl, і мені було цікаво, що таке парадигма, якої слідкують розробники Perl. У Вікі згадується, що вона підтримує багато парадигм, але я не впевнений, що я це розумію, оскільки це мова сценаріїв.

Отже, моє запитання таке: чи знайомі об'єктно-орієнтовані візерунки, які я знайомий з Java idiomatic у Perl, чи мені знадобляться зміни в моєму стилі дизайну, щоб написати ефективний Perl?

Примітка: це питання не критикувати Perl. Мені справді доводиться працювати в Perl, і я хотів би зрозуміти, як зміниться поточний спосіб, який я програмую.

Філософія Perl має тенденцію до того, щоб "робити те, що зараз практично". Якщо вам потрібно використовувати OOP, його є. Це не обов'язково у всіх рішеннях і змушувати людину писати код OOP, коли це просто "зробіть це, тоді це", тоді ця проблема типу часто зустрічається на користь продуктивних.

Багатопарадигмальний характер perl можна побачити в таких речах, як трансформація Шварца, яка має для нього дуже функціональні аспекти (в Ліспі вона відома як "прикрасити-сортувати-неприміряти"). OOP існує, як і процедурні (на зразок програмування на C) та імперативні (bash типу "зроби це тоді це").

Шаблони дизайну - це повторювані рішення загальних проблем. Вони існують у всіх мовах. Іноді ці візерунки називають ідіомами, хоча це також може стосуватися речей, які набагато простіші за візерунок.

За потреби багато класичних шаблонів дизайну GOF можуть бути реалізовані в перл. Шаблони дизайну Perl матимуть багато поширених імен, які знайомі з GOF. Не обов’язково випадок, що всі вони ідіоматичні.

Вивчаючи дизайнерські шаблони в perl, також врахуйте "Шаблони дизайну" не від Марка Домінуса .

Багато хто вважає, що шаблони дизайну є недоліками в мові . З цього погляду шаблони дизайну, такі як Ітератор, часто не потрібні. Не завжди - але часто.

Спочатку напишіть ідіоматичний perl. Не намагайтеся писати C в perl, або lisp в perl, або java в perl. Perl - перл. Якщо є проблема, яка стає більшою, ніж ідіоматичний perl, що вдається вирішити, і ви починаєте потребувати більш складних структур класу, тоді напишіть їх. Знайте шаблони дизайну, щоб можна було розпізнати "ця проблема тепер зросла до того, що потрібна абстрактна фабрика", - але не починайте намагатися зробити абстрактну фабрику в Perl, якщо вона вам не потрібна.

Деякі бібліотеки існують як в OOP, так і в більш традиційних формах. Див. Чи слід використовувати функціональні або об'єктно-орієнтовані інтерфейси CGI? для старого питання SO, де можна задати, яким способом користуватися бібліотекою.

Позиція Perl щодо парадигм - TMTOWTDI (існує декілька способів зробити це). Це одна з причин, що багато людей жартома називають Perl мовою лише для письма . Написати це може бути набагато простіше, ніж прочитати, адже стиль іншої людини може бути зовсім іншим з вашим.

Попри це, OOP, безумовно, підтримується в Perl. Якщо ви використовуєте безліч сторонніх кодів, це може бути, а може, і не бути OOP, але для власного коду ви можете зробити OOP відповідно до вмісту вашого серця. Я фактично вперше дізнався OOP в Perl. Спершу я спробував C ++, і він чомусь не "клацнув".

Я в тій же ситуації, я вже довгий час використовую Java,

Переїзд до Perl був шоком і полегшенням, але я використав книгу під назвою "Найкращі практики Perl", яка допомагає дуже багато, і якщо ви розумієте основні поняття мов програмування, просто просто простувати з нею.

Просто пам’ятайте, що в perl існує більше ніж один спосіб зробити це, я витрачав незліченну кількість годин на перегляд певного коду та модифікацію його, але врешті-решт, це виконує завдання з простою синтаксичною помилкою.

Існує кілька способів обробки коду з повторним використанням коду в 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()метод, тому поліморфний метод bar()не виводиться з класуFoo

Обидва класи Fooі Foo::Barотримують EXPORTEDфункцію ( не метод ) util()з пакету ( не клас )Foo::Util

Дві системи здаються складними, але мають дуже практичну корисність. Відстеження багаторазового успадкування може отримати складність швидко. Отже, маючи другий вимір доступності коду, ви зможете зберегти своє спадкове дерево невеликим та керованим.

Як правило, якщо функція монолітна і відносно німа, використовуйте EXPORTER, інакше використовуйте успадкування. Але не турбуйтеся використовувати EXPORTERвзагалі, якщо для того, що ви збираєтеся, буде пов'язано більше ніж 3 або 4 пакети.