💡 함수의 클린코드 원칙은 잘 받아들일 수 없었다. 내가 화면을 크게 쓰기도 하고… 함수를 추상화 레벨과 길이만으로 판단해서 코드 늘리면서까지 무리하게 쪼가리 낸다는게 이해햐기 쉽지 않았다. 반면 클래스로 범위를 넓히니 이해가 되기 시작했다. “하나의 책임”이라는 원칙 아래 논리적으로 코드를 쪼갠다면 코드를 훨씬 이해하기 쉬울 것 같다. (그에 반해 함수 원칙은 살짝 물리적인 느낌.) 함수 원칙 (물리) 와 클래스 원칙 (논리)를 적절히 섞어서 하나의 책임을 다하는 클래스 파일로 분리했을 때 OCP와 SRP를 만족하는 동시에 모두를 이해시키는 코드가 될 듯 싶다.

SRP (Single Responsibility ; 단일 책임 원칙)

클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다.

객체 지향 설계에서 중요한 개념
문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는데 있음….. 반성…..

응집도 (Cohesion)

클래스는 인스턴스 변수 수가 작아야 함
각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 함
메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 높음
응집도가 가장 높은 클래스는 가능하지도 바람직하지도 않음 → 하지만 우리는 응집도가 높은 클래스를 선호하지!
응집도가 높다는 말은, 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미
응집도를 이용한 리팩토링 ; 응집도를 유지하면 작은 클래스 여럿이 나온다
- 큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아짐
- 변수를 클래스 인스턴스 변수로 승격한다면 파라미터로 넘길 필요도 없음
- 클래스가 응집력을 잃는다면 쪼개라!!!!!!

2. 변경하기 쉬운 클래스

경험에 의하면 클래스 일부에서만 사용되는 비공개 메서드는 코드를 개선할 잠재적인 여지를 시사한다.

Sql 예제
- Sql 클래스 하위에 select, create, insert 등등…
- Sql 클래스를 generate() 강제하는 추상클래스로 만들고 selectSql, createSql 등 구현클래스 작성
- 추후 updateSql을 추가할 때 기존 클래스를 변경할 필요가 전혀 없다는 사실!
💡 내가 고민하고 있던 부분을 어쩌면 긁어주는 예시였다. 다만 원래는 static 했던 유틸성 함수를 클래스 + 인스턴스 변수로 쪼개버리면 메모리 비용과 오버헤드가 증가하지는 않을까 하는 어렴풋한 의문이 들긴 한다. 요새 머신들이 좋아서 사실 이런거에 큰 영향을 받지는 않겠지만…. 이 밸런스 게임은 하드웨어 발전으로 밸붕이 된거시 아닌즤,,,, 아무말,,,,

변경으로부터의 격리

테스트코드 예제
- 5분마다 값이 달라지는 시세 변화 API로 테스트코드를 짜기는 쉽지 않음
- 값을 계산하는 클래스에서 시세 변경 API를 날로 호출하는 것이 아니라
- 시세 변화 클래스를 하나 만들어서 분리
- 테스트 때는 해당 시세 변화 클래스를 mocking 해서 고정값으로 테스트
결합도를 최소로 줄이면 DIP (Dependency Inversion Principle ; 의존 역전 원칙) 을 만족

💡 이전 장들의 내용들이 점점 모이기 시작하며 재미있게 읽은 챕터. 클래스가 주제이니만큼 객체 지향 원칙을 기반으로 설명이 이루어지는데 납득이 된다. 잘 새겨둬야지.

글쓰기

노마드코더 이벤트노마드 코더, 강의 1:1 상담 해드려요~️⭐️📚 노마드코더 신간 안내 📚 IT 5분 잡학사전

# interview