[기술독서모임] Clean Code 6장

선·2020년 9월 5일

cleancode 기술독서모임

기술독서

목록 보기

6/12

6장 객체와 자료구조

자료 추상화💭

구현을 감추려면 추상화가 필요하다. 형식 논리에 치우쳐 조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지는 않는다.

추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다.

인터페이스나 조회/설정 함수만으로는 추상화가 이뤄지지 않는다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다.

자료/객체 비대칭📝

객체 : 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개
자료 구조 : 자료를 그대로 공개하며 별다른 함수는 제공하지 않음

두 정의는 상반되며 객체와 자료 구조는 근본적으로 양분된다.

(자료 구조를 사용하는) 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 어렵다.

절차적인 코드는 새로운 자료 구조를 추가 하기 어렵다. 그러려면 모든 함수를 고쳐야 한다. 객체 지향 코드는 새로운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐야 한다.

새로운 함수가 아니라 새로운 자료 타입이 필요할 때

클래스와 객체 지향 기법이 가장 적합

새로운 자료 타입이 아니라 새로운 함수가 필요할 때

절차적인 코드와 자료 구조가 더 적합

디미터 법칙❗

모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다
객체는 조회 함수로 내부 구조를 공개하면 안 된다

"클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다"

클래스 C
f가 생성한 객체
f 인수로 넘어온 객체
C 인스턴스 변수에 저장된 객체

하지만 위 객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안된다.

기차 충돌🔗

  final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

와 같은 코드를 기차 충돌이라고 한다.

일반적으로 조잡하다 여기지는 방식이므로 피하는 게 좋음

Options opts = ctxt.getOptions();
File scratchDir = opts.getScartchDir();
final String outputDir = scratchDir.getAbsolutePath();

로 나누는 것이 좋음

잡종 구조🔗

절반은 객체, 절반은 자료 구조인 잡종 구조가 만들어지기도 한다. 중요한 기능을 수행하는 함수도 있고, 공개 변수나 공개 조회/설정 함수도 있다.

객체와 자료 구조의 특성이 모두 있기 때문에 새로운 함수와 새로운 자료 구조를 추가하기 어렵다. 그러므로 되도록 피하는 게 좋다.

구조체 감추기🔗

객체는 뭔가를 하라고 말해야지 속을 드러내라고 말하면 안 된다. 모듈에서 함수는 자신이 몰라야 하는 여러 객체를 탐색할 필요가 없다. 그렇기에 디미터 법칙을 위반하지 않을 수 있다.

자료 전달 객체🎁

자료 구조체의 전형적인 형태

공개 변수만 있고 함수가 없는 클래스
자료 전달 객체(Data Transfer Object, DTO)라고 함
일반적인 형태로는 'bean' 구조가 있음

활성 레코드🔗

DTO의 특수한 형태
공개 변수, 비공개 변수에 조회/설정 함수가 있는 자료구조 + save, find와 같은 탐색 함수도 제공
데이터베이스 테이블이나 다른 소스에서 자료를 직접 변환한 결과

결론💡

객체는 동작을 공개하고 자료를 숨긴다. 그래서 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉽지만 기존 객체에 새로운 동작을 추가하기는 어렵다.

자료 구조는 별다른 동작 없이 자료를 노출한다. 그래서 기존 자료에 새 동작을 추가하기는 쉽지만 기존 함수에 새 자료 구조를 추가하시는 어렵다.

시스템을 구현할 때 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다.

느낀점🙊

이번 챕터에서는 객체와 자료 구조에 대해 다룬다. 객체와 자료 구조의 특성을 통해 구현하고자 하는 시스템이 어떤 방향의 유연성을 더 필요로 하느냐에 따라 더 효과적인 구현 방법을 사용하면 된다고 한다. 이 내용을 읽으면서 내가 너무 객체지향에 갇혀 있구나 하는 생각을 하게 되었다.

처음 프로그래밍을 시작할 때 C언어로 시작을 했고 지금은 돌아보니까 자바를 가장 많이 사용해 왔다. 그래서 절차적인 코드 보다는 객체지향이 더 익숙하다. 그래서 나도 모르게 절차지향 보다는 객체지향이 더 나은 방법이라는 생각이 무의식적으로 있었던 점을 돌아보게 되었다.

사실은 뭐가 더 낫고 뭐가 더 좋지 않은게 아니라 내가 어떤 시스템을 만들고 있느냐에 따라서, 어떤 점이 필요하냐에 따라서 더 적절한 방법을 고르면 되는 건데 말이다. 그래서 내가 그동안 코딩을 할 때 만들고자 하는 시스템에 어떤 것이 더 필요한 지를 생각하고 고민하지 않았다는 게 느껴졌다. 그냥 형식적인 논리에 맞춰서 코드를 짰지 않나 하는 생각이 든다. 좀 더 시스템의 구조적인 부분, 어떻게 표현 하는 게 더 좋을까 하는 부분에 대해서도 고민을 해봐야겠다!!