Clean Code - 로버트 C.마틴 #6 객체와 자료 구조
Info
책을 읽을 때 목차를 정리하고 목차의 구성원을 하나씩 하나씩 채워 나가는 재미가 있다. 이 책 또한 마찬가지였다. 구입한 책을 펼쳐 들고 각각의 주제들을 읽고 그 내용을 정리하고자 하였는데 이미 잘 정리된 프로젝트가 존재하였다.
Clean-Code 스터디 결과물 github
이런 좋은 문서를 공개해주신 팀에 감사드린다. 1장 코드가 존재하리라
주제를 정리하면서 위의 스터디 결과물의 내용만큼 깔끔하게 정리할 수 있을 거란 생각은 들지 않았다. 이번 책은 위 링크의 내용과 함께 읽어 나갈 생각이다. 스터디 모임에 참석해 본 경험이 없지만, 글은 같은 내용일지라도 개인의 경험에 따라 다양하게 해석되고 받아들여지리라 생각한다. 그런 다양한 견해들을 접할 기회와 여건이 된다면 얼마나 좋을까?
6장 객체와 자료 구조
변수를 비공개private로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다. 충동이든 변덕이든, 변수 타입이나 구현을 맘대로 바꾸고 싶어서다. 그렇다면 어째서 수많은 프로그래머가 조회get 함수와 설정set 함수를 당연하게 공개public해 비공개 변수를 외부에 노출할까?
자료 추상화
목록 6-1 구체적인 Point 클래스
1
2
3
4
public class Point {
public double x;
public double y;
}
목록 6-2 추상적인 Point 클래스
1
2
3
4
5
6
7
8
public interface Point {
double getX();
double getY();
void setCartesian(double x, double y);
double getR();
double getTheta();
void setPolar(double r, double theta);
}
목록 6-2는 구현을 완전히 숨긴다. 그에 반해 목록 6-1은 내부 구조를 노출하고, 개별적으로 좌표값을 읽고 설정하게 강제한다. 일반적으로 변수를 private으로 많이 선언을 하는데, 각 값마다 get과 set 함수를 제공한다면 이는 결과적으로 내부 구조를 노출하는 구조가 된다.
변수 사이에 함수라는 계층을 계층을 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다! set, get 메서드로 변수를 다룬다고 클래스가 되는 것이 아니라, 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다.
자료/객체 비대칭
- 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
- 자료 구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.
두 정의는 본질적으로 상반된다. 두 개념은 사실상 정반대다. 사소한 차이로 보일지 모르지만 그 차이가 미치는 영향은 굉장히다.
목록 6-5 절차적인 도형 (Procedural Shape)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class Square {
public Point topLeft;
public double side;
}
public class Rectangle {
public Point topLeft;
public double height;
public double width;
}
public class Circle {
public Point center;
public double radius;
}
public class Geometry {
public final double PI = 3.141592653589793;
public double area(Object shape) throws NoSuchShapeException {
if (shape instanceof Square) {
Square s = (Square)shape;
return s.side * s.side;
} else if (shape instanceof Rectangle) {
Rectangle r = (Rectangle)shape;
return r.height * r.width;
} else if (shape instanceof Circle) {
Circle c = (Circle)shape;
return PI * c.radius * c.radius;
}
throw new NoSuchShapeException();
}
}
객체 지향 프로그래머가 위 코드를 본다면 코웃음을 칠지도 모르겠다. 클래스가 절차적이라 비판한다면 맞는 말이다. 하지만 그런 비웃음이 100% 옳다고 말하기는 어렵다. 만약 Geometry 클래스에 둘레 길이를 구하면 perimeter() 함수를 추가하고 싶다면? 도형 클래스는 아무 영향도 받지 않는다! 도형 클래스에 의존하는 다른 클래스도 마찬가지다! 반대로 새 도형을 추가하고 싶다면 Geometry 클래스에 속한 함수를 모두 고쳐야 한다. 그래서 두 조건은 완전히 정반대라고 할 수 있다.
이번에는 목록 6-6을 살펴보자. 객체 지향적인 도형 클래스다. 새 도형을 추가해서 기존 함수에 아무런 영향을 미치지 않는다. 반면 새 함수를 추가하고 싶다면 도형 클래스 전부를 고쳐야 한다.
목록 6-6 다형적인 도형 (Polymorphic Shape)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public class Square implements Shape {
private Point topLeft;
private double side;
public double area() {
return side * side;
}
}
public class Rectangle implements Shape {
private Point topLeft;
private double height;
private double width;
public double area() {
return height * width;
}
}
public class Circle implements Shape {
private Point center;
private double radius;
public final double PI = 3.141592653589793;
public double area() {
return PI * radius * radius;
}
}
앞서도 말했듯이, 두 방식은 사실상 반대다! 그래서 객체와 자료 구조는 근본적으로 양분된다.
(자료 구조를 사용하는) 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.
반대쪽도 참이다.
절차적인 코드는 새로운 자료 구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다. 객체 지향 코드는 새로운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐야 한다.
다시 말해, 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며, 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다!
복잡한 시스템을 짜다 보면 새로운 함수가 필요할 경우거나, 새로운 자료 타입이 필요한 경우가 생긴다. 이때 상황에 맞게 클래스 & 객체 지향 기법을 사용하거나, 절차적인 코드와 자료 구조를 적절하게 사용하는 것이 좋다.
분별 있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다. 때로는 단순한 자료 구조와 절차적인 코드가 가장 적합한 상황도 있다.
디미터 법칙
디미터 법칙은 잘 알려진 휴리스틱heuristic(경험에 기반하여 문제를 해결하거나 학습하거나 발견해 내는 방법)으로, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다.
좀 더 정확히 표현하자면, 디미터 법칙은 “클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다”고 주장한다.
- 클래스 C
- f가 생성한 객체
- f 인수로 넘어온 객체
- C 인스턴스 변수에 저장된 객체
하지만 위 객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안 된다. 다시 말해, 낯선 사람은 경계하고 친구랑만 놀라는 의미이다.
1
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
위 코드는 디미터 법칙을 어기는 듯이 보인다. getOptions() 함수가 반환하는 객체의 getScratchDir() 함수를 호출한 후 getScratchDir() 함수가 반환하는 객체의 getAbsolutePath() 함수를 호출하기 때문이다.
기차 충돌
1
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
위와 같은 코드를 기차 충돌train wreck이라 부른다.
잡종 구조
구조체 감추기
자료 전달 객체
__ 활성 레코드
결론
참고 문헌
7장 오류 처리
오류 코드보다 예외를 사용하라
Try-Catch-Finally 문부터 작성하라
미확인unchecked 예외를 사용하라
예외에 의미를 제공하라
호출자를 고려해 예외 클래스를 정의하라
정상 흐름을 정의하라
null을 반환하지 마라
null을 전달하지 마라
결론
참고문헌
8장 경계
외부 코드 사용하기
경계 살피고 익히기
log4j 익히기
학습 테스트는 공짜 이상이다
아직 존재하지 않는 코드를 사용하기
깨끗한 경계
참고 문헌
9장 단위 테스트
TDD 법칙 세 가지
깨끗한 테스트 코드 유지하기
__ 테스트는 유연성, 유지보수성, 재사용성을 제공한다
깨끗한 테스트 코드
__ 도메인에 특화된 테스트 언어 __ 이중 표준
테스트 당 assert 하나
__ 테스트 당 개념 하나
F.I.R.S.T.
결론
참고 문헌
10장 클래스
클래스 체계
__ 캡슐화
클래스는 작아야 한다!
__ 단일 책임 원칙 __ 응집도Cohesion __ 응집도를 유지하면 작은 클래스 여럿이 나온다
변경하기 쉬운 클래스
__ 변경으로부터 격리
참고 문헌
11장 시스템
도시를 세운다면?
시스템 제작과 시스템 사용을 분리하라
__ Main 분리 __ 팩토리 __ 의존성 주입
확장
__ 횡단(cross-cutting) 관심사
자바 프록시
순수 자바 AOP 프레임워크
AspectJ 관점
테스트 주도 시스템 아키텍처 구축
의사 결정을 최적화하라
명백한 가치가 있을 때 표준을 현명하게 사용하라
시스템은 도메인 특화 언어가 필요하다
결론
참고 문헌
12장 창발성(創發性)
창발적 설계로 깔끔한 코드를 구현하자
단순한 설계 규칙 1: 모든 테스트를 실행하라
단순한 설계 규칙 2~4: 리팩터링
중복을 없애라
표현하라
클래스와 메서드 수를 최소로 줄여라
결론
참고 문헌
13장 동시성
동시성이 필요한 이유?
__ 미신과 오해
난관
동시성 방어 원칙
__ 단일 책임 원칙Single Responsibility Principle, SRP __ 따름 정리corollary: 자료 범위를 제한하라 __ 따름 정리: 자료 사본을 사용하라 __ 따름 정리: 스레드는 가능한 독립적으로 구현하라
라이브러리를 이해하라
__ 스레드 환경에 안전한 컬렉션
실행 모델을 이해하라
__ 생산자-소비자Producer-Consumer __ 읽기-쓰기Readers-Writers __ 식사하는 철학자들Dining Philosophers
동기화하는 메서드 사이에 존재하는 의존성을 이해하라
동기화하는 부분을 작게 만들어라
올바른 종료 코드는 구현하기 어렵다
스레드 코드 테스트하기
__ 말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라 __ 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자 __ 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 스레드 코드를 구현하라 __ 다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라 __ 프로세서 수보다 많은 스레드를 돌려보라 __ 다른 플랫폼에서 돌려보라 __ 코드에 보조 코드instrument를 넣어 돌려라. 강제로 실패를 일으키게 해보라 __ 직접 구현하기 __ 자동화
결론
참고 문헌
14장 점진적인 개선
Args 구현
__ 어떻게 짰느냐고?
Args: 1차 초안
__ 그래서 멈췄다 __ 점진적으로 개선하다
String 인수
결론
15장 JUnit 들여다보기
JUnit 프레임워크
결론
16장 SerialDate 리팩터링
첫째, 돌려보자
둘째, 고쳐보자
결론
참고 문헌
17장 냄새와 휴리스틱
주석
__ C1: 부적절한 정보 __ C2: 쓸모 없는 주석 __ C3: 중복된 주석 __ C4: 성의 없는 주석 __ C5: 주석 처리된 코드
환경
__ E1: 여러 단계로 빌드해야 한다 __ E2: 여러 단계로 테스트해야 한다
함수
__ F1: 너무 많은 인수 __ F2: 출력 인수 __ F3: 플래그 인수 __ F4: 죽은 함수
일반
__ G1: 한 소스 파일에 여러 언어를 사용한다 __ G2: 당연한 동작을 구현하지 않는다 __ G3: 경계를 올바로 처리하지 않는다 __ G4: 안전 절차 무시 __ G5: 중복 __ G6: 추상화 수준이 올바르지 못하다 __ G7: 기초 클래스가 파생 클래스에 의존한다 __ G8: 과도한 정보 __ G9: 죽은 코드 __ G10: 수직 분리 __ G11: 일관성 부족 __ G12: 잡동사니 __ G13: 인위적 결합 __ G14: 기능 욕심 __ G15: 선택자 인수 __ G16: 모호한 의도 __ G17: 잘못 지운 책임 __ G18: 부적절한 static 함수 __ G19: 서술적 변수 __ G20: 이름과 기능이 일치하는 함수 __ G21: 알고리즘을 이해하라 __ G22: 논리적 의존성은 물리적으로 드러내라 __ G23: If/Else 혹은 Switch/Case 문보다 다형성을 사용하라 __ G24: 표준 표기법을 따르라 __ G25: 매직 숫자는 명명된 상수로 교체하라 __ G26: 정확하라 __ G27: 관례보다 구조를 사용하라 __ G28: 조건을 캡슐화하라 __ G29: 부정 조건은 피하라 __ G30: 함수는 한 가지만 해야 한다 __ G31: 숨겨진 시간적인 결합 __ G32: 일관성을 유지하라 __ G33: 경계 조건을 캡슐화하라 __ G34: 함수는 추상화 수준을 한 단계만 내려가야 한다 __ G35: 설정 정보는 최상위 단계에 둬라 __ G36: 추이적 탐색을 피하라
자바
__ J1: 긴 import 목록을 피하고 와일드카드를 사용하라 __ J2: 상수는 상속하지 않는다 __ J3: 상수 대 Enum
이름
__ N1: 서술적인 이름을 사용하라 __ N2: 적절한 추상화 수준에서 이름을 선택하라 __ N3: 가능하다면 표준 명명법을 사용하 __ N4: 명확한 이름 __ N5: 긴 범위는 긴 이름을 사용하라 __ N6: 인코딩을 피하라 __ N7: 이름으로 부수 효과를 설명하라
테스트
__ T1: 불충분한 테스트 __ T2: 커버리지 도구를 사용하라! __ T3: 사소한 테스트를 건너뛰지 마라 __ T4: 무시한 테스트는 모호함을 뜻한다 __ T5: 경계 조건을 테스트하라 __ T6: 버그 주변은 철저히 테스트하라 __ T7: 실패 패턴을 살펴라 __ T8: 테스트 커버리지 패턴을 살펴라 __ T9: 테스트는 빨라야 한다
결론
참고 문헌
부록A 동시성 II
클라이언트/서버 예제 __ 서버 __ 스레드 추가하기 __ 서버 살펴보기 __ 결론
가능한 실행 경로 __ 경로 수 __ 가능한 순열 수 계산하기 __ 심층 분석 __ 결론
라이브러리를 이해하라 __ Executor 프레임워크 __ 스레드를 차단하지 않는non blocking 방법 __ 다중 스레드 환경에서 안전하지 않은 클래스
메서드 사이에 존재하는 의존성을 조심하라 __ 실패를 용인한다 __ 클라이언트-기반 잠금 __ 서버-기반 잠금
작업 처리량 높이기 __ 작업 처리량 계산 - 단일스레드 환경 __ 작업 처리량 계산 - 다중 스레드 환경
데드락 __ 상호 배제Mutual Exclusion __ 잠금 & 대기Lock & Wait __ 선점 불가No Preemption __ 순환 대기Circular Wait __ 상호 배제 조건 깨기 __ 잠금 & 대기 조건 깨기 __ 선점 불가 조건 깨기 __ 순환 대기 조건 깨기 __ 다중 스레드 코드 테스트 __ 스레드 코드 테스트를 도와주는 도구
결론 자습서: 전체 코드 예제 __ 클라이언트/서버 - 단일스레드 버전 __ 클라이언트/서버 - 다중 스레드 버전
부록B org.jfree.date.SerialDate
부록C 휴리스틱의 교차 참조 목록
에필로그 용어 대역표 약어 목록 찾아보기
댓글남기기