Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

8.426 visualizaciones

Publicado el

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

Publicado en: Software
  • Sé el primero en comentar

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

  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

×