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

Я работаю на Java, поэтому в основном я использую парадигму ООП во время кодирования. Я собираюсь начать работать в Perl, и мне было интересно, какова парадигма, которой следуют разработчики Perl. В вики упоминается, что он поддерживает много парадигм, но я не уверен, что понимаю это, поскольку это язык сценариев.

Итак, мой вопрос: знакомы ли объектно-ориентированные шаблоны в Java с идиоматическими в Perl, или мне понадобятся значительные изменения в моем стиле разработки для написания эффективного Perl?

Примечание: это не вопрос для критики Perl. Я на самом деле должен работать в Perl и хотел бы понять, как изменится мой нынешний способ программирования.

Философия Perl, как правило, заключается в том, чтобы «делать то, что практично сейчас». Если вам нужно использовать ООП, его там. Нет необходимости во всех решениях и заставлять человека писать ООП-код, когда это простая проблема типа «сделай это, потом это, то это», часто контрпродуктивная.

Мультипарадигмальную природу perl можно увидеть в таких вещах, как преобразование Шварца, которое имеет очень функциональные аспекты (в Лиспе это известно как «decorate-sort-undecorate»). ООП существует, как и процедурный (C, как программирование) и императив (bash, как «сделай это, затем это»).

Шаблоны проектирования - это повторяющиеся решения общих проблем. Они существуют на каждом языке. Иногда эти шаблоны называются идиомами, хотя это также может относиться к вещам, которые намного проще, чем шаблоны.

При необходимости многие классические шаблоны проектирования GOF могут быть реализованы на Perl. У шаблонов Perl Design Patterns будет много общих имен, которые люди знакомы с GOF. Нет необходимости в том, что все они - идиоматический Perl.

При изучении шаблонов проектирования в Perl, пожалуйста, обратите внимание на «Шаблоны проектирования» не от Mark Dominus .

Многие считают, что шаблоны проектирования - это недостатки в языке . С этой точки зрения шаблоны проектирования, такие как Iterator, часто не нужны в perl. Не всегда - но часто.

Сначала напишите идиоматический Perl. Не пытайтесь писать C на Perl, или LISP на Perl, или Java на Perl. Perl - это Perl. Если есть проблема, которая становится больше, чем может решить идиоматический Perl, и вы начинаете нуждаться в более сложных структурах классов, напишите их. Знайте шаблоны проектирования, чтобы иметь возможность распознавать «эта проблема переросла в точку, требующую абстрактной фабрики» - но не начинайте пытаться создать абстрактную фабрику в Perl, если она вам не нужна.

Некоторые библиотеки существуют как в ООП, так и в более традиционных формах. См. Должен ли я использовать функционально-ориентированные или объектно-ориентированные интерфейсы CGI? на старый вопрос SO, где спрашивают, каким образом использовать библиотеку.

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

При этом ООП, безусловно, поддерживается в Perl. Если вы используете много стороннего кода, это может быть или не быть ООП, но для вашего собственного кода вы можете сделать ООП для вашего сердца. Я действительно впервые изучил ООП в Perl. Сначала я попробовал C ++, и он почему-то не «щелкнул».

Я в той же ситуации, я использую Java в течение долгого времени,

Переезд на Perl был шоком и облегчением, но я использовал книгу под названием «Perl Best Practices». Она очень помогает, и если вы понимаете основные понятия языков программирования, все легко понять.

Просто помните, что для Perl существует более одного способа сделать это: я потратил бесчисленные часы, просматривая определенный код и модифицируя его, но в конце концов он выполняет свою работу с простой синтаксической ошибкой.

Есть много способов справиться с повторным использованием кода в Perl. Многие примеры не дают четкого различия между подходами, и многие классы используют как минимум два.

Я советую максимально использовать стиль ОО и использовать ЭКСПОРТЕР только в том случае, если у вас есть как минимум три или более классов, которым требуется относительно небольшой набор служебных функций.

Так:

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;

Я предпочитаю визуализировать ОО-подход и EXPORTERподход как два разных измерения доступности кода, как если бы функции входили в текущий пакет с оси х или у.

В приведенном выше примере:

Foo::Barвыводит метод foo()из классаFoo

Foo::Barопределяет bar()метод, поэтому полиморфный метод bar()не является производным от классаFoo

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

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

Обычно, если функция монолитная и относительно тупая, используйте EXPORTER, в противном случае используйте наследование. Но не стоит использовать EXPORTERвообще, если только то, что вы собираетесь делать, может включать более 3 или 4 пакетов.