Chap.2 추상화 계층

2.3 코드의 계층

• 2.3.1 API 및 구현 세부사항

• 2.3.2 함수

• 2.3.3 클래스

• 2.3.4 인터페이스

• 2.3.5 층이 너무 얇아질 때

  ---

  [📍 오늘 TIL 3줄 요약 ]

• 계층을 너무 크게 만드는 것 보단 너무 얇게 만드는 것이 차라리 낫다.

• 경험이 풍부한 개발자도 올바른 추상화 계층을 위해 설계와 재작업을 여러 번 반복할 수 있다.

• 함수를 한 문장으로 표현하기 어렵게 구현되었다면 재사용되고 일반화 할 수 있는 하위 문제와 개념을 적절히 분리하여 추상화한다.

  [ 책에서 기억하고 싶은 내용을 써보세요 ]

  단일 클래스의 이상적인 크기

  개발자들은 대게 아래와 같은 다양한 경험 법칙을 제시한다.

• 줄 수
  ex ) 300줄을 넘지 않아야 한다. 와 같은 규칙을 사용할 수 있으나 무조건 옳다는 것은 아니며클래스가 적절한 크기인지 경고의 의미로 사용

• 순차적 응집력
  한 요소의 출력이 다른 요소에 대한 입력으로 필요할 때 발생

• 기능적 응집력
  몇 가지 요소들이 모여 하나의 일을 성취하는 데 기여할 때 발생

• 관심사의 분리
  각각 별개의 문제를 다루는 개별 구성 요소로 분리되어야 한다는 원칙

  위와 같은 경험칙은 많은 개발자 모두가 동의하는 바이며, 늘 단일 클래스 내에 얼마나 많은 다른 개념이 들어가 있는지, 어떠한 로직은 재사용이나 재구성에 적합한지에 대해 신중히 생각 해야한다.

  [ **궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요 ]**

  의존성 주입

  생성자의 매개변수로 의존성을 주입해 코드 품질을 개선할 수 있다.

  책의 예시에서는 어떠한 텍스트를 요약하는 로직을 하나의 클래스 안에서 구현한 것으로 부터 예시를 시작한다.

  class TextSummarizer{
  ...
  	String summarizeText(String text){
  		return splitIntoParagraph(text)
  		.filter(paragraph -> calculateImportance(paragraph) >=IMPORTANCE_THRESHOLD).join('\n\n')
  
  	private Double calculateImportance(String paragraph){
  		...
  		return importanceScroe
  	}
  	private List<String> splitIntoParagraph(String text){
  		...
  		return paragraph
  	}
  	private Int? detectParagraphStartOffset(){}
  	private Int? detectParagraphEndOffset(){}
  }

  해당 예시 class에서는 텍스트를 요약하는 행위를 아래와 같은 하위문제로 나누고 클래스를 구분했다.

• 텍스트를 단락으로 분할

• 텍스트 문자열의 중요도 점수 계산 → 하위 문제로 중요한 명사,동사,형용사를 찾아야 함

  <아래 예시는 자바 공부하면서 조금씩 수정 중>

  class TextSummarizer{
  	private final ParagraphFinder paragraphFinder;
  	private final TetxtImportanceScorer importanceScorer
  		TextSummarizer(ParagraphFinder paragraphFinder;
  		TetxtImportanceScorer importanceScorer,){
  	this.paragraphFider = paragraphFinder
  	this.TetxtImportanceScorer  = importanceScorer
  	}
  	String summarizeText(String text){
  	return paragraphFinder.find(text).filter...join
  }
  class ParagraphFinder{
  	...
  }
  
  }

  이렇게 나눔으로써TextSummarizer 클래스는 높은 상위 알고리즘을 구성하는 모든 개념과 단계를 빠르게 알 수 있다.

  [ 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 ]

• 고품질 코드를 작성하는 것에 집착해 가끔 불필요하게 함수를 나누는 경험을 한 적이 있는데, 너무 큰 덩어리보단 오히려 낫다는 문장을 보고 함수 쪼개기에 더 집착하게 될 것 같다😂

• 개념을 나누는 것은 결국 그때의 서비스 구현 상황에 따라 달라지기도 하는 것이기에 늘 올바른 기준은 없다는 것을 명심하고 계속해서 끝없이 고민하는 것을 즐기는 것 만이 답인 것 같다.

• 누군가 나의 API를 봤을 때, 상위 계층만으로 코드의 용도를 명확히 인지 할 수 있는 것이 코드의 추상화에 대한 궁극적 목표임을 명심하자. → 가독성

  [ **궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요 ]**

• 자바의 Class (2/11까지 정리 예정)

  자바에 대한 지식이 매우 얕은 상태여서, javascript의 클래스처럼 맥락만 이해하고 넘어간 탓에 해당 챕터의 내용을 완벽히 이해하지 못했다.
  자바에서의 class 문법을 대략적으로 공부하고, 정리해보기.

• 2.1 널값 및 의사코드 규약

• 2.2 왜 추상화 계층을 만드는가?

  ---

  [📍 오늘 TIL 3줄 요약 ]

• 코드를 잘 구성한다는 것은 간결한 추상화 계층을 만드는 것

• 널 안정성, 보이드 안정성으로 컴파일러가 반드시 널값 여부 확인을 할 수 밖에 없도록 하기

• 추상화 계층은 궁극적으로 가독성, 모듈화, 재사용성 및 일반화성, 테스트 용이성 등의 코드품질을 향상

  [ 책에서 기억하고 싶은 내용을 써보세요 ]

• 가독성
  깨끗하고 뚜렷한 추상화 계층은 개발자가 한번에 한두개 정도의 계층과 개념만 다루면 되도록 한다

• 모듈화
  하위 문제에 대한 해결책을 나누고 구현 세부사항이 외부로 노출되지 않도록 보장한다. 다른 계층에 영향을 미치지 않고 계층 내에서만 구현을 변경하도록 한다.

• 재사용성 및 일반화성
  하위 문제에 대한 해결책을 재사용 하기 쉬워진다., 또한 이것이 세분화된다면 다른 상황에서 유용하게 일반화될 가능성이 크다

• 테스트 용이성
  추상화가 깨끗하게 분할되면 각 하위문제에 대한 해결책을 완벽하게 테스트 하는 것이 쉬워진다.

  [ 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 ]

• 코드의 추상화 라는 개념이 막연히 와 닿았는데, 명확히 이해하게 되었으며 그 중요성을 더욱 깨달음

• 고품질 코드를 만들기 위한 대부분의 노력이 코드의 추상화에 일조하고 있다는 것을 깨달음

  [ **궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요 ]**