Styl programowania w Perlu

9

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.

użytkownik10326
źródło
3
Mówiąc poważniej,
Robert Harvey
Perl obsługuje OOP. Możesz budować hierarchie klas, implementować funkcje wirtualne itp. Nie jest to najczęstsze użycie, ale można to zrobić.
Martin York,
„ponieważ jest to język skryptowy” - może być używany jako taki, ale pamiętaj, że perl jest maszyną wirtualną jak Java - perl jest kompilowany (w locie) do kodu bajtowego, który jest następnie wykonywany. Nie ma JIT, ale poza tym nadal jest to maszyna wirtualna z uruchomionym kodem.
Tanktalus

Odpowiedzi:

15

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.

Społeczność
źródło
4
+ 1. Ciekawe informacje. Biorąc to pod uwagę, dlaczego w SO jest wiele postów próbujących bronić / atakować Perla jako starego języka? Wydaje mi się potężny i użyteczny.
user10326,
2
Każdy ma swój ulubiony język. Wielu uważa, że ​​jeśli język nie jest w stanie wesprzeć Nowej Rzeczy w tym tygodniu, jest on stary i przestarzały i wszystko należy od niego usunąć. Inni poświęcili dużo czasu na naukę określonego języka i wiedzą, jak sprawić, by działał w miejscu, w którym się znajduje. Można to łatwo zmienić na dowolny język, który nie porusza się tak szybko, jak Gorący nowy język. Perl cierpi z powodu szczególnego pozbawienia praw obywatelskich, gdy czas potrzebny na zdobycie Perla 6 (każdego dnia… nie… rok teraz!). Nie powinno to zniechęcać do nauki perla - jest używane w wielu miejscach.
1
Prawdopodobnie przekonasz się, że perl jest lingua franca dla skryptów linuksowych, biorąc większość roli skryptowania powłoki od dawnych czasów. Tylko najbardziej zagorzałe skrypty powłoki będą narzekać, jeśli napiszesz skrypt perla, a nie bash podczas wykonywania skryptów w systemie * nix. Jedną z najważniejszych rzeczy dla Perla jest CPAN - jeśli masz zamiar napisać bibliotekę o rozsądnej wielkości, po prostu sprawdź, czy ktoś już ją napisał.
1
Wszystko, co kiedyś było skryptem powłoki o pewnej złożoności lub większym, jest teraz często skryptem perla. Perl często działa również jako taśma klejąca / klejąca między systemami lub aplikacjami. Przetwarzanie ciągów sprawiło, że znalazło się również w domu w kilku innych branżach (szczególnie w bioinformatyce - wystarczy spojrzeć na liczbę pytań opartych na DNA w znaczniku perl na SO).
4
Perl to solidny i kompletny język programowania. Można go używać do tworzenia skryptów (automatyzacji interakcji z innymi aplikacjami, w tym z powłoką), do budowania narzędzi, a nawet do aplikacji na większą skalę. Nienawiść do Perla zwykle koncentruje się na takich rzeczach, jak jego gęsta składnia, a do pewnego stopnia na niezrozumieniu faktu, że Perl nie próbuje narzucać użytkownikom określonych wzorców projektowych. Używam Perla każdego dnia. Często używam także innych języków. Lubię ekspresję i moc Perla. Przejdź przez niezręczny etap nauki, a szanse na to, że go pokochasz.
DavidO
7

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ął”.

Karl Bielefeldt
źródło
1
Dlaczego wiele osób uważa, że ​​jest to zła opcja kariery? Wydaje się, że jest potężny i może uzupełniać inne języki jako część zestawu narzędzi.
user10326,
3
Powiedzmy, że inne języki są prawie tak samo wydajne i mają o wiele bardziej nieodłączną strukturę. Firmy lubią strukturę.
Karl Bielefeldt
Dobry samouczek Perl OOP znajdziesz na codeproject.com/Articles/3152/Perl-Object-Oriented-Programming
Pmarcoen
1
To dobry samouczek OOP, wyjaśniający wbudowany styl OO Perla. Jeśli okaże się, że ten kod jest nieco szczegółowy, możesz zainteresować się biblioteką Perl Moose, która automatyzuje wiele powtarzalnych kodowań we wbudowanym OO. Ale najlepiej zacząć (IMH0) od wbudowanego stylu.
Matt Freake
1
Nigdy nie uważałem Perla za złą opcję kariery. Znajdź lokalną grupę Perl Mongers, a są szanse, że na prawie każdym spotkaniu ktoś wspomni o ofertach pracy Perl.
DavidO
3

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.

Sunny Patel
źródło
0

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.

James Aanderson
źródło