13. 컴포넌트 응집도 REP: 재사용/릴리스 등가 원칙 (Reuse/Release Equivalence Principle) 재사용 단위는 릴리스 단위와 같다 릴리스 번호가 없다면 재사용 컴포넌트들이 서로 호환되는지 보증할 방법이 없다. 릴리스 절차에는 적절한 공지와 함께 릴리스 문서 작성도 포함되어야 한다. 컴포넌트를 구성하는 모든 모듈은 ...

12. 컴포넌트 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성 가능 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. 컴포넌트의 간략한 역사 개발 초창기에는 메모리에서의 프로그램 위치와 레이아웃을 프로그래머가...

11. DIP: 의존성 역전 원칙 유연성이 극대화된 시스템이란 소스코드 의존성이 추상(abstract)에 의존하며, 구체(concretion)에 의존하지 않는 시스템 자바와 같은 정적 언어에서는 오직 인터페이스나 추상 클래스 같은 추상적인 선언만 참조해야 한다는 뜻 동적 타입 언어에도 동일한 규칙 적용 소프트웨어 시스템이라면 구체적인 많은 장치...

9. LSP: 리스코프 치환 원칙 상속을 사용하도록 가이드하기 애플리케이션의 행위가 하위 타입 중 무엇을 사용하는지에 대해 전혀 의존하지 않음 -> LSP 준수 정사각형/직사각형 문제 LSP를 위반하는 전형적인 문제 Square는 Rectangle의 하위 타입으로는 적합하지 않음 Rectangle의 높이와 너비는 서로 독립적으로 변경될...

8. OCP: 개방-폐쇄 원칙 소프트웨어 개체는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다. 사고 실험 소프트웨어 아키텍처가 훌륭하다면 변경되는 코드의 양이 가능한 한 최소화 됨 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고, 이들 요소 사이의 의존성을 체계화함으로써 변경량을 최소화 가능 아키텍트는 기능이 어떻게, 왜, 언...

7. SRP: 단일 책임 원칙 단 하나의 일만 해야 한다는 원칙은 SRP가 아님(헷갈림 주의!) 단일 모듈은 변경의 이유가 하나, 오직 하나뿐이여야 한다 하나의 모듈은 하나의, 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다. 하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다. 모듈은 단순히 함수와 데이터 구조로 ...

6. 함수형 프로그래밍 정수를 제곱하기 자바 프로그램은 가변 변수를 사용하는데, 함수형 프로그래밍에서는 가변 변수를 사용하지 않는다. 함수형 언어에서 변수는 변경되지 않는다. 불변성과 아키텍처 경합(race) 조건, 교착상태(deadlock), 동시 업데이트(concurrent update) 문제가 모두 가변 변수로 인해 발생 동시성 애플리...

10. ISP: 인터페이스 분리 원칙 다수의 사용자가 한 클래스에서 각기 다른 메소드 사용 자신이 사용하지 않는 메소드가 배포될 때 영향을 받음 그래서 분리가 필요함 ISP와 언어 정적 타입 언어는 소스코드에 포함된 선언문(import, include …)로 인해 소스코드 의존성이 발생하고, 이로 인해 재컴파일 또는 재배포가 필요함 동적 타...

5. 객체 지향 프로그래밍 캡슐화? 데이터와 함수를 쉽고 효과적으로 캡슐화하는 방법을 OO언어가 제공 이를 통해 데이터와 함수가 응집력 있게 구성된 집단을 서로 구분 짓는 선을 그을 수 있다. 사실 C언어에서도 완벽한 캡슐화 가능 오히려 OO언어에서 캡슐화 기능이 훼손됨 이 때문에 OO가 강력한 캡슐화에 의존한다는 정의는 받아들이기 힘들다....

4. 구조적 프로그래밍 증명 Goto 문의 좋은 사용 방식은 if/then/else와 do/while과 같은 분기와 반복이라는 단순한 제어 구조 이러한 제어 구조는 순차 실행과 결합했을 때 좋다. 모든 프로그램은 순차, 분기, 반복으로 표현 가능하다는 사실을 증명 해로운 성명서 성명서로 인해 goto문과 논쟁 goto가 패배 기능적 분해...