Perl의 프로그래밍 스타일

Java로 작업하므로 기본적으로 코딩 중에 OOP 패러다임을 사용합니다. 저는 Perl에서 일을 시작하려고하는데 Perl 개발자들이 따르는 패러다임이 무엇인지 궁금했습니다. 위키에서는 많은 패러다임을 지원한다고 언급하지만 스크립트 언어이기 때문에 이것을 이해하지는 못합니다.

그래서 내 질문은 : Perl의 Java 관용구에 익숙한 객체 지향 패턴입니까, 효과적인 Perl을 작성하려면 디자인 스타일을 크게 변경해야합니까?

참고 : 이것은 Perl을 비판하는 질문이 아닙니다. 저는 실제로 Perl에서 일해야하며 현재 프로그램 방식이 어떻게 바뀌는 지 이해하고 싶습니다.

펄의 철학은 "지금 실천적인 일을하는"철학이다. OOP를 사용해야하는 경우 OOP가 필요합니다. 모든 솔루션에 필요한 것은 아니며, 간단한 "이 작업을 수행 한 다음이 작업"유형의 문제인 경우 OOP 코드를 작성하도록 강요하는 경우가 종종 있습니다.

Perl의 다중 패러다임 특성은 Schwartzian 변환 과 같이 매우 기능적인 측면을 볼 수 있습니다 (Lisp에서는 "장식-정렬-장식하지 않음"이라고 함). OOP는 절차 적 (C와 같은 프로그래밍)과 명령형 ( "이것 다음에 이렇게하라")과 같이 존재한다.

디자인 패턴은 일반적인 문제에 대한 해결책을 되풀이하고 있습니다. 그들은 모든 언어로 존재 합니다. 때로는 이러한 패턴을 관용구라고하지만 패턴보다 훨씬 단순한 것을 나타낼 수도 있습니다.

필요한 경우 많은 클래식 GOF 디자인 패턴을 펄로 구현할 수 있습니다. Perl 디자인 패턴 은 사람들이 GOF에 익숙한 많은 공통 이름을 갖습니다. 그들 모두가 관용적 펄일 필요는 없습니다.

펄 디자인 패턴을 탐험 할 때, 또한 주목하시기 바랍니다 아닌가 "디자인 패턴" 에 의해 마크 주인님 .

많은 사람들이 디자인 패턴이 언어의 결함 이라고 생각합니다 . 이러한 관점에서 반복자와 같은 디자인 패턴은 종종 perl에서 필요하지 않습니다. 항상 그런 것은 아니지만 종종.

먼저 관용 펄을 작성하십시오. 펄에 C를 쓰거나 펄에 lisp를 쓰거나 펄에 java를 쓰려고하지 마십시오. Perl은 perl입니다. 관용적 펄이 처리 할 수있는 것보다 더 큰 문제가 있고 더 복잡한 클래스 구조가 필요하면 작성하십시오. "이 문제는 이제 추상 팩토리가 필요한 시점까지 커졌다"는 것을 인식 할 수있는 디자인 패턴을 알고 있습니다. 그러나 필요하지 않은 경우 추상 팩토리를 펄로 만들려고하지 마십시오.

일부 라이브러리는 OOP 및보다 전통적인 형식으로 존재합니다. 함수 지향 또는 객체 지향 CGI 인터페이스를 사용해야합니까?를 참조하십시오 . 라이브러리를 사용할 방법을 묻는 오래된 SO 질문.

패러다임에 대한 Perl의 입장은 TMTOWTDI입니다 (여러 가지 방법이 있습니다). 이것이 많은 사람들이 농담으로 Perl을 쓰기 전용 언어 라고 부르는 이유 중 하나입니다 . 다른 사람의 스타일이 당신의 스타일과 완전히 다를 수 있기 때문에 그것을 읽는 것보다 작성하는 것이 훨씬 쉽습니다.

즉, OOP는 확실히 Perl에서 지원됩니다. 타사 코드를 많이 사용하는 경우 OOP 일 수도 있고 아닐 수도 있지만, 자신의 코드에 대해서는 마음의 내용에 대해 OOP를 수행 할 수 있습니다. 나는 실제로 Perl에서 OOP를 처음 배웠다. 먼저 C ++을 시도했지만 어떤 이유로 "클릭"하지 않았습니다.

나는 같은 상황에 처해 있었고, 오랫동안 자바를 사용하고 있습니다.

Perl로 이사 한 것은 충격과 안도감 이었지만 'Perl Best Practices'라는 책을 사용했습니다. 많은 도움이되며 프로그래밍 언어의 기본 개념을 이해하면 쉽게 흐를 수 있습니다.

펄을 사용하는 방법은 여러 가지가 있다는 것을 기억하십시오. 특정 코드를보고 수정하는 데 많은 시간을 소비했지만 결국 간단한 구문 오류로 작업이 완료됩니다.

Perl에서 코드 재사용을 처리하는 여러 가지 방법이 있습니다. 많은 예제는 접근 방식과 다른 클래스의 차이를 명확하게 나타내지 않으며 적어도 두 가지를 사용합니다.

OO 스타일을 최대한 사용하는 것이 좋으며 상대적으로 작은 유틸리티 함수 클러스터가 필요한 클래스가 3 개 이상인 경우에만 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;

EXPORTER함수가 x 또는 y 축에서 현재 패키지로 들어오는 것처럼 OO 접근 방식과 접근 방식을 코드 가용성의 두 가지 차원 으로 시각화하는 것을 선호합니다 .

위의 예에서 :

Foo::Barfoo()클래스 에서 메소드 를 파생시킵니다Foo

Foo::Barbar()다형성 메소드 bar()가 클래스에서 파생되지 않도록 메소드를 정의합니다.Foo

클래스 둘 Foo과 Foo::Bar수신 EXPORTED기능 ( 하지 방법 ) util()패키지 (에서 하지 클래스 )Foo::Util

두 시스템은 복잡해 보이지만 매우 실용적인 유틸리티입니다. 여러 상속을 추적하면 까다로울 수 있습니다. 따라서 코드 가용성의 두 번째 차원을 가지면 상속 트리를 작고 관리하기 쉽게 유지할 수 있습니다.

일반적으로 함수가 모 놀리 식이고 상대적으로 멍청한 경우 EXPORTER를 사용하고, 그렇지 않으면 상속을 사용하십시오. 그러나 할 EXPORTER일이 3 개 또는 4 개가 넘는 패키지를 포함하지 않는 한 전혀 사용하지 않아도 됩니다.