SRP(Single Responsibility principle)
단일 책임 원칙 - 쉽게 유지 보수하고, 이해하기 쉬운 코드와 버그 발생 시 범위를 줄인다.
1. 한 클래스는 한 기능만 책임진다.
2. 클래스가 바뀌어야 하는 이유는 오직 하나여야 한다.
코드가 변경되는 이유가 여러개라면, 여러 장소에서 코드 변경이 된다. 유지보수, 추가 개발이 어렵다.
코드를 이해하고 변경하기 어려워진다. 기능들에 대해서 개별로 분리하라.
ex) 파싱 프로그램
1. 입력 읽기
2. 주어진 형식 파싱
3. 결과처리
4. 결과 요약 리포트
파싱 하는 작업을 한 클래스 내에서 작업하는 것이 아닌 기능의 따라서 코드를 분리한다.
응집도(Cohesion)
클래스나 메서드의 책임이 서로 얼마나 강하게 연결되어 있는지를 측정.
응집도가 높은 코드를 작성.
ex) CSV 데이터를 파싱하는 작업과 관련된 두 메서드를 한그룹으로 만들었다 <- 응집도가 높다
속성에 맞는 것을 모아서 클래스로 작성 하자. 계산 작업을 하는 로직을 파싱이나, 결과 전송하는 로직과 같은 곳에 작성이 되어 있다면 직접적이 관련이 없기 때문에 응집도가 떨어진다.
클래스를 개발할 때는 흔히 다음과 같은 카테고리로 그룹화(클래스 분리)
기능 / 정보 / 유틸리티 / 논리 / 순차 / 시간
결합도(Coupling)
한 기능이 다른 클래스에 얼마나 의존하고 있는지를 가늠. 많은 클래스를 참조할 수록 기능을 변경할 때 유연성이 떨어진다. 어떤 클래스의 코드를 바꾸면 이 클래스에 의존하는 모든 클래스가 영향을 받는다.
결합도가 낮은 코드를 작성.
인터페이스를 이용하면 요구 사항이 바뀌더라도 유연성을 유지할 수 있다.
ex) csv를 파싱하는데 json 항목으로 인코딩된 거래 내역을 파싱할려면? xml으로 파싱할려면? 최초 개발시 현재 개발하는 부분이 추가적으로 개발이 필요하단걸 염두 했다면 인터페이스를 이용했을 것이고, 구현한 클래스를 만들어서 호출하는 부분은 로직 변경 없이 손쉽게 기능을 추가를 할 수 있다.
명심하고 또 명심)
KISS (Kepp It Short and Simple)
DRY (Don't repeat yourself)
갓 클래스와 중복 코드를 피하자.
OCP (Open / Closed Principle)
코드를 직접 변경하지 않고 해당 메서드나 동작을 바꿀 수 있다. 코드 변경 없이(closed), 확장성은 개방(open)된다.
어떻게? 인터페이스를 사용한다.
반복 로직과 비즈니스 로직이 결합되어 있다면 인터페이스를 사용해서 결합을 제거하자.
실제로 코드를 직접 변경하지 않는 다는 이야기는 호출하는 부분에서는 코드르 변경하지 않는다는 이야기다. 확장을 하고자 하는 코드는 당연히 확장을 하기 위해서는 코드 작성이 필요하다.
더 나은 코드와 샘플 코드를 많이 보고 생각하고 곱씹고 익히자.
명심하고 또 명심하자. 유지보수와 기능 개발을 하게 쉽게 해야돼.
더 재밌게 코드를 작성할 수 있어!
소스코드)
책 참고)
실전 자바 소프트웨어 개발