주제
- 클린코드 6장
6장 "객체와 자료 구조" 요약
객체와 자료 구조
# 메모
조회 함수와 설정 함수(get, set)로 변수를 다룬다고 클래스가 되지는 않는다. 그보다는 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다.
(좌표 클래스의 setX(), setY()로 뭔가 지정하는게 아닌 setCartesian(double x, double y)로 지정해야 함.
자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다.
객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 제공한다.
vs 자료 구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.
절차가 어려운 상황 : 자료 구조의 추가/변경은 쉬우나 Geometry의 모든 함수를 변경해야 함
객체가 어려운 상황 :
객체지향에서는 비지터 패턴으로 해결 가능
(자료구조를 사용하는) 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.
vs
절차적인 코드는 새로운 자료 구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다. 객체 지향 코드는 새로운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐야 한다.
디미터 법칙 : 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다
코드를 짧게하려 반환의 반환의 반환의 메소드를 사용하는 기차 충돌은 하지말자
모듈에서 해당 함수는 자신이 몰라야 하는 여러 객체를 탐색할 필요가 없다.
절반은 객체, 절반은 자료 구조인 잡종 구조가 존재함
잡종 구조는 피하자
자료 전달 객체 DTO
공개 변수만 있고 함수가 없는 클래스
활성 레코드는 DTO의 특수한 형태, 데이터베이스 테이블이나 다른 소스에서 자료를 직접 변환한 결과..
활성 레코드에 비즈니스 규칙 메서드를 추가해 이런 자료 구조를 객체로 취급하지 말자
활성 레코드는 자료 구조로 취급한다. 비즈니스 규칙을 담으면서 내부 자료를 숨기는 객체는 따로 생성해야 함
# 요약
자료는 철저하게 숨기고, 적절하게 표현하라(추상화)
객체와 자료 구조는 양분된다.
객체 지향은 이를 해소하기 위해 비지터 패턴을 사용할 수 있음
객체는 동작을 공개하고 자료를 숨긴다. 기존 동작을 변경하지 않으면서 새 객체를 추가하기는 쉬운반면, 기존 객체에 새동작을 추가하기는 어렵다.
자료구조는 별다른 동작 없이 자료를 노출한다. 그래서 기존 자료 구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다.
개발자는 이 사실을 이해하고 직면한 문제에 최적인 해결책을 선택해야 함
7장 "오류 처리" 요약
오류 처리
# 메모
오류 코드보다 예외를 사용하라
여기서 말하는 코드는 false, FAIL 따위의 그냥 코드
예외를 적절하게 던지면 오류를 처리하는 로직과 다른 로직을 분리할 수 있다.
함수를 호출한 즉시 처리해야 하는 상황은 놓칠 때가 많다
try-catch-finally를 적절히 활용
예외가 발생할 코드는 애초에 tr-catch문으로 시작하는 편이 낫다.
블록 안에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워짐
강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성해보기
unchecked 예외를 활용하라
checked exception을 던졌을 때 catch 블록이 세 단계 위에 있다면 그 사이 메서드 모두가 선언부에 해당 예외를 정의해야 한다. 즉 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다는 것...
어떤 최하위 함수를 변경해 새로운 오류를 던진다고 가정했을 때, 선언부에 throws 절을 추가해야 함. 그러면 변경한 함수를 호출하는 함수 모두가 catchg 블록에서 새로운 예외를 처리하거나 선언부에 thwrow 절을 추가해야함.
이는 depth가 깊을 수록 수정 범위가 많아짐
외부 API를 사용할 때는 감싸는 것이 최선이다. 외부 라이브러리와 프로그램 사이의 의존성이 크게 줄어든다.
null을 반환하지 말자.
null을 확인하는 코드로 가득 찰 수 있다.호출자에게 문제를 떠넘기는 것이다.
클라이언트(호출자)가 예외적인 사항을 처리하지 말고, 클래스나 객체가 예외적인 상황을 캡슐화해서 처리하라
# 요약
명확한 전후 사정을 알 수 있게 하고, 로직과 에러 처리가 뒤섞이는 것을 지양해야 한다.
8장 "경계" 요약
소프트웨어 경계
# 메모
라이브러리, 오픈 소스 등 외부 코드를 우리 코드에 깨끗하게 통합헤야 한다.
인터페이스는 최대한 적용할 수 있는 범위를 넓히려 하고, 실제 쓰는 사람은 요구사항을 더 구체화하려 한다. (간극)
Map 클래스를 사용할 때 여기저기 넘기지 말자. 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다.
외부 패키지를 사용할 때는 테스트 코드를 통해 녹여내라
어댑터 패턴으로 API 사용을 캡슐화해 API가 바뀔 때 수정할 코드를 한 곳으로 모았다.
# 요약
잘 녹여내는 것이 중요
'#개발서적' 카테고리의 다른 글
클린코드 9장 (0) | 2023.08.01 |
---|---|
클린코드 4~5장 (0) | 2023.06.06 |
클린코드 3장 (0) | 2023.06.06 |
클린코드 1장 ~ 2장 (0) | 2023.06.06 |
[스프링 부트와 AWS로 혼자 구현하는 웹 서비스] 정리 (0) | 2021.05.26 |