구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다.
객체지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다.
함수형 프로그래밍은 할당문에 대해 규칙을 부과한다.
각 패러다임은 프로그래머에게서 권한을 박탈한다. 어느 패러다임도 새로운 권한을 부여하지 않는다.
즉, 패러다임은 무엇을 해야할지를 말하기보다는 무엇을 해서는 안되는지 말해준다.
이러한 논의를 바라보는 또 다른 방법은 각 패러다임이 우리에게서 무언가를 빼앗는다는 사실을 인지하는 것이다.
구조적 프로그래밍
가장 작은 기능에서부터 가장 큰 컴포넌트에 이르기까지 모든 수준에서 소프트웨어는 과학과 같고, 따라서 반증 가능성에 의해 주도된다. 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록 만들기 위해 분주히 노력해야 한다. 이를 위해 구조적 프로그래밍과 유사한 제한적인 규칙들을 받아들여 활용해야 한다.
객체지향 프로그래밍
제어흐름은 시스템의 행위에 따라 결정되며, 소스 코드 의존성은 제어흐름에 따라 결정되었지만, 다형성이 끼어들면 제어흐름을 반대로 돌릴 수 있다. 이를 의존성 역전이라 부르며, 소프트웨어 아키텍트 고나점에서 이러한 현상은 심오한 의미를 갖는다.
객체지향 언어가 다형성을 안전하고 편리하게 제공한다는 사실은 소스 코드 의존성을 어디에서든 역전시킬 수 있다는 뜻이기도 하다.
소스 코드 의존성이 제어흐름의 방향과 일치되도록 제한되지 않는다. 호출하는 모듈이든 아니면 호출 받는 모듈이든 관계없이 소프트웨어 아키텍트는 소스 코드 의존성을 원하는 방향으로 설정할 수 있다.
객체지향이란 다형성을 이용하여 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어권한을 획득할 수 있는 능력이다. 객체지향을 사용하면 아키텍트는 플러그인 아키텍쳐를 구성할 수 있고, 이를 통해 고수준의 정책을 포함하는 모듈은 저수준의 세부사항을 포함하는 모듈에 대해 독립성을 보장할 수 있다. 저수준의 세부사항은 중요도가 낮은 플러그인 모듈로 만들 수 있고, 고수준의 정책을 포함하는 모듈과는 독립적으로 개발하고 배포할 수 있다.
함수형 프로그래밍
아키텍트는 왜 변수의 가변성을 염려하는가? 경합, 교착, 동시 업데이트 문제가 모두 가변 변수로 인해 발생하기 때문이다. 우리가 동시성 애플리케이션에서 마주치는 모든 문제, 즉 다수의 스레드와 프로세스를 사용하는 애플리케이션에서 마주치는 모든 문제는 가변 변수가 없다면 절대로 생기지 않는다.
현명한 아키텍트라면 가능한 한 많은 처리를 불변 컴포넌트로 옮겨야 하고, 가변 컴포넌트에서는 가능한 한 많은 코드를 빼내야 한다.
결론
이들 세 패러다임 모두 우리에게서 무언가를 앗아간다.
지난 반세기 동안 우리가 배운것은 해서는 안되는 것에 대해서다.
이 사실을 깨닫는다면 우리는 환영받지 못할 사실, 즉 소프트웨어는 급격히 발전하는 기술이 아니라는 진실과 마주하게 된다. 앨런튜링이 전자식 컴퓨터에서 실행할 최초의 코드를 작성할 때와 지금은 소프트웨어 규칙은 조금도 다르지 않다. 도구와 하드웨어는 달라졌지만 소프트웨어의 핵심은 여전히 그대로이다.
소프트웨어는 순차, 분기, 반복, 참조로 구성된다. 그 이상 그 이하도 아니다.
3가지 패러다임부분 이해 잘 못했는데 그냥 넘어감
Loading Comments...