[CLEANCODE] 함수

SOLID (객체지향 설계의 5가지 원칙)

https://medium.com/nerd-for-tech/solid-principles-in-java-5cf926e44247

• SRP 단일 책임원칙
• OCP 개방 폐쇄 원칙
• LSP 리스코프 치환 원칙
• ISP 인터페이스 분리 원칙
• DIP 의존성 역전 원칙

---

SRP 단일 책임원칙

한클래스는 하나의 책임만 가져야함

• 클래스는 하나의 기능만 가지며, 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야함
• SRP 책임이 분명해지기 때문에, 변경에 의한 연쇄작용에서 자유로워짐
• 가독성 향상과 유지보수가 용이해짐
• 실무에서는 쉽지 않지만 늘 상기해야함

---

OCP 개방 폐쇄 원칙

소프트웨어 요소는 확장에는 열려있고, 변경에는 닫혀있어야함

• 변경을 위한 비용을 줄이고, 확장을 위한 비용을 가능한 극대화
• 객체지향의 추상화와 다형성을 활용하면 개방폐쇄원칙을 지킬 수 있음
• 요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소에는 수정이 일어나지 않고, 기존 구성요소를 쉽게 확장해서 재사용 

---

LSP 리스코프 치환 원칙

서브타입은 언제나 기반 타입으로 교체할 수 있어야함

• 서브 타입은 기반 타입이 약속한 규약(접근제한자, 예외 포함)을 지켜야함
• 클래스 상속, 인터페이스 상속을 이용해 확장성을 획득
• 다형성과 확장성을 극대화하기 위해서는 인터페이스를 사용하는 것이 더 좋음
• Composition을 이용할 수도 있음

---

ISP 인터페이스 분리 원칙

자신이 사용하지 않는 인터페이스는 구현 X

• 가능한 최소한의 인터페이스만 구현
• 예를 들어 클래스를 이용하는 클라이언트가 여러개고, 이들이 클래스의 특정부분만 이용시, 여러 인터페이스로 분류하여 클라이언트가 필요한 기능만 전달
• SRP가 클래스의 단일 책임이면, ISP는 인터페이스의 단일책임

---

DIP 의존성 역전 원칙

상위모델은 하위모델에 의존하면 안되며 둘다 추상황에 의존해야함 추상화는 세부사항에 의존해서는 안되며 세부사항은 추상화에 따라 달라짐

• 하위 모델의 변경이 상위 모듈의 변경을 요구하는 위계관계를 끊어야함
• 실제 사용관계는 그대로지만, 추상화를 매개로 메시지를 주고 받으면서 관계를 느슨하게 만들어야함

---

함수 작성하기

• 함수를 작게 쪼개야함
• 함수 내 추상화 수준을 동일하게 맞춤
• 한가지만 하는 함수(SRP), 변경에 닫게 만드는 함수(OCP)
• 함수의 인수 갯수는 0 ~ 2개가 적당하며, 3개 이상인 경우 객체로 넘기거나, 가변인자로 넘김
• 사이드 이펙트가 없는 함수, 값을 반환하는 함수가 외부 상태를 변경하는 경우가 없어야함  

---

함수 리팩터링 진행 순서

1. 기능을 구현하는 서투른 함수 작성 : 길고, 복잡하고 중복도 존재함
2. 테스트 코드를 작성 : 함수 내부의 분기와 엣지값마다 빠짐없이 테스트하는 코드를 짬
3. 리팩터링 진행 : 코드를 다듬고, 함수를 쪼개고, 이름 변경, 중복 제거