[CleanCode]클래스 2

 

응집도
Cohesion
: 클래스 매서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.

응집도가 높은 클래스

• 일반적으로 메서드가 전역변수를 많이 사용할수록 클래스의 응집도가 높다.
• 모든 전역iv를 메서드마다 사용하는 클래스는 응집도가 가장 높다.
  → 하지만 이는 가능하지도 바람직 하지도 않다. 그렇지만 우리는 이를 지향한다.

변수 참조 설명글

2023.01.08 - [☕ 자바 JAVA/☕ 변수와 자료형 Variables & Data Type] - [JAVA]선언위치와 static유무로 구분한 변수종류

책에서 말하는 메서드마다 사용하는 인스턴스 변수는
non-static이자 global variable(전역 변수)를 말한다.

• '함수를 작게, 매개변수 목록을 짧게'라는 전략을 따르다 보면
  몇몇 메서드만 사용하는 전역iv가 많아진다.
  → 이는 새로운 클래스를 쪼개야 한다는 신호다.

---

응집도를 유지하면 작은 클래스 여럿이 나온다.

• 큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다.

함수를 둘로 나누고 싶은데 lv를 여럿 사용한다면

함수를 클래스로 만들고 전역변수와 여러 메서드로 사용해라.

이렇게 만들다보면 전체적인 코드 수는 길어진 것처럼 보이지만
이느 좀 더 서술적인 이름을 사용하게 되며 가독성이 높아진다.

---

변경하기 쉬운 클래스

일반적으로 한 클래스에 select/update문 등을 몰아넣는다

SQL은 구조적인 관점에서 SRP를 위반한다.
class와 sql file이 연결되어 있기 때문이다.
→ sql을 수정하면 class파일도 수정해야만 한다.
→ 만약 update문을 수정했는데 오류가 생긴다면 select문도 같이 오류가 발생한다.

이를 최대한 클린하게 관리하려면
파생 클래스를 만들면 된다.

이런 식으로 파생 클래스 여럿으로 나눈다.

이렇게 하면 update문을 추가할 때
UpdateSql extends Sql 클래스를 만들면 된다.
다른 create/insert/select 문에 오류가 영향을 미치 않게 된다.

확장에 개발적이고 수정에 폐쇄적이어야 한다는OCP Open-Closed Principle 방식이다.

---

변경으로부터 격리

• 요구사항은 변하기 마련이다.
  → 따라서 코드도 변하기 마련이다.
• 상세한 구현(클래스와 메소드가 큰 경우)에 의존하는 경우는 구현이 바뀌면 위험에 처한다.

• class Portfolio에서 TockyoStockExchange API를 사용할 경우
  클래스에서 직접 호출하는 대신
• interface StockExchange에서 API를 호출하여 시스템의 결합도를 낮춘다.
• 이러한 구조는 class PortfolioTest를 만들어 테스트하기도 좋다.
• 이렇게 결합도를 줄이면 자연스럽게 또 다른 클래스 설계원칙인 DIP Dependency Inversion Principle 의존역전원칙을 따르는 클래스가 나온다.
• 이와 같은 추상화는 실제로 주가를 얻어오는 출처나 방식을 모두 숨긴다.