[좋은코드, 나쁜코드] 2장 추상화 계층 DEV / PROGRAMING
2023-05-22 posted by sang12
코드 작성의 목적은 문제 해결이다.
"결국 코드 작성의 목적은 문제 해결이다. 어떻게 하면 효율적으로 문제를 해결할 수 있는지?
추상화 계층을 통해 설명하려고 하는거 같다. 결국 가독성과 재사용성을 위한게 아닐까"
추상화 계층 및 코드 품질의 핵심 요소
가독성
모듈화
재사용성 및 일반화성
테스트 용이성
"당연한 말... 추상화 하면 좋은점"
API 및 구현 세부사항
어떤 코드를 호출하는 쪽에서 그 코드에 대해 알고 있는 사항을 공개 API라고 생각할 수 있다.
API로 공개되지 않은 내용은 구현 세부사항이다
"결국 공개할 API 는 인터페이스화 시켜 공개하고 구현체에 세부사항을 위임한다.
당연하게도 테스트하기 쉬워지며, 추상화의 이점을 얻어 코드는 이해하기 쉬워진다. 이것또한 당연한 말..."
모든 것을 위한 인터페이스?
장점
퍼블릭 API를 매우 명확하게 보여준다
테스트를 쉽게할 수 있다
쉽게 갈아낄 수 있다. -> 오늘 확신한 것과 한달 후에 확신한 것이 다를 수 있다.
같은 클래스로 두 가지 하위 문제를 해결할 수 있다.
단점
더 많은 작업이 필요하다 (보일러코드)
코드가 복잡해질 수 있다
실제 구현을 파악할 때 구현체를 구현하는 구체클래스를 찾아야 한다.
층이 너무 얇아질 때
= 너무 많은 클래스로 나눴거나, 모든 것을 인터페이스로 만들엇다면..
보일러 코드가 늘어난다
로직을 이해하려면 많은 파일이나 클래스를 따라가야 한다.
인터페이스 뒤에 숨은 구현체들을 파악하기 힘들다 (로직을 이해하거나 디버깅하는 것이 어렵다)
코드를 서로 다른 계층으로 분할해서 얻는 장점과 비교하면 이러한 비용은 상당히 낮은 것이지만 분할을 위한 분할은 의미가 없다는 것을 명심해야 한다.
비용이 이익보다 더 큰 시점이 올 수 있으므로 상식에 맞게 적용하는 것이 좋다.
너무 비대한 계층 때문에 발생하는 문제는 너무 얇은 계층 때문에 발생하는 문제보다 더 심각하다.
확실하지 않은 경우 남용의 위험에도 불구하고 계층을 얇게 만드는 것이 좋다.
"확실하지 않을때면 무조건 계층을 얇게 만들는 것이 좋다? 동의되지 않는다. 결국 그때그때 마다 다르니 잘써라는 말로 들리는건... 기분 탓"
클래스
'클래스는 응집력이 있어야 하고 한가지 일에만 관심을 가져야 한다'와 같은 말에 동의하지 않는 개발자들은 만나보지 못했다.
하지만 이 조언을 알고 있음에도 불구하고 많은 개발자가 여전히 너무 큰 클래스를 작성한다.
느낀점
복잡한 하나의 코드 예시를 제시하고 이를 함수 및 클래스로 분리 하며 최종적으로 인터페이스를 통해 추상화 하며 장점들을 설명한다. 2장에서도 당연한 말들로 시작해 당연한 말로 끝이난다.
하지만 해당 내용을 알고 있음에도 개발자는 여전히 너무 큰 클래스를 작성한다… 이게 2장에서 제일 중요한 말이 아니 였을까?