삶은달걀노른자

■ 13장 컴포넌트 응집도 Component Cohesion ​ 컴포넌트 응집도 관련 3가지 원칙이 있다. ​ 1. 재사용/릴리스 등가 원칙 REP: The Reuse/Release Equivalence Principle 2. 공통 폐쇄 원칙 CCP: The Common Closure Principle 3. 공통 재사용 원칙 CRP: The Common Reuse Principle ​ 1. 재사용/릴리스 등가 원칙 REP 재사용 단위는 릴리스 단위와 같아야 한다. 어떤 라이브리를 사용하고 신규 버전으로 업데이트하는 경우 우리는 릴리스 번호를 참조한다. 어찌 보면 매우 당연하고 직관적인 원칙이다. 설계 관점에서 보면 컴포넌트 안에는 응집성 높은 클래스와 모듈만 있어야 한다. 이들은 버전 번호가 같아야 하고..

◆ Part 4 컴포넌트 원칙 Components Principles ​ ■ 12장 컴포넌트 Components ​ 컴포넌트는 배포의 단위로 자바의 jar, 닷넷의 dll, 루비의 gem 등이 있다. 오늘날에는 이런 파일들을 기존 어플리케이션에 플러그인 형태로 배포하는 것이 일반적이다. ​ 책에서 말하는 컴포넌트 역시 런타임에 플러그인 형태로 결합할 수 있는 동적 링크 파일이다. 컴포넌트 아키텍처를 적용하기 위해 과거에는 초인적인 노력이 필요했지만 현재는 기본으로 쉽게 사용할 수 있는 수준이 되었다. ​ ​

■ 11장 DIP: 의존성 역전 원칙 Dependency Inversion Principle ​ 유연성이 극대화된 시스템 = 소스코드 의존성이 추상 abstraction 에 의존하며 구체 concretion 에는 의존하지 않는 시스템이다. 의존을 피해야 하는 것은 변동성이 큰 volatile 구체적인 요소이다. 이 구체적인 요소는 한창 개발중이라 자주 변경될 수밖에 없는 모듈이라고 할 수 있다. 쉽게 말해 구체인 class가 추상인 interface를 참조하는 모습을 생각하면 된다. ​ - 변동성이 큰 구체 클래스를 (직접)참조하지 말 것. 대신 추상 팩토리 Abstract Factory 를 사용한다. - 변동성이 큰 구체 클래스로부터 파생(상속)하지 말 것. - 구체 함수를 오버라이드 override ..

■ 10장 ISP: 인터페이스 분리 원칙 Interface Segregation Principle ​ User1이 op2와 op3을 사용하지 않음에도 이 두 메소드가 OPS에 포함되어 있으므로 User1은 OPS에 의존성을 가진다. op2 소스가 변경되면 User1도 재컴파일과 재배포를 해야 한다. ​ 이런 경우는 아래 그림과 같이 인터페이스로 분리하여 해결할 수 있다. ​ 자바와 같은 정적 타입 언어가 아닌 루비나 파이썬 같은 동적 타입 언어의 경우는 위와 같은 문제를 초래하는 import, use, include가 없기 때문에 소스코드 의존성이 아예 없으므로 재컴파일과 재배포가 불필요하다. 그래서 동적 타입 언어는 보다 유연하고 결합도가 낮은 시스템을 만들 수 있기 때문에 ISP를 아키텍처가 아닌 언..

■ 9장 LSP: 리스코프 치환 원칙 Liskov Substitution Principle ​ 리스코프는 사람 이름이다. ( Barbara Liskov ) 바바라 리스코프 - 위키백과, 우리 모두의 백과사전 위키백과, 우리 모두의 백과사전. ko.wikipedia.org 리스코프 치환 원칙이란, 자료형 S가 자료형 T의 하위형이라면, 프로그램에서 자료형 T의 객체는 프로그램의 속성을 변경하지 않고 자료형 S의 객체로 교체할 수 있어야 한다는 뜻이다. ​ ​ 위 설계는 LSP를 준수하는데, Billing 어플리케이션의 행위가 License 하위 타입 중 무엇을 사용해도 전혀 상관없기 때문이다. 즉, 의존성이 없다. 이들 하위 타입은 모두 License 타입을 대체할 수 있다. ​ ​ ​

■ 8장 OCP: 개방-폐쇄 원칙 Open-Closed Principle ​ 객체는 확장에는 열려 있어야 하고(개방), 변경에는 닫혀 있어야 한다.(폐쇄) 변경되는 코드의 양을 최소화 하기 위해서는, 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고(단일책임원칙 SRP), 이들 요소 사이의 의존성을 체계화(의존성역전원칙 DIP)해야 한다. ​ ​ 위 그림에서 화살표 A -> B는 소스코드 의존성의 방향으로 A에서 B를 호출한다는 뜻이다. 컴포넌트 관계는 단방향으로만 이루어져야 하는데, 화살표의 방향은 변경으로부터 보호하려는 컴포넌트를 향하고 있다. A에서 발생한 변경으로부터 B를 보호하려면 A가 B에 의존해야 한다. (즉, A -> B) ​ 위에서 우측 상단의 Interactor는 업무규칙을 포함하므..

◆ Part 3 설계 원칙 Design Principles ​ 좋은 시스템은 깔끔한 코드로부터 시작되며 이를 가능하게 하는 아키텍처 원칙이 SOLID이다. 이 원칙의 목적은 중간 수준의 소프트웨어 구조를 잘 만드는 데에 있다. 중간 수준이라 함은 코드 수준보다는 조금 상위에서 적용할 수 있다는 말이며, 모듈과 컴포넌트 내부에서 사용되는 소프트웨어 구조를 정의하는 데 도움을 준다. ​ SOLID는 다음의 다섯 가지 원칙이다. ​ - SRP : Single Responsibility Principle / 단일 책임 원칙 - OCP: The Open-Closed Principle / 개방-폐쇄 원칙 - LSP: The Liskov Substitution Principle / 리스코프 치환 원칙 - ISP: T..

■ 6장 함수형 프로그래밍 Functional Programming ​ 함수형 프로그래밍은 사실 프로그래밍 그 자체보다 앞서 등장했다. 이 패러다임의 핵심은 람다 lamda 계산법으로서 알론조 처치 Alonzo Church 가 1930년대에 발명했다. ​ 함수형 언어에서는 변수가 변경되지 않는다. 변수의 불변성이 중요한 이유는 바로 경합조건 race condition, 교착상태 deadlock, 동시 업데이트 concurrent update 문제가 모두 가변변수로부터 발생하기 때문이다. 아키텍트는 당연히 이러한 동시성 concurrency 문제에 관심을 가져야 한다. ​ 서비스를 가변 mutable 컴포넌트와 불변 immutable 컴포넌트로 분리하여 어느정도 이 문제를 해결할 수 있다. 또한 이벤트 소..

■ 5장 객체지향 프로그래밍 Object-Oriented Programming ​ OO의 본질을 설명하기 위해 3가지 특성을 살펴보자. ​ 1. 캡슐화 사실 캡슐화는 C 언어에서 완벽하게 구현되었었고 오히려 C++에서 완벽한 캡슐화가 깨지게 되었다. 클래스의 멤버변수를 클래스 헤더 부분에 선언하도록 함으로써 해당 헤더파일(xxxx.h 같은)을 사용하는 측에서 멤버변수의 존재를 알 수 있기 때문이다. 따라서 OO가 강력한 캡슐화에 의존한다는 정의는 받아들이기 어렵다. ​ 2. 상속 OO 언어가 있기 전에도 상속을 흉내낼 수는 있었지만 OO 언어에서 확실히 상속을 편리하게 만든 건 사실이다. 게다가 다중 상속은 기존에 훨씬 어려웠다. 그래서 OO에 있어 캡슐화에 대해서는 0점, 상속에 대해서는 0.5점을 주..

■ 4장 구조적 프로그래밍 Structured Programming 네덜란드 태생의 데이크스트라 Edsger Wybe Dijkstra 는 1950~60년대에 goto 문장의 폐단과 반대로 goto의 좋은 사용 방식이 if/then/else, do/while과 같은 분기와 반복이라는 단순한 제어 구조에 해당한다는 사실을 발견했다. 또한 이 시기에 모든 프로그램은 순차, 분기, 반복 이라는 세 가지 구조만으로 표현할 수 있다는 것이 사실로 증명되었다. 구조적 프로그래밍이 현재까지 가치있는 것은 프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 능력 때문이다. 현대 언어가 아무 제약없는 goto 문을 지원하지 않는 이유이기도 하다. 또한 아키텍처 관점에서는 기능적 분해를 최고의 실천법 중 하나로 여기는 이..