아키텍쳐 - 프로그래밍 패러다임

패러다임

프로그래밍에도 패러다임이 있다. 

 

• 구조적 프로그래밍
• 객체지향 프로그래밍
• 함수형 프로그래밍

프로그래밍 패러다임은 프로그래머가 무엇을 할 지가 아니라 무엇을 하면 안 되는지를 말해준다. 위의 3가지 규칙은 프로그래머에게 goto문, 함수 포인터, 할당문을 뺏는다. 

 

---

구조적 프로그래밍

goto문은 프로그램의 모듈을 분해하는 것을 방해한다. 만약 모듈을 분해할 수 없다면 분할 정복 기법의 사용이나 각각의 모듈을 테스트 하는데 어려움이 있을 것이다. 구조적 프로그래밍은 goto문의 사용을 제한함으로써 프로그래밍에서 테스트 가능한 단위를 작게 만들어 낸다. 이렇게되면 프로그래머가 각각의 컴포넌트, 모듈...등을 쉽게 테스트할 수 있다.

 

---

객체 지향 프로그래밍

흔히 객체 지향 프로그래밍의 요소로 캡슐화, 상속, 다형성을 꼽는다. 그러나 정말 저 3가지 모두가 객체 지향만의 요소일까? 사실 캡슐화는 C언어에서도 충분히 구현 가능하며, 그렇게 사용 된다. (헤더에 필요한 것들만 노출 시킴) 상속은 객체 지향에서 좀 더 편하지만, 그렇다고 C언어에서도 불가능한 것은 아니었다. 그렇다면 다형성은? 다형성 역시 객체 지향이 등장하기 전부터 존재했고, 사용되어왔다. C언어는 이러한 다형성을 함수 포인터로 구현했다. 그러나 함수 포인터는 위험하다. 함수 포인터를 사용하는 방식은 프로그래머가 특정 관례를 지켜야 하며 이러한 관례를 지키지 못했을 때는 찾아내기 어려운 버그가 발생한다. 객체 지향은 함수포인터 없이 다형성을 제공하므로써 다형성에 대한 접근성을 크게 키웠다.

 

의존성 역전

또한 객체지향에서는 인터페이스를 통해 의존성을 역전시킬 수 있다. 보통은 의존성(상속 관계)와 제어 흐름이 같은 방향이다. 즉 상위 객체가 하위 객체에 의존하는 것이 전통적인 방법이었다. 그러나 인터페이스를 통한다면 이런 의존성을 역전시킬 수 있는데 이러한 접근법 덕에 개발자는 제어흐름을 결정할 수 있는 권한을 갖게 된다. SOLID의 원칙 중 하나인 DIP(의존성 역전 원칙)을 생각해보자. 객체 지향은 이것을 가능하게 한다. 즉, 객체 지향은 고수준의 모듈을 저수준의 모듈과 독립 시키며 각각의 모듈은 독립적으로 배포되고 개발될 수 있다.

 

---

함수형 프로그래밍

반복문을 돌린다 하면 자바같은 언어에서는 가변 변수인 i를 사용하게 될 것이다. 이처럼 많은 언어가 가변 변수를 사용한다. 그러나 함수형 언어에서 가변 변수는 없다. 그렇다면 가변 변수가 없는게 왜 좋을까? 왜냐면 경헙, 교착, 동기화의 문제가 모두 가변 변수로 인해 발생하기 때문이다. 그렇다고 해서 가변 변수를 안 쓰기란 현실적으로 어렵다. 그렇다면 가변 컴포넌트와 불변 컴포넌트를 분리하는 선에서 타협을 볼 수 있다. 불변 컴포넌트는 순수하게 함수형 방식만 사용하며 가변 변수는 없다. 그리고 이런 불변 컴포넌트는 하나 이상의 가변 컴포넌트와 연결될 수 있다. 가능한 많은 것들을 불편 컴포넌트로 구성하고 가변 컴포넌트는 최소로 줄이는 것이 좋은 아키텍쳐라고 할 수 있다. 

 

이벤트 소싱

상태가 아니라 트랙잭션의 리스트를 저장하는 것이다. 예를 들어 SVN이나 git의 작동 방식을 보자. 이것들은 상태가 아니라 트랜잭션들을 저장한다. 그리고 이것들은 완전한 함수형으로 불변성을 가진다. 저장 공간과 처리 능력이 충분하다면 모든 애플리케이션이 불변성을 가질 수 있다. 혹은 상태를 중간중간 백업한 뒤 거기서부터 다시 트랜잭션을 저장하는 방법을 택할 수도 있다. 참고하자