클래스
클래스 체계
: 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다. 정적 공개 상수가 있다면 맨 처음 나온다. 다음으로 정적 비공개 변수가 나오며, 이어서 비공개 인스턴스 변수가 나온다. 공개 변수가 필요한 경우는 거의 없다. 변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사 처험 읽힌다.
- 캡슐화
: 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야한다는 법칙도 없다. 때로는 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. 우리에게 테스트는 아주 중요하다.
클래스는 작아야한다.
: 클래스를 만들 때 첫 번째 규칙은 크기다. 두 번째 규칙도 크기다. 더 작아야한다. 그렇다면 얼마나 작아야하는가 ? 함수는 물리적인 행 수로 크기를 측정했다. 하지만 클래스는 맡은 책임으로 크기를 정한다. 단일 책임 원칙에 맞춰 책임을 하나로 만들도록 노력해야한다.
-
응집도
: 클래스는 인스턴스 변수 수가 작아야 한다. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야한다. 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스 응집도가 더 높다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다. 일반적으로 이처럼 응집도가 가장 높은 클래스는 가능하지도 바람직하지도 않다. 그렇지만 우리는 응집도가 높은 클래스를 선호한다. 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미기 때문이다. -
응집도를 유지하면 작은 클래스 여럿이 나온다.
: 큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다. 예를 들어, 변수가 아주 많은 큰 함수가 하나가 있다. 큰 함수 일부를 작은 함수 하나로 빼내고 싶은데, 빼내려는 코드가 큰 함수에 정의된 변수 넷을 사용한다. 그렇다면 변수 네 개를 새 함수에 인수로 넘겨야 옳을까 ? 전혀 아니다! 만약 네 변수 클래스 인스턴스 변수로 승격한다면 새 함수는 인수가 필요없다. 그만큼 함수를 쪼개기 쉬워진다.
변경하기 쉬운 클래스
: 대다수 시스템은 지속적인 변경이 가해진다. 그리고 뭔가 변경할 때마다 시스템이 의도대로 동작하지 않을 위험이 따른다. 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.
- 변경으로부터 격리
: 요구사항은 변하기 마련이다. 따라서 코드도 변하기 마련이다. 객체 지향 프로그래밍 입문에서 우리는 구체적인 클래스와 추상 클래스가 있다고 배웠다. 구체적인 클래스는 상세한 구현을 포함하며 추상 클래스는 개념만 포함한다고도 배웠다. 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험해 빠진다. 그래서 우리는 인터페이스롸 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.
시스템
시스템 제작과 시스템 사용을 분리하라
: 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 연결하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다. 시작 단계는 모든 애플리케이션이 풀어야 할 관심사다. 이것이 이 장에서 우리가 맨 처음 살펴볼 관심사다. 관심사 분리는 우리 분야에서 가장 오래되고 가장 중요한 설계 기법 중 하나다.
확장
: 소프트웨어 시스템은 물리적인 시스템과 다르다. 관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.
자바 프록시
: 자바 프록시는 단순한 상황에 적합하다. 개별 객체나 클래스에서 메서드 호출을 감싸는 경우가 좋은 예이다.
테스트 주도 시스템 아키텍처
: 관점으로 관심사를 분리하는 방식은 그 위력이 막강하다. 애플리케이션 도메인 논리를 POJO 로 작성할 수 있다면, 즉 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해 진다.
의사 결정을 최적화 하라.
: 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다. 도시든 소프트웨어 프로젝트든, 아무 큰 시스템에서는 한 사람이 모든 결정을 내리기 어렵니다. 가장 적합한 사람에게 책임을 맡기면 가장 좋다. 우리는 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤하다.
명백한 가치가 있을 때 표준을 현명하게 사용하라
: 견축 현장을 바라보면 경탕이 나온다. 새로운 건물이 들어서는 속도는 놀랍기 그지없다. 오늘날 기술 발전으로 놀라운 설계도 가능하다.
시스템은 도메인 특화 언어가 필요하다.
: 대다수 도메인과 마찬가지로, 건축 분야 역시 필수적인 정보를 명료하고 정확하게 전달하는 어휘,관용구,패턴이 풍부하다. 소프트웨어 분야에서도 최근들어 DSL이 새롭게 조명 받기 시작하다. DSL 은 간단한 스크립트 언어나 표준 언어로 구현한 API를 가리킨다.
결론
: 시스템은 역시 깨끗해야한다. 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 도메인 논리가 흐려지면 제품 품질이 떨어진다. 버그가 숨어들기 쉬워지고 스토리를 구현하기 어려워지는 탓이다. 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다. 모든 추상화 단계에서 의도는 명확히 표현해야한다. 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야한다.
시스템 설계든 개별 모듈 설계든, 실제로 돌아가는 가장 단순한 수단을 사용해야한다는 사실을 명심하자.
