안녕하세요. Humanscape Software Engineer David 입니다.
클린아키텍처 책 중 패러다임의 개요에 대해 공부한 내용을 공유하려합니다.
패러다임 paradigm 이란?
어떤 한 시대 사람들의 견해나 사고를 근본적으로 규정하고 있는 테두리로서의 인식의 체계. 또는 사물에 대한 이론적인 틀이나 체계.
책에서는 프로그래밍의 패러다임을 구조적 프로그래밍, 객체 지향 프로그래밍, 함수형 프로그래밍 3가지로 설명하고 있습니다.
구조적 프로그래밍(1968, 에츠허르 비버 데이크스트라), 객체 지향 프로그래밍(1966, 올레 요한 달, 크리스텐 니가드), 함수형 프로그래밍(1930, 알론조 처치)으로 세 패러다임 모두 반세기 이상의 역사가 있습니다.
재미있는 것은 프로그래밍에서 이 세 가지 외의 패러다임은 현재 존재하지않고 앞으로도 존재하지않을 것이라는 걸 책에서 설명하고 있습니다.
그리고 우리가 반세기 동안 배운건 해서는 안될 것에 대해서라고 하는데요.
즉, 패러다임은 무엇을 해야 할지를 말하기보다는 무엇을 해서는 안되는지를 말해준다고 합니다. 각각 살펴보겠습니다.
구조적 프로그래밍(Structured Programming)
: 제어의 직접적인 전환에 부과되는 규율
구조적 프로그래밍을 처음 고안한 데이크스트라는 프로그래밍은 어렵고, 프로그래머들은 프로그래밍을 잘하지 못한다는 문제의식을 합니다.
인간의 뇌가 감당하기에는 너무나 많은 세부사항들이 있기 때문인데, 수학적 증명으로 이 문제를 해결하려합니다.
즉 프로그래머는 입증된 구조를 이용하고 이를 코드와 결합해 코드가 올바르다는 사실을 스스로 증명하게 되는 연구인데, 이는 상당히 힘들었습니다.
goto 문이 모듈을 더 작은 단위로 재귀적으로 분해하는 과정에 방해가 된다는 사실이 모듈을 분해할 수 없어서 분할 정복 접근법으로 증명 불가능 하다는 사실을 깨닫습니다.
goto 문의 좋은 사용방식은 if/then/else, do/while과 같은 분기와 반복이라는 단순한 제어구조로의 사용이라는 것을 깨달았습니다.
그리고 프로그램은 순차, 분기, 반복으로 구성되어있고 이 제어구조가 프로그래밍 제어구조의 최소 집합이라는 사실 증명해내며 구조적 프로그래밍은 탄생하게 됩니다.
프로그래밍은 과학에 더 가깝다.
데이크스트라의 프로그래밍 관점에서 정리에 대한 유클리드 계층구조의 증명에 대한 연구는 끝내 증명 해내지 못하게 됩니다.
하지만 다른 전략으로 과학적 방법으로 접근할 수 있습니다.
뉴턴의 운동법칙과 만유인력의 법칙은 옳다고 증명할 수 없습니다. 시연할 수 있고 소수점 많은 자리까지의 정확도는 측정할 수 있지만 수학적으로 증명할 수는 없습니다.
즉, 과학적 방법은 수학과는 달리 반증은 가능하지만 그 올바름은 증명 할 수 가 없습니다.
소프트웨어 테스트는 버그가 있음을 보여줄 뿐 버그가 없음을 보여줄 수는 없다는 점에서 소프트웨어는 오히려 과학과 같습니다.
그렇기 때문에 구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강조합니다. 그리고 세부 기능들이 거짓인지를 증명하려고 시도하는데요.
이게 실패한다면, 이 기능들은 목표에 부합할 만큼은 충분히 참이라고 여기게 됩니다.
구조적 프로그래밍이 오늘날까지 가치 있는 이유는 프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 능력 때문입니다. 현대적 언어가 아무런 제약 없는 goto 문을 지원하지 않는 이유이기도 합니다.
대규모 시스템을 모듈과 컴포넌트로 나눌 수 있습니다.
우리는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록 만들기 위해 분주히 노력해야합니다.
객체 지향 프로그래밍(Object Oriented Programming)
: 제어흐름의 간접적인 전환에 부과되는 규율
캡슐화
비슷한 역할을 하는 속성과 메소드들을 하나의 클래스로 모은것을 캡슐화 라고 합니다. 캡슐화에 속한 개념으로 정보 은닉이라는것이 있는데, 캡슐 내부의 로직이나 변수들을 감추고 외부에는 기능(api)만을 제공하는것을 의미합니다.
하지만 많은 언어가 캡슐화를 강제하지는 않습니다. 객체 지향 프로그래밍은 프로그래머가 충분히 올바르게 행동함으로써 캡슐화된 데이터를 우회해서 사용하지 않을 거라는 믿음을 기반으로 합니다.
상속
상속이란 클래스를 재사용 하는 것입니다. 상위 클래스를 하위 클래스에서 상속 받게 되면 상위 클래스의 멤버변수나 메소드를 그대로 물려 받을 수 있습니다. 상속이 있기 때문에 코드를 재활용할 수 있고 그렇기 때문에 생산성이 높고 유지보수 하기가 좋습니다.
다형성
다형성은, 같은 모양의 함수가 상황에 따라 다르게 동작 하는것을 의미합니다. 오버로딩과 오버라이딩이 있는데, 오버로딩이란것은 함수의 이름은 같으나 함수의 매개변수 숫자, 타입등을 달리해서 다르게 사용하는것을 의미하고, 오버라이딩은 상위 클래스의 메소드를 하위 클래스에서 똑같은 이름으로 재정의 하는것을 의미합니다.(덮어씌우기) 이렇게 되면, c++의 경우에는 상위 클래스 타입 변수에 하위 클래스를 담은 상태에서 메소드를 호출하면 상위 클래스의 메소드가 호출되고, 하위 클래스 타입 변수에 하위 클래스를 담으면 하위 클래스의 메소드가 호출됩니다. 즉, 메소드의 이름은 똑같은데, 상황(상위 클래스의 참조 변수냐 하위 클래스의 참조 변수냐)에 따라 호출 되는 메소드가 다른것입니다.
객체 지향 프로그래밍은 다형성을 이용하여 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어 권한을 획득할 수 있는 능력입니다. 플러그인 아키텍처의 구현이 가능해졌고, 모듈 간 독립성 보장, 독립적 개발, 독립적 배포를 가능하게 해주었습니다.
함수형 프로그래밍(Functional Programming)
: 변수 할당에 부과되는 규율
함수형 언어에서 변수는 변경되지 않습니다.
명령 언어에서 a=3; a=4;는 a에 3이라는 값을 대입하고 4로 바꾸는 명령인 반면에, 함수형 언어에서는 a=3이 a를 3 그 자체로 정의합니다.. 즉 한번 a를 3으로 정의했다면 그 정의는 그 정의가 존재/유효하는 범위(scope)까지는 절대 바뀌지 않습니다. 그렇기 때문에 심지어는 a를 선언하기 전에 사용하는 것조차 가능하다.
이런 특징에서 나오는 장점으로 표현식의 의미가 명료해진다는 것이 있습니다. 또, 제어 흐름을 생각하지 않고 프로그래밍 할 수 있다는 장점이 있습니다. 디버깅을 할 때도, 명령형 언어에서 버그를 잡을 때는 변수들의 전후 변화를 생각하면서 머리를 싸맬 때, 함수형 언어는 scope만 잘 확인하면 쉽게 디버깅 할 수 있습니다. 절차형 언어와는 달리 눈에 핏발을 세우고 변수가 어떻게 변화하나 추적할 필요가 없다며 함수형 언어 팬들은 자랑하고는 합니다.
경합 조건, 교착상태 조건, 동시 업데이트 문제가 모두 가변 변수로 인해 발생하기 때문입니다. 즉, 다수의 스레드와 프로세스를 사용하는 애플리케이션에서 마주치는 모든 문제는 가변 변수가 없다면 절대로 생기지 않습니다.
단, 저장 공간이 무한하고 프로세서의 속도가 무한히 빠르다고 전제한다면 대답은 대체로 긍정적일 것입니다. 하지만 우리의 세계는 그렇지않으니 타협이 필요합니다.
결론적으로는 애플리케이션을 제대로 구조화하려면 변수를 변경하는 컴포넌트와 변경하지 않는 컴포넌트를 분리해야 한다는 것입니다.
현명한 아키텍트라면 가능한 많은 처리를 불변 컴포넌트로 옮겨야하고, 가변 컴포넌트에서는 가능한 많은 코드를 빼내야합니다.
이벤트 소싱은 상태가 아닌 트랜잭션을 저장하자는 전략 계좌의 잔고를 구할 때 모든 트랜잭션을 각기 기록해놓았다가 합을 구하는 것이 이벤트 소싱의 기본 발상입니다.
소스 버전관리 프로그램인 Git이 정확히 방식으로 작동합니다.
1946년 앨런 튜링이 전자식 컴퓨터에서 실행할 거의 최초의 코드를 작성할 때 사용한 소프트웨어 규칙과 지금의 소프트웨어 규칙은 조금도 다르지않습니다. 도구도 달라졌고 하드웨어도 변했지만, 소프트웨어의 핵심은 그대입니다.
소프트웨어는 순차, 분기, 반복, 참조로 구성되며 그 이상도 이하도 아니다.
마무리
구조적 프로그래밍은 goto문을, 객체지향 프로그래밍은 함수 포인터, 함수형 프로그래밍은 할당문을 우리에게서 앗아갔습니다.
각 패러다임이 제시하는 하지말아야할 것들 우리가 알게 모르게 쓰고 있지는 않나요?
빨리가는 유일한 방법은 제대로 가는 것이다
- 로버트 C 마틴
우리 모두 제대로 가는 코딩라이프가 되길 바래요. 다음에 또 만나요!
감사합니다.
Get to know us better! Join our official channels below.
Telegram(EN) : t.me/Humanscape KakaoTalk(KR) : open.kakao.com/o/gqbUQEM Website : humanscape.io Medium : medium.com/humanscape-ico Facebook : www.facebook.com/humanscape Twitter : twitter.com/Humanscape_io Reddit : https://www.reddit.com/r/Humanscape_official Bitcointalk announcement : https://bit.ly/2rVsP4T Email : support@humanscape.io
[출처]
함수형 프로그래밍(Functional Programming)
https://simsimjae.tistory.com/293
가입하기
