아이템 19

knowledge를 반복하여 사용하지 말라

프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다.(....)

knowledge

의도적인 정보를 의미한다. 예를 들어 상속을 할 때 특정 메서드를 오버라이드하지 않게 강제해 해당 메서드가 슈퍼클래스와 동일하게 동작하게 하는 경우가 있다.

중요한 knowledge는 크게 두 가지가 존재한다.

1. 비즈니스 로직: 프로그램이 어떠한 식으로 동작하는지와 프로그램이 어떻게 보이는지 (시간이 지나면서 변함)
2. 공통 알고리즘: 원하는 동작을 하기 위한 알고리즘 (공통으로, 크게 변하지 않음)

모든 것은 변화한다

knowledge 반복은 프로젝트의 확장성을 막고, 쉽게 깨지게 된다. 따라서 함께 변경될 가능성이 높은지, 따로 변경될 가능성이 높은지 판단하여 추출을 할 필요가 있다.

단일 책임 원칙

• 단일 책임 원칙: 클래스를 변경하는 이유는 단 한 가지여야 한다.

장학금 관련 부서는 qualifiesForScholarship 프로퍼티를, 인증 관련 부서는 isPassing 프로퍼티를 추가하였는데, 이들은 같은 함수에 의존하고 있다.

class Student {
	fun isPassing(): Boolean =
			calculatePointsFromPassedCourses() > 15 

	fun qualifiesForScholarship(): Boolean =
			calculatePointsFromPassedCourses() > 30

	private fun calculatePointsFromPassedCourses(): Int {
			
	}
}

하지만 계산 방식에 차이가 발생한다면 의존하고 있던 다른 함수도 영향을 받을 수 있다. 따라서 책임에 따라 클래스를 구분할 필요가 있다.

// accreditations 모듈
fun Student.qualifiesForScholarship(): Boolean {
	...
}

// scholarship 모듈
fun Student.calculatePointsFromPassedCourses(): Boolean {
	...
}

위와 같이 확장함수를 작성해서 각각의 부서가 관리하는 서로 다른 모듈 파일에 배치하도록 할 수 있다.

정리

서로 다른 곳(위의 예에서는 다른 부서)에서 사용하는 knowledge는 독립적으로 변경할 가능성이 크므로 비슷한 처리를 하더라도 다른 knowledge로 취급하는 것이 좋다.

비슷해 보이는 코드는 모두 추출하려는 경향이 있는데, 극단적인 것은 좋지 않다. 단일 책임 원칙을 잘 지키도록 하자.