Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

패턴 그리고 객체지향적 코딩의 법칙 책 요약정리

8,055 views

Published on

책 [패턴 그리고 객체지향적 코딩의 법칙] 요약 정리하였습니다.
책 제목: 패턴 그리고 객체지향적 코딩의 법칙
저자: 문우식
출판사: 한빛미디어
출간일: 2007년 11월 11일

Published in: Software
  • Be the first to comment

패턴 그리고 객체지향적 코딩의 법칙 책 요약정리

  1. 1. 패턴 그리고 객체지향적 코딩의 법칙 책 요약정리 - 작성자: 황대영 - 수정일자: 2016.05.15
  2. 2. 목차 • 저자 • 책 소개 • 요약정리 기준 • 1. 어떤 코드가 잘 만들어진 것일까 • 2. C로 개발하면 안되나요? • 3. 공통점 묶기, 조금만 알기 • 4. 회사에선 사원, 군대에선 군인, 편의점에선 손님 • 5. 체계적인 정리법이 필요하다
  3. 3. 목차 • 6. 컴퓨터는 생각보다 훨씬 빠르다 • 7. 패턴은 이름 붙여진 것일뿐 • 8. 빠르게 더 빠르게 • 9. 이쁜 코드 만들기 • 10. 쉬운 그림으로 이해하기 • 11. 객체 생성은 객체 생성 전문가에게 • 12. 관점의 차이가 곧 객체 생성의 차이 • 13. 필요한 것은 알아서 만들자
  4. 4. 목차 • 14. 순서를 정리하면 시점이 보인다 • 15. 복잡한 조립은 조립 전문가에게 맡기자 • 16. 오직 하나뿐인 그대 • 17. 너의 쌍둥이가 필요해 • 18. 수정할 수 없는 너무 안정적인 당신 • 19. 무슨 일 생기면 바로 알려줘 • 20. 한 가지 탐색법만 기억하라 • 21. 복합구조도 접근법은 하나
  5. 5. 목차 • 22. 난 기분에 따라 행동이 달라져 • 23. 골라 쓰는 알고리즘 • 24. 공유되는 정보와 대리인 • 25. 행동만 따로 떼어보자 • 26. 꾸미는 방법도 가지가지 • 27. 객체지향을 넘어서
  6. 6. 저자 - 문우식 • 현재 (주)카뮤즈의 책임연구원으로 근무중 • PC, 서버, 웹, 모바일, 하드웨어, 임베디드 시스템등의 다양한 경험 • 특히 C++과 JAVA의 철학을 좋아한다 • 또한 실무를 통해 얻은 경험만이 진정한 지식이라고 믿으며 개발은 끝없이 밀려오는 요구사항과의 싸움이라고 생각하는 초보 아키텍트
  7. 7. 책 소개 • 제목 : 패턴 그리고 객체지향적 코딩의 법칙 • 출판사 : 한빛미디어 • 출간일 : 2007년 11월 11일 • 책은 꼭 사서 봅시다! • 현재는 절판되고 eBook으로 구매 가능합니다. • http://www.yes24.com/24/goods/6116359?scode=032&OzSrank=1
  8. 8. 요약정리 기준 • 디자인 패턴은 아주 간략히 정리하여 생략하였다. • 의미 전달에 왜곡이 없도록 중요하다고 생각하는 문장을 그대로 가져왔다. • 예제는 C++ 코드 위주로 되어 있는데 생략되어 있으므로 이해하는데 본 슬라이드만 봐서는 어려움이 있을 수 있다. • 책을 직접 사서 본 후 본 슬라이드를 보는 것을 권장한다.
  9. 9. 1. 어떤 코드가 잘 만들어진 것일까 • 요구사항을 만족시키는 코드의 가치를 평가하는 가장 큰 기준은 변화하는 요구사항을 얼마나 안정적으로 수용할 수 있는가이다. • 객체 지향의 중요 요소인 공통적인 성질을 묶는 ‘그 무엇'을 가리키는 키워드(key word)가 필요할 것이다. => 클래스 • 프로그래밍 세계에서 공통적 성질을 가지는 종류라는 것은 곧 서로 관련이 있는 데이터와 함수를 의미한다.
  10. 10. 1. 어떤 코드가 잘 만들어진 것일까 • 결과는 같지만 그 결과를 쉽게 도출하고 재사용할 수 있으며 변화하는 요구사항에 적절히 대응할 수 있는 가장 쉬운 방법이 객체지향이기 때문에 사랑받는 것이다.
  11. 11. 2. C로 개발하면 안되나요? • C++은 상속, 캡슐화, 다형성 그리고 그밖에 디자인 패턴으로 대변되는 여러 가지 유용한 테크닉이 존재하기 때문에 C++로 개발해야 한다. • 개발 방법의 기본 • 개발을 체계적으로 진행할 수 있는가? • 개발하기 쉬운가? • 관리하기 쉬운가? • 확장하기 쉬운가? • 안정적인가?
  12. 12. 2. C로 개발하면 안되나요? • C로 작성할 경우 기본적으로 지켜야 할 규칙 • 관련된 구조체와 함수를 쉽게 연관 지을 수 있는가? • 구조체의 변수들은 어떻게 수정되어야 하는가? • 의도되지 않은 수정이 이루어졌을 경우 어떻게 동작해야 하는가? • 사용해야 될 함수와 말아야 될 함수들은 어떻게 구분하는가?
  13. 13. 2. C로 개발하면 안되나요? • 객체지향 언어에서 객체라는 것은 메모리상의 데이터를 직접적으로 다루는 로우 레벨(low-level)인 기계적 개념이 아닌 좀 더 하이 레벨(high-level)의 논리적 개념이 기본이 된다. • 개발자가 일일이 신경써 주면서 GIMP처럼 이해하기 쉽도록 만드는데 비용이 100이라면 객체지향 언어에서 제공하는 클래스라는 도구를 이용하면 그 비용을 50 정도로 줄일 수 있다.
  14. 14. 2. C로 개발하면 안되나요? • 현실적으로 최소한 수 만줄 이상의 코드를 작성할 때 진정한 개발 방법론의 가치를 알 수 있다. • 객체지향 프로그래밍은 구조적 프로그래밍이 가지는 단점을 보완하면서 더 큰 프로그램을 개발하는데 적합한 개념과 여러 가지 언어적 지원이 덧붙여진 연구와 경험의 산물이다.
  15. 15. 3. 공통점 묶기, 조금만 알기 • 공통점 묶기와 조금만 알기 이 두가지 개념만 완벽히 이해하고 지킬 수 있어도 객체지향의 절반은 이루었다 • 함수들의 공통점을 묶고 나아가 클래스간의 공통점을 묶고 컴포넌트간의 공통점을 묶고 이렇게 잘 묶어서 정리하다 보면 그게 바로 객체지향 프로그래밍이고 컴포넌트 프로그래밍이다. • 아주 간단한 공통점 묶기가 객체지향의 초석
  16. 16. 3. 공통점 묶기, 조금만 알기 • 공통점 묶기를 도와 주는 편리한 객체지향 언어의 기술, 바로 상속이다. • 가상 함수를 선언함으로 컴파일러에게 컴파일 타임에 함수 형태를 미리 알려 줄 수 있다. • 함수의 호출 방식은 같지만 동작의 형태가 실제 어떤 클래스냐에 따라 달라지는 기능을 우리는 다형성(polymorphism)이라고 부른다.
  17. 17. 3. 공통점 묶기, 조금만 알기 • 많이 알게 됨으로 인해 발생하는 오작동을 막기 위해 클래스에 대한 접근을 통제할 수 있도록 객체지향 언어는 ‘캡슐화(Encapsulation)’라는 기능을 제공한다. • 변수든 함수든 가능한 한 조금만 알게 해서 클래스 사이의 결합도(Coupling)을 줄이는 것이 중요하다.
  18. 18. 3. 공통점 묶기, 조금만 알기 • 공통점 묶기와 조금만 알기는 객체지향 언어에서 상속, 다형성, 캡슐화보다 더 중요한 개념이다. • 공통점을 묶고 조금만 알기 위해 노력하다 보니 상속, 다형성, 캡슐화가 필요하게 되고 더불어 추상화(Abstraction), 일반화(Generalization)라고 세분화(Specialization)도 저절로 이루어지는 것이다.
  19. 19. 3. 공통점 묶기, 조금만 알기 • 객체지향의 결정판이라고 알려진 디자인 패턴을 어렵게 느끼는 이유 중 하나는 경험의 산물로 보지 않고 공부해서 익혀야 되는 것으로 인식하기 때문이다. • 언어는 개발자의 실수를 언어가 최대한 막아 주어 생산성을 높이는 방향으로 발전한다.
  20. 20. 4. 회사에선 사원, 군대에선 군인… • 모든 클래스는 하나의 책임만을 가진다. • 변수 하나, 함수 하나를 넣을 때 “과연 이 기능이 이 클래스에 들어가는 것이 맞을까?”에 대해 고민해야 한다. • 결합도와 복잡도는 클래스를 연결시켜 주는 인터페이스 사용을 통해 낮출 수 있다. => 확장성 높임
  21. 21. 5. 체계적인 정리법이 필요하다 • 뭔가를 기억하기보다는 썻던 물건은 언제나 찾기 쉽도록 잘 정리한다. • 조금씩 정리하는 것을 합한 시간보다 나중에 헤매게 되는 시간이 몇 배는 더 크다. • 지저분한 코드 => 새로운 요구사항 발생 => 요구사항 적용의 어려움 => 급조한 코드 => 지저분한 코드 => (악순환) 반복..
  22. 22. 5. 체계적인 정리법이 필요하다 • 지저분한 소스 탄생시키는 대표적인 경우 • 무책임한 개발자 • Case by Case로 땜빵하는 코드 • 소스의 이해 부족으로 인한 잘못된 수정 • 높은 결합도로 인한 부작용 • 문서와 다른 소스 • “역사적인 이유~”라며 시작되는 변명 • 커뮤니케이션의 부족
  23. 23. 5. 체계적인 정리법이 필요하다 • 깨끗한 코드는 가독성이 높고 구조적으로 이해하기 쉬운 코드 • 새로운 요구사항이 기존의 깨끗한 소스로도 수용이 안되는 경우는 리팩토링을 통해서 새로운 구조의 소스를 만들고 작업하면 된다.
  24. 24. 5. 체계적인 정리법이 필요하다 • 깨끗한 코드를 작성하기 위한 원칙 • 다른 개발자들에게 API를 제공한다는 마음으로 개발하라. • 남이 봐도 쉬운 코드를 만들어라 • ‘역사적'인 이유를 만들지 말아라. • 자신의 코드만 보지 말아라. • 기존의 코드와 통일성 있는 코드를 작성하라. • 커뮤니케이션 하라. • 항상 ‘1년 뒤에 이 소스를 본다면?‘ 이라고 생각하라. • 리팩토링 하라.
  25. 25. 5. 체계적인 정리법이 필요하다 • 빨리 코딩하고 안정성이나 코드의 품질과는 상관없이 ‘다 됐습니다'라고 쉽게 말하는 경향이 있다. • 개발 계획 • 항상 생각하는 것의 3배 이상을 잡을 것을 권장한다. • 개발하는 시간 외에 정리하는 시간, 테스트하는 시간을 포함시켜라. • 객체지향은 코딩으로부터 설계까지 모든 부분에 걸쳐서 적용될 수 있는 궁극의 정리 방법임을 명심하자.
  26. 26. 6. 컴퓨터는 생각보다 훨씬 빠르다 • 퍼포먼스 때문에 알아보기 힘들고 구조적이지 못한 코드를 작성해야 한다면 얻는 것보다 잃는 것이 더 많을 것이다. • 퍼포먼스에 의한 문제보다도 요구사항이나 제품의 안정성에 의한 문제가 더 중요할 수 있다. • 우리는 0.0001초와 0.0002초의 퍼포먼스 차이에 신경 쓰기보다는 구조와 요구사항에 더 신경써야 하는 세상에 살고 있다.
  27. 27. 6. 컴퓨터는 생각보다 훨씬 빠르다 • 소프트웨어 개발은 점점 구조와 알기 쉬움을 중시하는 방향으로 발전해 나간다.
  28. 28. 7. 패턴은 이름 붙여진 것일 뿐 • 내가 그의 이름을 불러 주기 전에는 그는 다만 하나의 몸짓에 지나지 않았다. • GoF가 그 패턴의 이름을 불러 주기 전에는 그 패턴은 다만 하나의 코드에 지나지 않았다. • 디자인 패턴은 정리를 위한 수단이 되어야지 개발의 목적이 되어서는 안된다.
  29. 29. 7. 패턴은 이름 붙여진 것일 뿐 • 코드가 안정적으로 동작할 때까지 계속적으로 고치는 것이다. 이것이 바로 리팩토링(refactoring)이 필요한 이유이다. • 패턴은 객체지향으로 작성한 코드를 지속적으로 리팩토링해서 얻어진 최종 결과물이다. • 처음부터 이런 요구사항의 변화를 예측하고 패턴을 활용한 코드를 올바르게 작성할 수 있다면 정말 좋겠지만 이것을 가능하게 해주는 것은 경험 말고는 아무 것도 없다.
  30. 30. 7. 패턴은 이름 붙여진 것일 뿐 • 언제나 객체지향 프로그래밍을 하길 원했고 시행착오를 통해 얻은 자신의 경험과 지식을 패턴을 통해 정리할 수 있었다. • 완벽함이란 더 이상 무엇인가를 더할 것이 없을 때 이루어지는 것이 아니라, 더 이상 무엇인가를 뺄 것이 없을 때 이루어진다. – 앙뜨완느 마리 로제 드 생떽쥐페리
  31. 31. 7. 패턴은 이름 붙여진 것일 뿐 • 객체지향의 원칙 • 클래스가 꼭 필요한 변수와 함수만을 가지고 있는가? • 클래스 사이의 연관성이 너무 높지 않은가? • 중복된 코드가 너무 많지 않은가? • 클래스가 너무 크지 않은가? • 코드를 이해하기 쉬운가? • 변하는 부분과 변하지 않는 부분은 무엇인가?
  32. 32. 7. 패턴은 이름 붙여진 것일 뿐 • 어디까지나 사람이 보는 코드이므로 보기 좋은 코드가 수정하기도 쉽다 • 클래스 사이의 관계나 객체를 배치하는 방법을 패턴으로 정리해서 재사용성을 높이는 장점이 있다.
  33. 33. 8. 빠르게 더 빠르게 • 코드를 빠르게 생산해내고 다시 빠르게 분리해서 다른 모양으로 (리팩토링) 만들 수 있는 능력은 생각보다 매우 중요 • 디자인의 성공 비율은 초보 때 낮다가 경험이 쌓이면 점점 높아짐 • 빠른 코딩 속에 디자인 • 익숙치 못한 코드나 패턴을 내 것으로 만드는 가장 빠른 길은 일단 만들어 보면서 손으로 느끼는 것
  34. 34. 8. 빠르게 더 빠르게 • 구현 포퍼먼스 높이기 • 코딩 중에는 마우스를 최대한 만지지 마라. • 자신이 사용하는 툴의 모든 단축키를 외워라. • 디버깅하기 쉽도록 코드를 작성하라. • 반복되는 작업을 편하게 해줄 도구를 찾아라. • 목적지로 가는 가장 빠른 길을 탐색하라. • 구현 중에는 흐름을 끊지 말아라.
  35. 35. 9. 이쁜 코드 만들기 • ‘나 잘났다‘라는 식으로 자신만의 코드를 만들면 오히려 코드의 통일성을 해치는 꼴이 될 것이다. • 컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 만들 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 만든다. – 리팩토링 저자 Martin Fowler
  36. 36. 9. 이쁜 코드 만들기 • 코드는 개발자의 얼굴이다. • 얼굴이 지저분한데 누가 호감을 가지겠는가. • 사람도 항상 관리하고 깔끔하게 하고 다녀야 하는 것처럼 코드도 한번 만들고 나면 다신 안보는 것이 아니라 만들어 놓고부터 시작이라는 마음가짐을 가져야 한다.
  37. 37. 10. 쉬운 그림으로 이해하기 • 우리는 굳이 UML을 모른다 하더라도 대부분의 개발자들이 칠판에 적혀진 네모와 동그라미, 그리고 이들을 연결하는 선만으로 모든 것을 설명하고 또 이해할 수 있다는 점을 알고 있다.
  38. 38. 11. 객체 생성은 객체 생성 전문가에게 • 팩토리(Factory) 패턴은 성격이 같은 객체를 생성할 때 구체적인 객체 타입에 따른 생성 부분을 캡슐화 시켜서 코드의 복잡도를 줄여준다.
  39. 39. 12. 관점의 차이가 곧 객체 생성의 차이 • 추상 팩토리(Abstract Factory) 패턴은 관련성을 가지는 객체의 집합을 생성하는 인터페이스를 제공하는 것이 목적이다. • 팩토리를 사용하는 것도 좋지만 무분별하게 많아진다면 그 자체로도 코드의 이해도는 떨어질 수 있다.
  40. 40. 13. 필요한 것은 알아서 만들자 • 팩토리 메소드(Factory Method) 패턴은 한마디로 인터페이스는 부모 클래스에서 정할 수 있지만 구체적인 객체 생성은 보다 적합한 자식 클래스에서 생성하는 것이다.
  41. 41. 14. 순서를 정리하면 시점이 보인다 • 템플릿 메서드(Template Method) 패턴
  42. 42. 15. 복잡한 조립은 전문가에게 맡기자 • 빌더(Builder) 패턴은 객체 생성 과정을 클래스화 하여 객체를 동일하게 생성하는 여러 곳의 코드 중복을 막아 준다.
  43. 43. 16. 오직 하나뿐인 그대 • 싱글턴(Singleton) 패턴은 흔히들 시스템에 하나밖에 존재하지 않는 객체의 생성과 접근을 제어하기 위해 사용된다. • 싱글턴이 가지는 가장 큰 책임은 함부로 접근되어서는 안되는 자원을 보호하는 것이다.
  44. 44. 17. 너의 쌍둥이가 필요해 • 프로토타입(Prototype) 패턴은 객체의 원형을 기반으로 자신과 똑같은 객체를 생성하는 방식이다.
  45. 45. 18. 수정할 수 없는 너무 안정적인 당신 • 어댑터(Adaptor) 패턴은 호환성을 가지지 않는 인터페이스를 맞추기 위한 목적으로 사용된다.
  46. 46. 19. 무슨 일 생기면 바로 알려줘 • 옵저버(Observer) 패턴은 정보 객체가 변경됐을 때 이 정보 객체를 참조하는 다른 객체들에게 변경사항을 알리어 변경된 정보를 즉각적으로 반영할 수 있는 방법이다. • 이 때 정보 객체를 소유하는 쪽을 서브젝트(Subject)라고 하며 정보 객체를 참조하는 객체를 옵저버(Observer)라고 부른다.
  47. 47. 20. 한가지 탐색법만 기억하라 • 이터레이터(Iterator) 패턴은 컬렉션의 내부 구현과 탐색 방법을 분리시키는 방법이다. • 탐색하는 행위를 하나의 책임으로 보고 패턴화 했다는데 의의를 가진다.
  48. 48. 21. 복합구조도 접근법은 하나 • 컴포지트(Composite) 패턴은 객체들의 트리로 대변되는 객체들 사이의 소유 구조를 동일한 인터페이스로 다룰 수 있는 방법이다. • 개별 객체와 복합 객체를 코드상에서 따로 구분하지 않고 이들의 공통점으로 만들어진 인터페이스를 구성하는 것이 이 패턴의 핵심이다.
  49. 49. 22. 난 기분에 따라 행동이 달라져 • 스테이트(State) 패턴은 객체의 서로 다른 내부 상태를 각각의 상태 객체로 클래스화 해서 분기문을 제거한다. • 결과적으로 클라이언트 코드로 노출되는 인터페이스는 동일하지만 내부 객체 상태 변화에 따라 객체는 다른 모습으로 동작한다.
  50. 50. 23. 골라 쓰는 알고리즘 • 스트래티지(Strategy) 패턴은 알고리즘을 독립적으로 확장시킬 수 있는 방법이다. • 동일한 인터페이스로 확장된 알고리즘은 클래스의 멤버 함수로 속해 있을 때보다 더 높은 확장성을 가진다.
  51. 51. 24. 공유되는 정보와 대리인 • 프록시(Proxy) 패턴은 클라이언트 코드에서 사용을 원하는 객체로의 접근을 제어하기 위한 목적으로 사용된다. • 프록시는 내부적으로 자신이 ‘제어'하는 객체와 동일한 인터페이스를 클라이언트에서 제공하여 클라이언트가 통신을 원하는 객체와 직접적으로 통신을 하는 것처럼 믿게 만든다.
  52. 52. 24. 공유되는 정보와 대리인 • 플라이웨이트(Flyweight) 패턴은 대량으로 생성되는 객체들 사이의 중복되는 정보를 공유, 메모리적인 효율성을 높이는 방법이다. • 중복된 정보를 공유하는 방법은 싱글턴, 팩토리, 자원 풀(Resource Pool) 등 여러 방법으로 구현될 수 있다.
  53. 53. 25. 행동만 따로 떼어보자 • 커맨드(Command) 패턴은 객체의 행동을 별도의 클래스에 캡슐화해서 행동 객체에 확장성을 부여한다. • 각각의 커맨드는 특정 객체에 의존하지 않도록 만들어지므로 재활용성이 매우 높다.
  54. 54. 26. 꾸미는 방법도 가지가지 • 데코레이터(Decorator) 패턴은 기본 기능을 하는 객체와 이 객체를 기반으로 동작하는 데코레이터들을 조합하여 기능을 확장하는 방법이다. • 상속보다 유연한 방법으로 동적으로 기능을 추가/삭제할 수 있고 조합해서 쓸 수 있다는 장점이 있다.
  55. 55. 27. 객체지향을 넘어서 • 공부가 오직 자신의 지적 만족과 지식 검증을 위해서 제품 코드에 반영되어서는 안된다. • 정말 가치가 있는 기술이라면 개발팀 모두가 공유하고 쉽게 사용될 수 있어야 한다는 필요충분 조건을 만족해야 한다. • 객체지향은 업무를 분배하거나 팀원들 모두가 절대 규칙으로 여길 때 진정한 가치를 가진다.
  56. 56. 27. 객체지향을 넘어서 • 객체지향 분석은 반드시 “어떻게 현실적으로 적용할 수 있을까?”라는 과정의 연속이어야 한다. • 이론은 항상 실전이 밑받침이 됐을때 진정한 빛을 발휘한다. • 신나게 달려온 99%의 제품 개발보다 릴리즈를 위한 마지막 1%의 개발이 몇 갑절은 힘들다. • 그 동안 숨겨져 있던 수많은 버그가 더 이상은 못 참고 뛰쳐 나오며, 갑작스레 수용할 수 없는 요구사항들이 쳐들어 오기 때문이다.
  57. 57. 27. 객체지향을 넘어서 • 요구사항을 어떻게 모든 개발자들에게 잘 분배하느냐 • 어떻게 문제를 분석할 것인가? • 어떻게 업무를 나눌 것인가? • 어떻게 업무를 전달하고 설명할 것인가? • 어떤 방법으로 개발자가 일하길 원하는가? • 어떻게 결과를 확인할 것인가? • 어떻게 통합할 것인가? • 객체지향은 이 모든 것의 해답이 될 수 있다.
  58. 58. 감사합니다 • 책은 꼭 사서 봅시다! • http://www.yes24.com/24/goods/6116359?scode=032&OzSrank=1

×