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

9

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

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

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

user10326
источник
3
На более серьезной ноте, сделайте поиск Google для "философии perl", и посмотрите здесь: perldesignpatterns.com
Роберт Харви
Perl поддерживает ООП. Вы можете создавать иерархии классов, реализующие виртуальные функции и т. Д. Не самое распространенное использование, но это можно сделать.
Мартин Йорк,
«поскольку это язык сценариев» - его можно использовать как таковое, но помните, что perl - это столько же виртуальная машина, сколько и Java - perl компилируется (на лету) в байт-код, который затем выполняется. Там нет JIT, но кроме этого это все еще виртуальная машина с вашим кодом.
Tanktalus

Ответы:

15

Философия 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, где спрашивают, каким образом использовать библиотеку.

Сообщество
источник
4
+ 1. Интересная информация. Принимая во внимание все это, почему в SO так много постов, пытающихся защитить / атаковать Perl как старый язык? Мне это кажется мощным и полезным.
user10326
2
У каждого свой любимый язык. Многие считают, что если язык не может поддерживать новую вещь на этой неделе, язык устарел и устарел, и с него все следует убрать. Другие тратят значительное время на изучение определенного языка и знают, как заставить его работать там, где он есть. Это легко изменить на любой язык, который движется не так быстро, как The Hot New Language. Perl страдает определенным лишением прав, когда требуется время, чтобы получить Perl 6 (в любой день ... ошибаться ... год сейчас!). Это не должно удерживать от изучения Perl - оно используется во многих местах.
1
Скорее всего, вы обнаружите, что Perl - это лингва-франка для сценариев Linux, берущая на себя большую часть роли сценариев оболочки с давних времен. Только самые стойкие сценаристы оболочки будут жаловаться, если вы пишете сценарий perl, а не bash при выполнении сценариев в системе * nix. Одна из самых важных вещей для Perl - это CPAN - если кто-то собирается написать какую-то библиотеку разумного размера, просто проверьте, не написал ли это кто-то еще.
1
Все, что раньше было сценарием оболочки некоторой сложности или выше, теперь часто является сценарием perl. Perl также часто работает как клей / клейкая лента между системами или приложениями. Его обработка строк также сделала его дома в нескольких других отраслях (в частности, в биоинформатике - просто посмотрите, сколько вопросов на основе ДНК существует в теге perl SO).
4
Perl - это надежный и полный язык программирования. Его можно использовать для создания сценариев (автоматизации взаимодействия с другими приложениями, включая оболочку), или для создания утилит, или даже для более масштабных приложений. Ненависть Perl имеет тенденцию концентрироваться на таких вещах, как его плотный синтаксис и, в некоторой степени, на неправильном понимании того факта, что Perl не пытается навязать определенные шаблоны проектирования своим пользователям. Я использую Perl каждый день. Я также часто использую другие языки. Мне нравится выразительность и сила Perl. Пройдите неловкий этап обучения и, скорее всего, вам это тоже понравится.
DavidO
7

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

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

Карл Билефельдт
источник
1
Почему многие считают это плохим вариантом карьеры? Кажется, что он мощный и может дополнять другие языки как часть набора инструментов.
user10326
3
Скажем так, другие языки почти такие же мощные и имеют гораздо более врожденную структуру. Компании любят структуру.
Карл Билефельдт
Для хорошего учебника Perl ООП проверьте codeproject.com/Articles/3152/Perl-Object-Oriented-Programming
Pmarcoen
1
Это хороший урок по ООП, объясняющий встроенный стиль ООП в Perl. Если вы находите этот код немного многословным, вас может заинтересовать библиотека Perl Moose, которая автоматизирует большую часть повторяющегося кодирования во встроенном ОО. Но лучше всего начинать (IMH0) со встроенного стиля.
Мэтт Фрейк
1
Я никогда не считал Perl плохим вариантом карьеры. Найдите местную группу Perl Mongers, и есть вероятность, что почти на каждом собрании кто-то будет упоминать вакансии в Perl.
DavidO
3

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

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

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

Солнечный Патель
источник
0

Есть много способов справиться с повторным использованием кода в 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 пакетов.

Джеймс Аандерсон
источник