[TIL] 클린코드(Clean Code) - 6장. 객체와 자료 구조

📆 TIL (Today I Learned) 날짜

2022.03.01

📚 오늘 읽은 범위

6장. 객체와 자료 구조

📝 책에서 기억하고 싶은 내용

• 자료 추상화 : 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다! 그저 (형식 논리에 치우쳐) 조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지는 않는다. 그보다는 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. (p.119)
• 자료/객체 비대칭 : 복잡한 시스템을 짜다 보면 새로운 함수가 아니라 새로운 자료 타입이 필요한 경우가 생긴다. 이때는 클래스와 객체 지향 기법이 가장 적합하다. 반면, 새로운 자료 타입이 아니라 새로운 함수가 필요한 경우도 생긴다. 이때는 절차적인 코드와 자료 구조가 좀 더 적합하다. 분별 있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다. 때로는 단순한 자료 구조와 절차적인 코드가 가장 적합한 상황도 있다. (p.122)
• 디미터 법칙은 잘 알려진 휴리스틱(heuristic)으로, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. 객체는 자료를 숨기고 함수를 공개한다. 즉, 객체는 조회 함수로 내부 구조를 공개하면 안 된다는 의미다. 그러면 내부 구조를 (숨기지 않고) 노출하는 셈이니까. (p.123)
• 잡종 구조 : 절반은 객체, 절반은 자료구조인 형태. 중요한 기능을 수행하는 함수도 있고, 공개 변수나 공개 조회/설정 함수도 있다. 공개 조회/설정 함수는 비공개 변수를 그대로 노출한다. 이런 잡종 구조는 새로운 함수는 물론이고 새로운 자료 구조도 추가하기 어렵다. 양쪽 세상에서 단점만 모아놓은 구조다. 그러므로 잡종 구조는 되도록 피하는 편이 좋다. 프로그래머가 함수나 타입을 보호할지 공개할지 확신하지 못해 (더 나쁘게는 무지해) 어중간하게 내놓은 설계에 불과하다. (p.124)
• 구조체 감추기 : 객체라면 뭔가를 하라고 말해야지 속을 드러내라고 말하면 안 된다. (p.125)
• 자료 전달 객체 : 자료 구조체의 전형적인 형태는 공개 변수만 있고 함수가 없는 클래스다. 이런 자료 구조체를 때로는 자료 전달 객체(Data Transfer Object, DTO)라 한다. DTO는 굉장히 유용한 구조체다. 특히 데이터베이스와 통신하거나 소켓에서 받은 메시지의 구문을 분석할 때 유용하다. 흔히 DTO는 데이터베이스에 저장된 가공되지 않은 정보를 애플리케이션 코드에서 사용할 객체로 변환하는 일련의 단계에서 가장 처음으로 사용하는 구조체다. (p.126)
• 활성 레코드 : 활성 레코드는 데이터베이스 테이블이나 다른 소스에서 자료를 직접 변환한 결과다. 불행히도 활성 레코드에 비즈니스 규칙 메서드를 추가해 이런 자료 구조를 객체로 취급하는 개발자가 흔하다. 하지만 이는 바람직하지 않다. 그러면 자료 구조도 아니고 객체도 아닌 잡종 구조가 나오기 때문이다. 해결책은 당연하다. 활성 레코드는 자료 구조로 취급한다. 비즈니스 규칙을 담으면서 내부 자료를 숨기는 객체는 따로 생성한다. (여기서 내부 자료는 활성 레코드의 인스턴스일 가능성이 높다.) (p.127)
• 객체는 동작을 공개하고 자료를 숨긴다. 그래서 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다. 자료 구조는 별다른 동작 없이 자료를 노출한다. 그래서 기존 자료 구조에 새동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다. (p.127)
• (어떤) 시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다. 우수한 소프트웨어 개발자는 편견 없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다. (p.128)

😀 오늘 읽은 소감 및 떠오르는 생각

• 평소 생각해본적도 없었고 그래서 객체와 자료 구조체의 큰 차이점을 몰랐는데 객체와 자료 구조체에 대해 잘 알게 되는 시간이었다.
• 사실 VO(Value Object)나 DTO(Data Transfer Object)를 보통 실무에서 그냥 쓰니까 생각 없이 그냥 썼었는데 이런 의미로 쓰는 것이었구나를 알게 됐다. 참 생각 없이 제대로 알지도 못하고 살았구나 하는 생각이 들었다.
• 객체도 아니고 자료 구조도 아닌 잡종 구조를 만들어내지 않도록 유의해야겠다. 지금도 충분히 이런 잡종 구조를 많이 접하고 있는 것 같다.
• 많은 사람들이 객체 지향이 대세이고 객체 지향이 최고라고 외친다고 해서 무조건적으로 객체 지향 한가지 기법만 추구할 것이 아니라 상황에 따라 자료 구조와 절차적인 코드 작성 기법을 사용하는 등 상황에 맞는 구현 방식을 선택하는 것이 더 효율적이고 바람직한 행동이라는 생각이 들었다.
• 요즘 디자인 패턴을 잘 모르는 것 같아 공부를 좀 하고 있었는데 디자인 패턴을 더 열심히 공부 해야겠다는 생각이 들었다. 디자인 패턴을 잘 알아야 객체도 잘 쓸 수 있고 자료 구조체에 대해서도 잘 알 수 있을 것 같다.

🤔 궁금한 내용 및 잘 이해되지 않는 내용

• 디미터 법칙 : 책 내용상 어떤 것을 말하고 있는지는 알겠으나 더 자세히는 잘 모르겠다. 이미 알고 있는 것을 얘기하고 있는 것 같기도 해서 지금보다 더 많이 궁금해지면 그때 자세히 찾아보도록 해야겠다. 디자인 패턴 공부를 먼저 하고나면 디미터 법칙에 대해 더 잘 이해할 수 있을 것 같다는 생각이 자꾸 드는 이유는 무엇일까?