Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- 10830번
- java
- BOJ
- java의 정석
- 가장 긴 증가하는 부분 수열2
- DxTrace
- 17장
- 11758번
- programmers
- 11286번
- 2156번
- 코딩 테스트
- 자바의 정석
- 백준
- Adapater Pattern
- springboot
- 프로그래머스
- Spring
- 1300번
- SerialDate 리펙터링
- Dxerr.h
- Design Patterns
- 2206번
- 9장
- Design Pattern
- 2166번
- 클린코드
- 코딩테스트
- 냄새와 휴리스틱
- 1043번
Archives
- Today
- Total
Don't give up!
[클린코드] 8장 경계 본문
이 글은 로버트 마틴의 '클린 코드'를 읽고 TIL(Today I Learned)로써 정리한 내용을 기록하는 글입니다.
자세한 내용은 책을 통해 확인하실 수 있습니다.
알라딘: 클린 코드 Clean Code (aladin.co.kr)
경계
- 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다.
- 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다.
외부 코드 사용하기
- 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려 애쓴다.
- 사용자는 자신의 요구에 집중하는 인터페이스를 바란다.
- 이러한 긴장으로 인해 시스템 경계에서 문제가 생길 소지가 많다.
//나쁜 코드 - 형변환이 매번 있으며 sensors의 권한이 사용하는 모두에게 존재함.
Map sensors = new HashMap();
Sensor s = (Sensor)sensors.get(sensorId);
//Generics 사용하여 개선 - 코드 가독성은 높아지지만 권한 문제는 해결x, Map 인터페이스가 변경되면 수정해야할 부분이 생긴다.
Map<String, Sensor> sensors = new HashMap<Sensor>();
Sensor s = sensors.get(sensorId);
//Map을 캡슐화하는 Sensors 클래스 정의하여 개선 - 권한 문제도 해결할 수 있음.
public class Sensors {
private Map sensors = new HashMap();
public Sensor getById(String id) {
return (Sensor)sensors.get(id);
}
}
- 외부 API를 캡슐화하면 나머지 프로그램이 설계 규칙과 비즈니스 규칙을 따르도록 강제할 수 있다.
- 외부 API를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의해야 한다.
경계 살피고 익히기
- 외부 패키지 테스트가 우리 책임은 아니지만 우리 자신을 위해 우리가 사용할 코드를 테스트하는 편이 바람직하다.
- 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익혀라.
학습 테스트
- 학습 테스트는 프로그램에서 사용하려는 방식대로 외부 API를 호출한다.
- 학습 테스트는 다음의 순서대로 진행한다.
- 외부 패키지의 문서를 자세히 읽기 전에 첫 번째 테스트 케이스를 작성한다.
- 오류를 해결하기 위해 문서를 읽고 테스트를 해결한다.
- 얻은 지식을 토대로 간단한 단위 테스트 케이스들이 담긴 테스트 클래스로 표현한다.
- 테스트 클래스로부터 얻은 지식을 바탕으로 독자적인 클래스로 외부 API를 캡슐화한다.
- 학습 테스트는 필요한 지식만 확보하는 손쉬운 방법이다.
- 패키지 새 버전이 나오면 학습 테스트를 돌려 차이가 있는지 확인할 수 있다.
- 학습 테스트만 돌려도 우리 코드와 호환되는지 확인할 수 있다.
- 이러한 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다.
아직 존재하지 않는 코드를 사용하기
- 때로는 우리 지식이 경계를 너머 미치지 못하는 코드 영역도 있다.
- 코드를 작성하는 우리는 경계가 어디쯤인지 대략적으로 알 수 있다. (필요한 경계 인터페이스를 알 수 있음.)
- 자체적으로 우리가 바라는 인터페이스를 정의하라.
어댑터 패턴 (ADAPTER PATTERN)
- 어댑터 패턴은 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴이다.
- API 사용을 캡슐화해 API가 바뀔 때 수정할 코드를 한곳으로 모으면 구현을 나중으로 미룰 수 있다.
- 우리가 바라는 인터페이스를 구현하면 우리가 인터페이스를 전적으로 통제한다는 장점이 생긴다.
- 코드 가독성도 높아지고 코드 의도도 분명해진다.
- 테스트도 아주 편하다. API 인터페이스가 나온 다음 테스트 케이스를 생성해 API를 올바로 사용하는지 테스트할 수 있다.
정리
- 외부 API는 우리가 통제할 수 없는 영역이며 제공자와 사용자의 목적이 달라 권한 등의 문제가 발생할 수 있다.
- 경계에 위치하는 코드는 깔끔히 분리하라.
- 기대치는 정의하는 테스트 케이스를 작성하라.
- 통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하라.
- 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하라. (새로운 클래스로 경계를 감싸거나, 어댑터 패턴을 사용해 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하라.)
'개발서적 > 클린 코드' 카테고리의 다른 글
[클린코드] 9장 단위테스트 (0) | 2021.07.27 |
---|---|
[클린 코드] 7장 오류 처리 (0) | 2021.07.26 |
[클린 코드] 6장 객체와 자료구조 (0) | 2021.07.25 |