• 책 내용을 간략하게 정리한다만, 주기적으로 읽어보는 것을 권장한다
  • http://www.yes24.com/Product/Goods/77283734

소개

• 1960년대나 지금이나 코드는 sequence, selection, itration의 반복이다
• 언어는 조금씩 발전하고 툴은 좋아졌지만, 프로그래밍을 이루는 기본 요소들은 변하지 않는다
• 그래서 현재의 내가 과거로 돌아가 종이테이프로 구멍을 뚫어 코딩하는 시대로 간다면, 하루가 지나고 금방 적응하여 코드를 작성할 수 있을거라고 한다, 그 반대도 마찬가지

• 소프트웨어에선 행위, 아키텍처 이 2가지 관점이 중요하다는데, 위 매트릭스에 도입해보면 아래와 같은 결론을 얻는다
  • 소프트웨어의 행위, 기능 개발이라 생각할 수 있는데, 긴급하지만 항상 중요도를 가지진 않는다
  • 소프트웨어의 아키텍처는 중요하지만 긴급하진 않다
• 위 결론과 함께 매트릭스에 도입하면 아키텍처가 행위보다 더 중요하단 걸 알 수 있다
  • 1. Do - 긴급, 중요 → 아키텍처, 행위
  • 2. Decide - 긴급X, 중요 → 아키텍처
  • 3. Delegate - 긴급, 중요X → 행위
  • 4. Delete

프로그래밍 패러다임

• 구조적 프로그래밍
  • 구조적 프로그래밍은 메인 프로그램을 여러 서브 기능을 담은 프로그램으로 분해
  • 그런데 이 분해 작업을 컨트롤 할 수 없는 것이 goto문인데, 서브 분해를 하기 위해선 goto를 기피할 것
• 객체 지향 프로그래밍
  • 캡슐화, 상속, 다형성을 가진 프로그래밍
  • 특히 다형성을 이용하여 코드 의존성을 역전시켜 코드 수정에 대한 어려움을 완화
• 함수형 프로그래밍
  • 불변성, 변수를 변경하지 않는 것이 원칙
  • 불변성이 있으면 race 경합, deadlock 같은 문제를 해결할 수 있음

설계 원칙

• 집을 만드는 것에 비유하자면, 좋은 벽돌이 있어야 좋은 집을 만드는데, 이 재료에 대한 원칙이 SOLID
• SRP, 단일 책임 원칙
  • 모듈은 하나의 요구사항에 대해서만 책임을 져야 한다
• OCP, 개방 폐쇄 원칙
  • 확장은 유연함과 동시에 변경은 작아야 한다
• LSP, 리스코프 치환 원칙
  • 객체 지향 개념으로 어느 두 객체를 코드에 치환했을 때 수정 되지 않는 다면 상속 관계를 나타낼 수 있다
• ISP, 인터페이스 분리 원칙
  • 인터페이스로 유연함을 늘리고 의존성을 추가한다
• DIP, 의존성 역전 원칙
  • 코드 의존성은 추상적인 것에만 의존해야 한다

컴포넌트 원칙