-
[Clean Code] 함수Dev/정리 2022. 5. 15. 11:24
SOLID (객체지향설계)
객체지향 설계의 5가지 원칙
1. SRP 단일 책임 원칙
한 클래스는 하나의 책임만 가져야 한다.
- 클래스는 하나의 기능만 가지며, 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이여야 한다.
- SRP 책임이 분명해지기 때문에, 변경에 의한 연쇄작용에서 자유로워 질 수 있다.
- 가독성 양상과 유지보수가 용이해진다.
- 실전에는 쉽지 않지만 늘 상기해야 한다.
2. OCP 개방/폐쇄 원칙
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
- 변경을 위한 비용을 줄이고, 확장을 위한 비용은 가능한 극대화 해야 한다.
- 요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소에는 수정이 일어나지 않고, 기존 구성요소를 쉽게 확장해서 재사용한다.
- 객체지향의 추상화의 다형성을 활용한다.
3. LSP 리스코프 치환 원칙
서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다.
(=> 부모 클래스로 활용이 되거나, 그 인터페이스로 활용을 할 수 있어야한다.)
- 서브 타입은 기반 타입이 약속한 규약(접근제한자, 예외 포함)을 지켜야 한다.
- 클래스 상속, 인터페이스 상속을 이용해 확장성을 획득한다.
- 다형성과 확장성을 극대화하기 위해 인터페이스를 사용하는 것이 더 좋다.
- 합성(composision)을 이용할 수도 있다.
4. ISP 인터페이스 분리 원칙
자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다.
- 가능한 최소한의 인터페이스만 구현한다.
- 만약 어떤 클래스를 이용하는 클라이언트가 여러 개고, 이들이 클래스의 특정 부분만 이용한다면, 여러 인터페이스로 분류하여 클라이언트가 필요한 기능만 전달한다.
- SRP가 클래스의 단일 책임이라면, ISP는 인터페이스의 단일 책임
5. DIP 의존성 역전 원칙
상위 모델은 하위 모델에 의존하면 안된다. 둘 다 추상화에 의존해야 한다.
추상화는 세부 사항에 의존해서는 안된다. 세부 사항은 추상화에 따라 달라진다.
(=> 클래스 사이 간 이용할 때 추상화를 이용하기)
- 하위 모델의 변경이 상위 모듈의 변경을 요구하는 위계관계를 끊는다.
- 실제 사용관계는 그대로이지만, 추상화를 매개로 메시지를 주고 받으면서 관계를 느슨하게 만든다.
간결한 함수 작성하기
- 한가지만 하기(SRP)
- 변경에 닫게 만들기(OCP - Open-Closed Principle)
- 인수의 갯수는 0~2개가 적당하다.
(3개 이상인 경우 -> 객체로 인자로 넘기기)
안전한 함수 작성하기
- 부수효과(Side Effect) 없는 함수
부수 효과? 값을 반환하는 함수가 외부 상태를 변경하는 경우
함수 리팩터링
1. 기능을 구현하는 서투른 함수를 작성한다
길고, 복잡하고, 중복도 있다
2. 테스트 코드를 작성한다
함수 내부의 분기와 엣지값마다 빠짐없이 테스트하는 코드를 짠다.
3. 리팩터링 한다
코드를 다듬고, 함수를 쪼개고, 이름을 바꾸고, 중복을 제거한다.
'Dev > 정리' 카테고리의 다른 글
[Spring Security] 스프링 시큐리티 주요 아키텍처 (0) 2023.01.20 [Clean Code] 형식 맞추기 (0) 2022.05.17 [Clean Code] 깨끗한 코드, 의미 있는 이름 (0) 2022.05.14