패턴 그리고 객체지향적 코딩의 법칙

  • story1 ~ 10

1. 왜 C++을 사용해야 하는가?

  • 가치 있는 코드란 무엇인가?
    • 기능 요구사항을 정확하게 만족하는 코드
    • 요구사항이 변경되더라도 유연하게 대처 가능한 코드 (확장성)
    • 다른 개발자가 활용하기 편한 코드 (API가 잘 되어 있음)
  • 개발 방법의 기본
    • 개발을 체계적으로 진행할 수 있는가?
    • 개발하기 쉬운가?
    • 관리하기 쉬운가?
    • 확장하기 쉬운가?
    • 안정적인가?
  • C++은 “상속, 캡슐화, 다형성 그리고 디자인 패턴 등을 통해 여러 유용한 테크닉이 존재한다.” 다만, 이것은 C가 아닌 C++로 개발해야하는 이유가 될 수는 없다.

  • C 프로그래밍 시 생각할 점
    • 관련된 구조체와 함수를 어떻게 연관지을 것인가?
    • 구조체의 변수들은 어떻게 수정되어야 하나?
    • 의도되지 않은 수정이 이루어졌을 경우 예외처리?
    • 사용할 함수와 사용하면 안되는 함수에 대한 구분
  • 해당 내용의 결론?
    • “구조적 언어인 C를 이용하여, 객체 지향적으로 개발하는 방법”과 “객체 지향적 언어인 C++을 이용하여, C 만큼의 성능을 충족시키면서 개발하는 방법”
      • 성능이 중요한 경우 : 전자
      • HW에서 제공되는 정도의 성능 + 유지보수의 편리함 : 후자

2. 객체 지향 코드

  • 모든 이론이나 개념에 대해 그것이 왜 필요했는지 고민하고 이해하는 것이 필요

  • 객체 지향의 기본 단위 : 클래스
    • 클래스는 하나의 책임 (혹은 기능)을 가지는 것이 좋음
    • 확장성을 높힘 (== 결합도와 복잡도를 낮춤)
  • 공통점 묶기와 조금만 알기
    • 상속
    • 다형성
    • 캡슐화
  • ※ [참고] 다중 상속
    • C++에만 있고, Java에서는 다중 interface 상속 개념만 지원
    • 모든 클래스는 하나의 책임만 (기능만)을 가진다.
  • 추상 클래스와 인터페이스의 차이?
    • 추상 클래스는 클래스 전체를 다 구현하지 않고, 자식 클래스에게 구현의 일부를 위임
    • 인터페이스 : 기능 구현을 하지 않음이 원칙
      • C++ : 컴파일러가 키워드를 구별하지 않으므로 사용 시 주의
      • Java : interface와 abstract 키워드로 분리
  • 객체지향의 원칙
    • 클래스가 꼭 필요한 변수와 함수만 가지고 있는가?
    • 클래스 사이의 연관성이 너무 높지 않은가?
    • 중복된 코드가 너무 많지 않은가?
    • 클래스가 너무 크지 않은가?
    • 코드를 이해하기 쉬운가?
    • 변하는 부분과 변하지 않는 부분은 무엇인가?

3. 코드의 종류

  • 지저분한 소스가 탄생하는 배경
    • 무책임한 개발자
    • Case By Case로 땜빵하는 코드
    • 소스의 이해 부족으로 인한 잘못된 수정
    • 높은 결합도로 인한 부작용
    • 문서와 다른 소스
    • “역사적인 이유로”라며 시작되는 변명
    • 커뮤니케이션의 부족
  • 깨끗한 코드란?
    • 가독성이 높고 구조적으로 이해하기 쉬운 코드
    • 새 요구사항이 기존 깨끗한 코드로 수용이 어려운 경우, 리팩토링을 통한 새로운 구조의 소스를 만들기
  • 깨끗한 코드를 만들기 위한 원칙
    • 다른 개발자들에게 API를 제공한다는 마음
    • 남이 봐도 쉬운 코드를 만든다
    • “역사적”인 이유를 만들지 말아라
    • 내 코드만 보지 말기
    • 기존의 코드와 통일성 있는 코드를 작성하기
    • 커뮤니케이션 하기
    • 항상 ‘1년 뒤에 이 소스를 본다면?’이라고 생각하기
    • 리팩토링
  • 이쁜 코드 만들기
    • 함수 및 변수의 Naming 규칙
    • Prefix 붙이기
    • 탭 들여쓰기 및 공통 type 묶기
    • 클래스 헤더 구성
      • public (호출이 빈번한 public -> 생성자 순으로)
      • protected (해당 클래스의 자식 클래스가 overriding할 수 있는 함수)
      • 클래스 내부에서만 사용하는 private
      • 변수는 되도록 맨 아래쪽에 배치
    • ’{‘,’}’는 내려쓰기
    • 주석 달기
  • 이쁜 코드는 위 규칙을 통일한 코드라고 생각
    • 개개인에게 맡기기 보다는 cpplint를 이용하는게 더 깔끔
    • code style에 대해 상세하게 설명할 필요 없이 알아서 맞춰줌

4. Patterns

  • 패턴
    • GoF의 ‘Design Patterns’
    • 디자인 패턴은 정리를 위한 수단이지 개발의 목적이 아님
    • 리팩토링 : 코드가 안정적으로 동작할 때까지 지속해서 수정
    • 디자인 패턴은 지속적으로 리팩토링해서 얻어진 최종 결과물
  • Story 11 ~ 28은 패턴에 대한 설명이므로 정리 생략 (Head First Design Patterns 참고 해서 공부해보자)

  • 패턴 참고 사이트