의존 의 자기 유사성 
 Posts 의존 의 자기 유사 성 # 
 2017 - 09 - 03 02 : 05 : 25 ( rev . 10 ) 
 2013 - 08 - 26 04 : 11 : 42 ( published ) 
 의존 성 이란 
 다양 한 종류 의 의존 성 
 객체 와 패키지 
 지역 변수 
 의존 성 낮추 기 
 의존 성 과 중복 
 의존 성 이란 # 
 시스템 설계 에서 아주 중요 한 개념 중 하나 로 의존 ( dependency ) 이 라는 것 이 있 다 . 다양 한 정의 가 있 지만 이 글 에서 는 간단 하 게 
 A 는 B 가 있 어야 만 올바르 게 작동 할 수 있 을 때 A 가 B 에 의존 한다 ( A depends on B ) 
 의존 성 이 낮 은지 를 평가 할 수 있 는 휴리스틱 중 하나 는 변경 비용 ( change cost ) 이 얼마나 낮 은가 , 혹은 변경 에 따른 여파 ( ripple effect ) 가 얼마나 좁 은가 를 보 는 것 이 다 . 쉽 게 말 해서 코드 를 수정 할 때 노력 이 적 게 들 면 의존 성 이 낮 다고 짐작 할 수 있 다 . 
 다양 한 종류 의 의존 성 # 
 재미있 는 점 은 의존 성 에 도 다양 한 스케일 ( scale ) 이 있 고 , 각 스케일 에서 유사 한 형태 로 반복 되 며 나타난다는 점 이 다 . 이 를 자기 유사 성 ( Self - similarity ) 이 라고 한다 . Koch curve 같 은 Fractal 을 떠올리 면 좋 겠 다 : 
 객체 와 패키지 # 
 요즘 은 모두 들 " 객체 , 객체 " 하 는 시대 라 , 의존 성 에 이야기 를 할 때 에 도 보통 객체 간 의 의존 혹은 좀 더 크 게 봐서 패키지 간 의 의존 을 많이 얘기 한다 . 의존 성 주입 ( dependency injection ) , 의존 성 역전 ( Dependency inversion principle 혹은 inversion of control ) , 안전 한 패키지 에 의존 하 기 ( Stable dependencies principle ) 등등 . 
 이 부분 은 뻔한 얘기 니까 넘어가 자 . 
 함수 # 
 약간 스케일 을 낮추 면 함수 간 의 의존 성 에 대한 이야기 를 해 볼 수 있 겠 다 . 함수 사이 에 의존 성 을 만드 는 주범 은 전역 변수 ( global variable ) 혹은 전역 상태 ( global state ) 이 다 . 함수 외부 에 어떠 한 상태 ( variable , state ) 가 있 고 , 그 상태 는 다른 어떠 한 함수 에서 나 접근 이 가능 하 다 ( global ) . 결과 적 으로 시간 이 흐름 에 따라 , 혹은 초기 설계 에서부터 이 전역 변수 를 중심 으로 여러 함수 들 이 엮이 게 된다 . 의존성 이 라는 단어 로 다시 표현 하 면 , 여러 함수 들 이 전역 변수 를 매개 로 서로 영향 을 주 고 받 는 상태 가 되 면서 서로 가 서로 에 대해 의존 성 을 갖 게 된다 . 
 메 서드 # 
 함수 와 전역 변수 사이 의 의존 관계 는 하나 의 인 스턴스 내부 에서 도 작 은 스케일 로 또 출현 한다 . 여러 인 스턴스 메서 드 들 이 인 스턴스 변수 를 매개 로 서로 영향 을 주 고 받 는 상황 은 그 스케일 만 다를 뿐 의존 성 이 존재 하 는 것 이 다 . 
 서두 에서 변경 비용 을 기준 으로 의존 성 을 평가 할 수 있 다고 했 는데 , 이 경우 엔 메 서드 이동 하 기 ( move method ) 리팩토링 을 할 때 의 비용 을 생각 해 볼 수 있 겠 다 . 메서 드가 인 스턴스 변수 에 의존 하 고 있 지 않 으면 그대로 메 서 드 를 빼 서 다른 클래스 로 옮기 면 된다 . 변경 비용 이 낮 다 . 하지만 인 스턴스 변수 에 의존 하 고 있 으면 해당 인 스턴스 변수 및 그 인 스턴스 변수 에 의존 하 고 있 는 다른 메서 드 들 을 면밀히 살펴야 대상 메 서 드 를 옮길 수 있 다 . 
 매개변수 # 
 함수 나 메 서드 내부 로 들어가 도 봐도 마찬가지 입니다 . 아래 의사 코드 를 보 자 : 
 bar 메 서드 의 다섯 줄 중 세 줄 은 매개변수 를 사용 하 고 있 다 . 매개변수 와 해당 문장 들 사이 에 의존 성 이 있 는 것 이 다 . 그 결과 변경 비용 이 높 아 진다 . 메 서드 추출 하 기 ( extract method ) 리팩토링 을 할 때 의 비용 을 생각 해 보 자 . 매개 변수 에 의존 하 고 있 지 않 은 두 줄 을 뽑아낼 때 에 는 아무 생각 없이 두 줄 을 잘라서 새 메 서드 본문 에 넣 고 , 원래 위치 에 새 메 서드 호출 코드 를 집어넣 으면 된다 . 하지만 매개 변수 에 의존 하 고 있 는 줄 은 그렇 지 않 다 . 
 지역 변수 # 
 지역 변수 도 마찬가지 다 . 지역 변수 를 중심 으로 하 여 해당 지역 변수 를 사용 하 고 있 는 다른 문장 들 사이 에 의존 성 이 생긴다 . 그러 한 문장 은 쉽 게 독립 적 으로 추출 ( extract method ) 될 수 없 다 . 
 의존 성 낮추 기 # 
 하나 의 원칙 으로 다양 한 스케일 의 문제 를 설명 할 수 있 으면 그건 좋 은 거 죠 . 왜냐하면 한 놈 만 잘 신경 써서 잡 아도 많 은 문제 를 해결 할 수 있 으니까 . 
 객체 지향 프로그래밍 을 하 건 구조 적 프로그래밍 을 하 건 함수 형 프로그래밍 을 하 건 상관없이 한 놈 만 패 야 한다면 주저 말 고 " 의존 성 " 을 잡 아 보 길 권한다 . 그러 고 보 면 온갖 좋 은 설계 원칙 이 라는 것 들 이 패러다임 과 무관 하 게 일관 적 으로 추구 하 는 것 이 바로 의존 성 을 낮추 는 것 이 다 . 
 기왕에 리팩토링 얘기 를 꺼냈으니 , 리팩토링 책 에서 말 하 는 냄새 ( code smells ) 몇 가지 를 의존 성 이 라는 측면 에서 다시 검토 해 보 자 : 
 긴 파라 메터 목록 - 파라 메터 가 많 으면 메 서드 내부 의 문장 간 의존 성 이 높 아 진다 . 
 거대 한 클래스 - 클래스 가 거대 하 면 인 스턴스 변수 도 많 아 진다 . 반대 로 , ( 유틸리티 클 래스 가 아닌 이상 ) 인 스턴스 변수 가 적 으면서 클래스 가 거대 하 기 는 쉽 지 않 다 . 
 긴 메 서드 - 메 서드 가 길 면 지역 변수 도 많 아 진다 . 반대 로 , 지역 변수 가 적 으면서 메 서드 가 길 기 도 쉽 지 않 다 . 
 임시 필드 - 이름 에서 그대로 드러나 므로 생략 . 
 의존 성 을 최대한 낮추 는 것 은 좋 은 설계 를 얻 기 위한 훌륭 한 원칙 중 하나 이 다 . 
 의존 성 과 중복 # 
 그럼 의존 성 을 어떻게 낮추 나 ? 위 에서 설명 한 의존 성 의 다양 한 모습 들 을 살펴서 사살 하 는 방법 도 있 겠 지만 , 다른 방법 도 있 다 . Test Driven Development : By Example 에서 켄트 백 은 이런 말 을 한다 : 
 If dependency is the problem , duplication is the symptom . . .. Unlike most problems in life , where eliminating the symptoms only makes the problem pop up elsewhere in worse form , eliminating duplication in programs eliminates dependency . 
 의존 성 이 문제 라면 중복 은 드러나 는 징후 다 . ... 문제 자체 는 남겨둔 채 로 징후 만 을 제거 하 면 다른 어딘가 에서 최악 의 형태 로 문제 가 드러나 곤 하 는 현실 세계 의 일반 적 인 양상 과 는 달리 , 프로그램 에서 는 중복 만 제거 해 주 면 의존 성 도 제거 된다 . 
 즉 , 문제 ( 의존성 ) 를 직접 공략 하 는 법 말 고 문제 의 징후 ( 중복 ) 을 공략 하 는 것 도 방법 이 라는 것 이 다 . TDD 의 두 가지 설계 원칙 - 중복 제거 , 의도 드러내 기 - 은 여기 에서 기인 하 는 것 이 다 . 
 여담 # 
 요 몇 년 사이 기획 일 을 주로 하 다 보 니 기획 자 의 관점 에서 도 가끔 생각 을 해 보 는데 , 의존 성 의 자기 유사 성 은 클래스 와 패키지 범위 를 넘 어서 기획 단계 까지 도 이어질 수 있 다고 생각 한다 . 확장 성 있 는 서비스 , 변화 에 대처 할 수 있 는 서비스 를 기획 하 려면 이 개념 을 잘 활용 할 필요 가 있 겠 다고 생각 한다 . 
 시스템 분석 / 설계 능력 은 기획 자 가 지녀야 할 지식 의 본체 ( body of knowledge ) 를 이루 는 커다란 한 축이 라고 생각 한다 . 또 다른 중요 한 축 으로 는 시스템 이 아닌 " 인간 에 대한 이해 " 같 은 것 이 있 을 수 있 겠 다 . 이 사이 에 겹치 는 부분 도 있 을 것 이 고 . 
 0 . 528 디자인 이 란 서로 를 이롭 게 연결 하 는 것 
 0 . 085 사내 시스템 의 UX 
 0 . 058 기획 자 의 욕심 에 대한 생각 
 0 . 042 사용자 경험 이란 
 0 . 025 Object - oriented programming 
 0 . 024 Software engineering 
 0 . 023 강규영 
 0 . 023 김창준 
 0 . 022 November 18 
 0 . 021 2002 
 newer 디자인 이 란 서로 를 이롭 게 연결 하 는 것 
 older Naturally Dangerous 독후감 
 dot / s