Styl programowania w Perlu

Pracuję w Javie, więc zasadniczo używam paradygmatu OOP podczas kodowania. Zaraz zacznę pracować w Perlu i zastanawiałem się, jaki jest paradygmat, którym kierują się programiści Perla. W wiki wspomina, że ​​obsługuje wiele paradygmatów, ale nie jestem pewien, czy to rozumiem, ponieważ jest to język skryptowy.

Więc moje pytanie brzmi: czy wzorce obiektowe, które znam w Javie idiomatyczne w Perlu, czy będę potrzebował znaczących zmian w moim stylu projektowania, aby napisać skuteczny Perl?

Uwaga: To nie jest pytanie do krytykowania Perla. Właściwie muszę pracować w Perlu i chciałbym zrozumieć, jak zmieni się obecny sposób programowania.

Filozofia Perla polega na tym, że „rób to, co jest teraz praktyczne”. Jeśli potrzebujesz użyć OOP, jest tam. Nie jest to konieczne we wszystkich rozwiązaniach i zmuszanie osoby do pisania kodu OOP, gdy jest to proste „zrób to, to wtedy” ten typ problemu często przynosi efekt przeciwny do zamierzonego.

Wieloparadygmatyczną naturę perla można dostrzec w takich rzeczach, jak transformacja Schwartziana, która ma bardzo funkcjonalne aspekty (w Lisp jest znana jako „decorate-sort-undecorate”). OOP istnieje, podobnie jak proceduralne (programowanie w stylu C) i imperatywne (bash jak „zrób to, to teraz”).

Wzory projektowe to powtarzające się rozwiązania typowych problemów. Istnieją w każdym języku. Czasami te wzorce nazywane są idiomami, chociaż może to również odnosić się do rzeczy, które są znacznie prostsze niż wzór.

W razie potrzeby wiele klasycznych wzorców projektowych GOF można zaimplementować w perlu. Wzory projektowe Perla będą miały wiele popularnych nazw, które ludzie znają GOF. Nie jest konieczne, aby wszystkie z nich były idlomatyczne.

Podczas eksploracji wzorców projektowych w Perlu, zwróć również uwagę na „Wzory projektowe” nie są autorstwa Marka Dominusa .

Wiele osób uważa, że Wzory Projektowe to braki w języku . W tej perspektywie wzorce projektowe, takie jak Iterator, są często niepotrzebne w perlu. Nie zawsze - ale często.

Najpierw napisz idlomatyczny perl. Nie próbuj pisać C w perlu, lisp w perlu lub java w perlu. Perl to perl. Jeśli istnieje problem, który staje się większy niż peri idiomatyczny może sobie poradzić i zaczynasz potrzebować bardziej złożonych struktur klas, to napisz je. Poznaj wzorce projektowe, aby móc rozpoznać „ten problem urósł do tego stopnia, że ​​potrzebujesz abstrakcyjnej fabryki” - ale nie zaczynaj próbować tworzyć abstrakcyjnej fabryki w Perlu, jeśli jej nie potrzebujesz.

Niektóre biblioteki istnieją zarówno w OOP, jak i bardziej tradycyjnych formach. Zobacz Czy powinienem używać interfejsów CGI zorientowanych funkcyjnie czy obiektowo? po stare pytanie SO, w którym pyta się, w jaki sposób korzystać z biblioteki.

Postawa Perla wobec paradygmatów to TMTOWTDI (istnieje więcej niż jeden sposób, aby to zrobić). Jest to jeden z powodów, dla których wiele osób żartuje nazywać Perla językiem tylko do pisania . O wiele łatwiej jest pisać niż czytać, ponieważ styl innej osoby może być zupełnie inny niż twój.

Biorąc to pod uwagę, OOP jest z pewnością obsługiwany w Perlu. Jeśli używasz dużo kodu strony trzeciej, może to być OOP, ale dla własnego kodu możesz robić OOP według własnego uznania. Właściwie pierwszy raz nauczyłem się OOP w Perlu. Najpierw wypróbowałem C ++ i z jakiegoś powodu nie „kliknął”.

Jestem w tej samej sytuacji, używam Javy od dłuższego czasu,

Przeprowadzka do Perla była dla mnie szokiem i ulgą, ale skorzystałem z książki zatytułowanej „Najlepsze praktyki Perla”. To bardzo pomaga, a jeśli rozumiesz podstawowe pojęcia dotyczące języków programowania, łatwo jest z tym po prostu płynąć.

Pamiętaj tylko, że w Perlu jest więcej niż jeden sposób, aby to zrobić. Spędziłem niezliczone godziny, patrząc na określony kod i modyfikując go, ale w końcu robi to z prostym błędem składni.

Istnieje wiele sposobów obsługi ponownego wykorzystania kodu w Perlu. Wiele przykładów nie wyjaśnia rozróżnienia między podejściami, a wiele klas używa co najmniej dwóch.

Radzę używać stylu OO w jak największym stopniu i używaj EKSPORTERA tylko wtedy, gdy masz co najmniej trzy lub więcej klas, które potrzebują stosunkowo niewielkiego skupienia funkcji narzędziowych.

Więc:

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;

Wolę wizualizować podejście OO i EXPORTERpodejście jako dwa różne wymiary dostępności kodu, tak jakby funkcje przychodziły do ​​bieżącego pakietu od osi X lub Y.

W powyższym przykładzie:

Foo::Barwywodzi metodę foo()z klasyFoo

Foo::Bardefiniuje bar()metodę, więc metoda polimorficzna bar()nie jest pochodną klasyFoo

Zarówno klasy, jak Fooi funkcja Foo::Barodbierająca EXPORTED( nie metoda ) util()z pakietu ( nie klasa )Foo::Util

Oba systemy wydają się skomplikowane, ale mają bardzo praktyczną użyteczność. Śledzenie wielokrotnego dziedziczenia może być trudne. Zatem posiadanie drugiego wymiaru dostępności kodu pozwala utrzymać małe drzewo dziedziczenia i zarządzać nim.

Ogólnie, jeśli funkcja jest monolityczna i względnie głupia, użyj EKSPORTERA, w przeciwnym razie użyj dziedziczenia. Ale nie zawracaj sobie głowy używaniem, EXPORTERchyba że to, co zamierzasz zrobić, może obejmować więcej niż 3 lub 4 paczki.