[클린코드] 6. 객체와 자료구조 - 요약 및 인사이트

인사이트 정리

요즘 타입스크립트를 공부하기 때문에 더 찔리는(..ㅎ) 챕터였다. 

여태까지는 자료구조와 객체, 절차적인 클래스와 객체지향적인 클래스를 고려하지 않고 개발했던 것 같다.

과거를 되돌아볼 때 flutter에서 provider를 사용할 때는 빈 구조의 자료 구조체를 사용했던 것 같고,

타입 스크립트에서는 객체지향적인 클래스를 사용해보려고 한 것 같다. 이유를 묻는다면,, 코드 예시에서 그렇게 사용했기 때문에.,,?

 

하지만 이번 공부를 통해, 언어마다 정답이 있거나 예시에 있다고 냅다 따라 쓰는 것이 아니라 

시스템의 확장성을 고려하여 자료구조와 객체 중 최적의 방법을 선택해야한다는 것을 알게 되었다. 

 

6장까지 읽으면서 느끼는 건, 클린 코드를 만드는 정답이 따로 있는 것이 아니라,

개발자가 협업과 시스템 확장성을 고려해서 최적의 해결책을 찾아가는 것이 클린 코드를 만드는 것이라는 생각이 든다.

 

 

요약

1. 자료 추상화 

 

1-1)

public class Point {
	public double x;
	public double y;
}

- 목록 6-1은 구현을 노출한다. 확실히 직교자표계를 사용한다. 

- 조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지는 않는다. 

 

public interface Point {
	double getX();
	double getY();
	void setCartesian(double x, double y);
}

- 목록 6-2는 클래스 메서드가 접근 정책을 강제한다. 직교 자료계를 사용하는지, 극 좌표계를 사용하는지 알 길이 없다. 

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

 

1-2)

- 목록 6-3은 자동차 연료 상태를 구체적인 숫자 값으로 알려준다 .

- 목록 6-4는 자동차 연료 상태를 백분율이라는 추상적인 개념으로 알려준다. 정보가 어디서 오는지 전혀 드러나지 않는다. 

 

 

1-3) 결론

- 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다.

- 인터페이스나 조회/ 설정 함수만으로는 추상화가 이뤄지지 않는다. 아무생각없이 조회 / 설정 함수를 추가하는 방법이 가장 나쁘다. 

 

 

2. 자료/객체 비대칭 

 

- 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. 

- 자료구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다. 

- 두 정의는 본질적으로 상반된다. 

 

2-1) 목록 6-5는 절차적인 도형 클래스다.

- 각 도형 클래스는 간단한 자료 구조다. 즉, 아무 메소드도 제공하지 않는다. 

- 도형이 동작하는 방식은 Geometry 클래스에서 구현한다. 

- Geometry 클래스에 함수를 추가하고 싶다면 도형 클래스는 아무런 영향을 받지 않는다. 

- 새 도형을 추가하고 싶다면 Geometry 클래스에 속한 함수를 모두 고쳐야 한다. 

 

2-2) 목록 6-6은 객체 지향적인 도형 클래스다. 

- 새 도형을 추가해도 기존 함수에 아무런 영향을 미치지 않는다.

- 반면 새 함수를 추가하고 싶다면 도형 클래스 전부를 고쳐야한다. 

 

2-3)

- 복잡한 시스템을 짜다보면 새로운 함수가 아니라 새로운 자료 타입이 필요한 경우가 생긴다. 이때는 클래스와 객체지향 기법이 가장 적합하다.

- 새로운 함수가 필요한 경우도 생긴다. 이 때는 절차적인 코드와 자료 구조가 좀 더 적합하다. 

- 때로는 단순한 자료 구조와 절차적인 코드가 가장 적합한 상황도 있다. 

 

 

3. 디미터 법칙 

 

디미터법칙은 잘 알려진 휴리스틱으로, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. 

객체는 자료를 숨기고 함수를 공개한다. 조회함수로 내부 구조를 공개하면 안 된다는 의미다. 

 

3-1) 기차충돌 

- 여러 객체가 한 줄로 이어진 기자처럼 보이기 때문이다. 조잡하다고 여겨지는 방식으므로 피하는 편이 좋다. 

- 디미터 법칙을 위반하는지 여부는 ctxt, Options, ScratchDir이 객체인지 아니면 자료 구조인지에 달렸다. 

- 객체라면 내부 구조를 숨겨야 하므로 확실히 디미터 법칙을 위반한다. 

 

3-2) 잡종구조 

- 새로운 함수는 물론이고 새로운 자료 구조도 추가하기 어렵다. 

- 잡종 구조는 되도록 피하는 편이 좋다. 

 

3-3) 구조체 감추기 

- ctxt가 객체라면 뭔가를 하라고 말해야지 속을 드러내라고 말하면 안된다. 추상화 수준을 뒤 섞어놓아 다소 불편하다. 

- ctxt에 임시 파일을 생성하라고 시키면 어떨까? 내부 구조를 드러내지 않으며, 모듈에서 해당 함수는 자신이 몰라야 하는 여러 객체를 탐색할 필요가 없다. 

 

 

4. 자료 전달 객체 

 

- 자료 구조체의 전형적인 형태는 공개 변수만 있고 함수가 없는 클래스다. 

- 자료 구조체를 때로는 자료 전달 객체라 한다. 

- 좀 더 일반적인 형태는 빈 구조다. 빈은 비공개 변수를 조회 / 설정 함수로 조작한다. 

 

 

5. 결론 

 

- 시스템에 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 

- 다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다. 

- 우수한 소프트웨어 개발자는 편견없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다.