기능적 프로그래밍 (Part 0) : 프로그래밍 패러다임 간 간략한 비교

반응형

이 기사는 "함수 프로그래밍"에 대해 설명하는 시리즈의 일부입니다.

바로 이 부분에서는 프로그래밍 패러다임에 대해 알아보겠습니다. 명령적 패러다임과 선언적 패러다임을 만지고 있습니다. 최소한의 예와 비교로 실행한다. 마지막으로, 우리는 몇 가지 패러다임을 진화론적 관점에서 살펴볼 것입니다.

목차

• 프로그래밍 패러다임
• 명령 패러다임
• 선언적 패러다임
• 합계 예시의 추가 마일
• 진화 관점
• 결론

프로그래밍 패러다임

 

프로그래밍 패러다임은 프로그래밍의 스타일 또는 방식이다. 그래서 어떤 언어들은 우리가 특정한 패러다임으로 글을 쓰도록 강요합니다. 다른 언어들은 프로그래머에게 선택권을 열어둔다. 각 패러다임이 일련의 개념을 따른다. (제목 그림을 봐주세요-아직 그렇지 않다면, "패러다임" 단어가 의미를 가질 수 있도록.

컴퓨터 프로그래밍의 역사에서, 엔지니어들은 다른 언어들을 개발해왔다. 각각의 언어는 마음속에 패러다임을 가지고 있었다. 이러한 패러다임은 다음 두 가지 주요 범주 중 하나에 속한다.

1. 명령 패러다임

여기서 제어 흐름은 명시적이며, 프로그래머는 프로그램의 상태를 변경하는 방법을 지시한다. 더 많은 패러다임을 포함하는 경우:

• 구조 패러다임
• 객체 지향 패러다임

 

2. 선언적 패러다임

여기서 제어 흐름은 암시적이며, 프로그래머는 어떻게 해야 하는지를 명시하지 않고 프로그램에게 지시한다. 더 많은 패러다임을 포함하는 경우:

• 기능 패러다임
• 논리 패러다임
• 수학적 패러다임
• 반응적 패러다임

간단한 결론:

대부분의 언어는 명령형 또는 선언형 패러다임에 속하며, 각 패러다임은 일련의 개념을 따른다.

 

다음 두 가지 주요 패러다임에 대해 자세히 알아보겠습니다.

명령과 선언의 패러다임.

1. 명령 패러다임

명령형 패러다임은 구조적인 측면에서 (구조적인 패러다임 때문에) 약간 진화했지만, 여전히 문제가 있다.

• 프로그램 수행 방법(컨트롤 흐름이 명시적임)
• 공유 상태

 

생각을 좀 더 가깝게 하기 위해서. 위의 두 가지 문제에 대해 두 가지 유사점을 살펴보겠습니다(문제를 이해한 경우 다음 부분을 건너뛰고 예제로 이동할 수 있습니다).

문제 1: 프로그램에 작업 수행 방법을 알려줍니다(컨트롤 흐름이 명시적임).

• 사례: 그들을 미션을 향해 이끄는 선두를 가진 1,000명의 직원을 상상해 보십시오. 리더는 1000명의 직원들에게 하나씩 일을 하는 방법을 알려주기 시작합니다. 얼마나 안 좋을 것 같아? 저는 이런 미시적 수준의 경영방식이 중대한 위험과 함정을 가지고 있고 심지어 효과가 없을 것이라는 것을 알 수 있다고 확신합니다.
• 해결책: 책임 분야의 사람들을 그룹화하고 각 그룹에 팀장을 위임합니다. 각 조의 리더는 임무를 위해 할 줄 알아야 합니다. 그렇게 되면 복잡성과 병목 현상이 많이 줄어들고 관리도 훨씬 쉬워질 것입니다.
• 이 비유에서
  — 미션 리더 = 프로그래머.
  — 그룹 리더 = 상위 기능
  — 각 그룹의 직원 = 코드 라인
• 결론: 우리가 프로그램 레벨에 더 높은 수준의 조직 구조를 적용한다면, 우리의 삶은 훨씬 더 부드러워질 것입니다.

문제 2: 공유 상태

• 사례: 당신이 아버지라고 상상해보세요, 당신은 두 아이가 있습니다. 당신은 그들을 위한 공유 은행 계좌를 만들었습니다. 매달 1000달러씩 그 계좌에 넣어주시는군요. 귀하의 자녀 모두 계정이 공유된 것을 알지 못합니다. 그래서 그들은 각자 1000달러씩 자신에게 쓸 돈이 있다고 생각한다. 월말에 당신은 그 계좌에 -1000달러가 있다는 것을 알았기 때문에 망하는 것이다.
• 해결책: 각 자녀는 별도의 계정과 월별 금액이 있어야 합니다.
• 이 비유에서:
  — 하위 = 기능
  — 공유 은행 계정 = 공유 상태입니다.
• 결론: 기능이 동일한 상태를 공유하는 경우. 그들은 무의식적으로 그것을 사용합니다. 이것은 2가지 기능만으로 당신의 프로그램 상태를 엉망으로 만들 것입니다. 따라서 각 함수는 사용할 수 있는 독립적인 상태를 갖는 것이 항상 더 좋습니다.

 

명령 패러다임의 예

명령 패러다임에서 합이 어떻게 구현될 수 있는지 살펴보겠습니다.

왜 이것이 필수로 여겨지는가?

• 프로그램 작업 방법(컨트롤 흐름이 명시적임)을 알려줍니다. 우리는 for 루프에 명시적으로 작업 방법을 알려줍니다. 또한 어레이의 각 요소에 명시적으로 액세스합니다.
• 공유 상태: 결과 변수는 공유 상태이며, 모든 반복에서 변이됩니다(더 큰 문제에서 공유 상태를 처리하는 것은 훨씬 더 어렵습니다).

2. 선언적 패러다임

 

선언적 패러다임은 프로그래머가 어떻게 해야 하는지를 명시하지 않고 프로그램에게 지시하는 것이다.

명령적 패러다임과는 달리 선언적 패러다임은 명령적이지 않습니다. 즉, 선언적 패러다임에서는 다음과 같은 함수를 작성한다.

• (암시적 컨트롤 흐름) 대신 프로그램이 수행해야 하는 작업을 설명합니다.
• 부작용이 발생하지 않도록 하십시오(나중에 자세히 논의하겠습니다).

선언적 패러다임의 예

우리는 합계함수가 명령 패러다임에서 어떻게 구현될 수 있는지 보았고, 선언적으로 어떻게 구현될 수 있는지 살펴보자.

 

마법! 그렇지? 하지만 왜 그것이 선언적인 것으로 여겨지나요?

• (암시적 제어 흐름) 대신 프로그램이 수행해야 하는 작업을 설명합니다. 반복자(반복자)도 없고 루프에 작동 방법이나 요소 접근 방법을 명시적으로 알려주지 않습니다. 그것은 reduce를 사용함으로써 달성되었다.
• 부작용 없음: 공유 상태는 부작용의 한 형태로, 환원 및 추가 기능의 구성을 사용하여 완전히 제거되었습니다.

합계 예시의 추가 마일:

짝수만 합치면 어떨까요?

반드시 해야 할 일은 다음과 같습니다.

 

하지만 선언적으로 우리는 할 것이다:

보시다시피, 두 패러다임(임페러다임과 선언적 패러다임)을 비교하려는 경우, 선언적 패러다임(우리의 경우 기능 패러다임)은 기어 620과 더 유사하며, 기어를 별도의 유닛으로 개발한 다음 필요한 곳에 추가하면 됩니다. 그러나 명령 패러다임에서는 거의 모든 것이 동일한 코드로 혼합되고 융합됩니다(단, 실제로 디자인 패턴을 훌륭하게 수행한 경우는 제외).

일반적으로 선언적 패러다임은 다음과 같다.

• 예측 가능
• 테스트 가능
• 재사용 가능
• 사용자 지정 가능
• 캐시 가능
• 유지관리 가능
• 컴포지터블

이러한 점들 중 일부는 총체적 예시의 맥락에서 반드시 말이 되는 것은 아니지만, 향후 기사에서는 말이 될 것이다.

 

진화 관점

우리는 명령과 선언의 두 가지 주요 패러다임을 이해한 후, 각각 하위 패러다임을 가집니다. 이제 구조적, 객체 지향적, 기능적 패러다임에 대해 더 이야기해 보겠습니다. 진화론적인 관점에서 보면요

각각의 패러다임은 새로운 것을 도입함으로써 프로그래밍 방식을 제한해왔다. 최고의 도약은 다음과 같다.

• 구조 패러다임: if/else/then/loop 등과 같은 구조를 우리 코드에 도입함으로써 got의 제한된 사용과 "제어 전달의 흐름"입니다. 다시 말해, 그것은 제어의 이전 흐름을 제약한다.
• 객체 지향 패러다임: 상속을 이용한 다형성을 도입함으로써 함수에 대한 포인터를 이용한 다형성 수행이 제한된다.
• 기능 패러다임: 불변성을 도입하여 공유 상태와 부작용을 제한했습니다.

각 패러다임은 하나 이상의 다른 패러다임의 개념을 사용할 수 있다는 것을 명심하십시오(예를 들어, 객체 지향 패러다임과 기능 패러다임 모두 구조 패러다임 개념을 사용합니다).

 

결론

현실에서, 우리는 다른 수준의 숙련도를 필요로 하는 다른 스타일의 패러다임을 가지고 있습니다. 더 많은 패러다임을 실천하면 더 많은 초능력을 갖게 될 것이고, OO는 초능력과 FP도 가지고 있습니다. 당신이 이러한 패러다임에서 더 강해질수록, 당신의 해결책은 더 강력해질 것이고, 사람들은 당신의 주위에 더 안전하다고 느낄 것입니다.

시간을 내어 이 기사를 읽어주셔서 정말 감사합니다. 저는 다음 시리즈 요리를 하고 있습니다. 이 글이나 앞으로 나올 글에 대한 코멘트에 대해 어떻게 생각하시는지 피드백 부탁드려요.

다음은 함수 프로그래밍에 대한 일련의 기사의 기사입니다.

이 일련의 기사에서 우리는 함수 프로그래밍의 주요 개념을 다룹니다. 시리즈가 끝나면 보다 기능적인 접근 방식으로 문제를 해결할 수 있습니다.

 

이 시리즈에서는 다음에 대해 설명합니다.

0. 프로그래밍 패러다임 간 간략한 비교

• 부작용
• 퍼스트 클래스 함수
• 순수함수
• 폐업
• 카레링
• 구성.
• 함수자
• 모나드

리소스:

• https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html
• https://cs.lmu.edu/~ray/notes/sigms/
• https://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html
• https://blog.cleancoder.com/uncle-bob/2017/07/11/PragmaticFunctionalProgramming.html
• https://blog.cleancoder.com/uncle-bob/2012/12/19/Three-Paradigms.html
• https://en.wikipedia.org/wiki/Programming_paradigm
• https://en.wikipedia.org/wiki/Procedural_programming
• https://en.wikipedia.org/wiki/Functional_programming
• https://en.wikipedia.org/wiki/Non-structured_programming