밥아저씨는 2장을 들어가며 세 가지의 패러다임에 대해 설명을 한다.
- 구조적 프로그래밍
- goto문장 → if / then / else 와 do / while / until 로 대체
- 제어흐름의 직접적인 전환에 대해 규칙을 부과
- 객체 지향 프로그래밍
- stack frame을 heap으로 옮기면, 함수 호출이 반환된 이후에도 함수에 선언된 지역변수가 오랫동안 유지되는 것을 발견 → 함수가 클래스의 생성자, 지역변수는 인스턴스 변수, 중첩 함수는 메서드가 되었다.
- 함수 포인터를 특정 규칙에 따라 사용하는 과정을 통해 필연적으로 다형성 등장
- 제어흐름의 간접적인 전환에 대해 규칙을 부과
- 함수형 프로그래밍
- 제일 먼저 만들어졌지만 최근 들어서 겨우 도입되기 시작
- John McCarthy가 만든 LISP 언어의 근간이 되는 개념이 바로 이 람다 계산법!
- 할당문에 대해 규칙을 부과
이러한 패러다임들은 우리에게 무엇을 해야할 지를 말하기보다는 "무엇을 해서는 안 되는지를 말해준다.
구조적 프로그래밍
goto문장 → if / then / else 와 do / while / until 로 대체하라는 규칙이다.
goto문장을 사용하게 되면, 모듈을 더 작은 단위로 분해하는 과정에 방해가 되는 경우가 있다.
예를한번 찾아보았다.
int main()
{
int num;
printf("숫자 입력 : ");
scanf(%d", &num);
if(num == 1)
goto label1; //label1이라는 레이블로 이동하라는 의미이다.
elseif(num == 2)
goto label2; //label2이라는 레이블로 이동하라는 의미이다.
else
goto label3; //label3이라는 레이블로 이동하라는 의미이다.
//label
label1:
printf("1을 입력 했습니다.");
label2:
printf("2을 입력 했습니다.");
label3:
printf("3혹은 다른값을 을 입력 했습니다.");
return 0;
}왜일까?
사실 goto문을 들어만 봤지 사용해본 적도 없고 해서 왜인지 궁금하여 찾아보았다.
goto문은 프로그램의 구조를 해치기 때문에 goto문을 사용한 소스는 이식성과 재사용에 무척 불리하다. 특정 동작을 하는 코드를 다른 프로그램에서 재사용하려면 goto문에 의해 엉켜 있는 실 을 다 풀어야 하고 옮긴 후에 다시 그 프로그램에 맞게 연결해야 하기 때문
→ 위의 예제는 goto문이 3개 뿐이지만 만약 수십개가 있다고하면,, goto문이 여기저기를 돌아다니고있을 것이다.
코드 순서도 어떻게되는지 알기 힘들것이다, 만약 분리해야 할 경우 분리해야 할 부분도 잡기 힘들것같은데. 그래서 위의 표현처럼 엉켜 있는 실 이라고 표현이 딱 맞을것 같다. 그래서 그뒤를 조금더 읽어보니 goto 문 없이도 사실 프로그램을 순차, 분기, 반복 이라는 세가지 구조만으로 표현할 수 있다.
구조적 프로그래밍을통해 우리는 더 작은 단위의 모듈로 분리할 수 있을 것이다. 또한 분리해야 될 부분도 좀 더 명확해질것이다.
결론은?
모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트하기 쉽도록) 만들기 위해 컴포넌트를 잘 분리해야 한다.
객체 지향 프로그래밍
객체 지향을 들어가며, 좋은 아키텍처를 만드는 일은 객체지향(Object-Oriented, OO) 설계 원칙을 이해하고 응용하는 것 부터 출발한다고 말한다.
OO란?
OO 는 세 가지 부류가 있는데 캡슐화, 상속, 다형성이다.
이에 대해 밥아저씨의 생각을 정리 해 보았다.
-
캡슐화
캡슐화가 존재하긴 하지만, C언어 외의 다른언어는 실제로 C 언어에서 누렸던 완벽한 캡슐화를 약화시켜왔다.
-
상속
상속이 객체지향에서 새롭게 등장한 방식은 아니지만, 나름대로 편리하게 사용할 수 있게 하긴 했다.
-
다형성
다형성도 사실 이전부터 표현할수있는 방식이었다.
하지만, 기존의 방식을 크게 개선했고 매우 큰 효과를 냈다.
사실 밥 아저씨는 캡슐화에 대해서는 별로 인정 안 하고 상속 그리고 다형성 에 주로 의의로 두었는데, 그중에서 특히 "다형성" 이 아키텍트 적인 관점에서 가지는 의의를 매우 크게 보였다.
다형성이란 뭘까?
일반적으로 제어 흐름은 시스템의 행위에 따라 결정되며, 소스 코드의 의존성은 제어 흐름에 따라 결정된다. 그래서 제어 흐름의 방향은 항상 고수준 로직에서 저수준 로직으로 향하게 된다.
이때 다형성이 끼어들면 무언가 특별한 일이 일어난다. 다형성이란, 쉽게 말해 고수준 로직에서 저수준 로직으로 흘러가는 흐름 사이에 추상 로직을 두는 것을 말한다. 이렇게 하면, 프로그램의 로직은 다음처럼 바뀐다.
- 기존 : (고수준 로직) → (저수준 로직)
- 다형성 적용 후 : (고수준 로직) → (추상 로직) ← (저수준 로직)
→ 로 흘러가던 방향이 ← 로 제어흐름이 반대인 점을 주목, 이를 의존성 역전이라고 한다.
이러한 현상은 특별한 의미를 갖는다. OO가 안전하고 편리하게 다형성을 제공한다는 사실은 소스 코드 의존성을 어디서든 역전시킬 수 있다는 뜻이다.
결론
💡 OO란 다형성을 이용하여 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어 권한을 획득 할 수 있는 능력.함수형 프로그래밍
Eli가 어려울거라던 함수형 프로그래밍에 들어왔다.
함수형 프로그래밍의 개념은 프로그래밍 그 자체보다 앞서 등장 했는데, 이 패러다임에서 핵심이 되는 기반은 람다계산법으로 알론조 처치가 1930에 개발 했다.
자바는 가변 변수를 사용하는데, 가변 변수는 실행 중에 상태가 변할 수 있다.
하지만 클로저에서는 이러한 가변변수가 전혀 없다ㅏ. 클로저에서는 x와 같은 변수가 한 번 초기화되면 절대 변하지 않는다.
이는 우리에게 놀라운 것을 알려주는데, 함수형 언어에서 변수는 변경되지 않는다 는 것이다.
하지만 불변성이 정말로 실현 가능한가?
- 저장공간이 무한하고 프로세서의 속도가 무한이 빠른 전제한다면 가능하다.
자원이 무한대가 아니라면 조금 미묘하다.
그래서 불변성은 실현 가능하지만 타협을해야한다.
하나는 가변 컴포넌트와 불변 컴포넌트로 분리하는 하고, 가능한 한 많은 처리를 불변 컴포넌트로 옮기고, 가변 컴포넌트에서는 가능한 한 많은 코드를 빼내야 한다.
결론
💡 불변 컴포넌트와 가변 컴포넌트를 분리하여 관리하자.
정리하자면
- 구조적 프로그래밍은 제어흐름의 직접적인 전환에 부과되는 규율이다.
- 직접적이란
goto를 사용하지않는것.
- 직접적이란
- 객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 부과되는 규율이다.
- 함수형 프로그래밍은 변수 할당에 부과되는 규율이다.
