창발성 창발성 : 하위 계층(구성 요소)에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상. 창발적 설계로 깔끔한 코드를 구현하자 켄트 백은 다음 규칙을 따르면 설계는 단순하다고 말한다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 위 목록은 중요도 순임. 단순한 설계 규칙 1: 모든 테스트를 실행하라 테스트가 없으면 시스템이 의도한 대로 돌아가는지 검증이 불가능하다. 또한 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 높아진다. => 테스트가 쉽게 코드를 작성하게 되어, 크기가 작고 목적 하나만 수행하는 클래스가 나오게 됨. 테스트 케이스를 만들고 계속 돌리라는 규칙을 따르면, 시스템은 낮은 결합도와..

순수 자바 AOP 프레임워크 순수 자바 관점을 구현하는 여러 자바 프레임워크는 내부적으로 프록시를 사용 프로그래머가 설정 파일이나 API를 사용해 필수적인 애플리케이션 기반 구조를 구현하면, 프레임워크는 사용자 모르게 프록시나 바이트코드 라이브러리를 사용해 이를 구현함 => 애플리케이션은 사실상 프록시 라이브러리와 독립적이게 되며, 복잡한 프록시 논리 없이 단순한 구현이 가능함 => 코드가 깨끗해지고, 테스트하기 쉬워짐 AspectJ 관점 관심사를 관점으로 분리하는 가장 강력한 도구 : AspectJ 언어 AspectJ : 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장. 풍부한 도구 집합을 제공하지만, 새 도구를 사용하고 새 언어 문법과 사용법을 익혀야 한다는 단점이 있음 => 최근에 나..

의존성 주입 사용과 제작을 분리하는 강력한 메커니즘 중 하나. 제어 역전 기법을 의존성 관리에 적용 -> 한 객체가 맡은 보조 책임을 새로운 객체에 전부 떠넘기는 기법 -> 책임을 다른 메커니즘(주로 main 루틴이나 특수 컨테이너)에 전담해 넘김으로써 제어를 역전 +클래스가 의존성을 해결하지 않고 설정자 메서드나 생성자 인수를 제공해 의존성을 주입할 수 있음 확장 처음부터 올바르게 시스템을 만들 수는 없다. -> 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현하되, 계속해서 시스템을 조정하고 확장해야 함 => 반복적이고 점진적인 애자일 방식의 핵심. 테스트 주도 개발, 리팩터링은 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만듦 시스템 아키텍처는 관심사를 적절히 분리해 관리하면 점진적인 발전이 가능 ..

변경으로부터 격리 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. => 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리할 수 있음 시스템 시스템 수준과 같은 높은 추상화 수준에서 깨끗함을 유지하는 방법을 살펴보자. 시스템 제작과 시스템 사용을 분리하라 시스템을 제작하는 단계(시작 단계)와 사용하는 단계를 분리하여 코드를 설계하는 것이 좋다. 만일 생성 로직과 실행 로직이 뒤섞여 있으면(ex: 초기화 지연 기법), 실행 메서드에서 생성자 인수에 의존하게 되고, 테스트 시에도 적절한 테스트 전용 객체와 실행 경로 등을 신경써야 하는 복잡성이 생긴다. 또한 실행 로직과 뒤섞인 생성 로직에서 생성하는 객체는 모든 문맥에 적합하기 어렵다. 설정 논리는 일반 실행 논리와 분리해..

변경하기 쉬운 클래스 변경을 하고 싶을 때 이미 존재하는 클래스 코드에 손대어야만 수정할 수 있는 코드는 바람직하지 않다. => 클래스에 손대면 다른 코드를 망가뜨릴 잠정적인 위험이 존재함. 위의 경우, 클래스를 분리하면 기존 클래스를 변경하지 않고도 기능을 추가할 수 있도록 리팩토링할 수 있다. => SRP(단일 책임 원칙), OCP(확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙)의 관점에서 바람직함. 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다.

클래스 깨끗한 클래스가 깨끗한 코드를 만든다. 클래스 체계 표준 자바 관례에 따르면, 정적 공개 상수 정적 비공개 변수 비공개 인스턴스 변수 공개 함수 비공개 함수(자신을 호출하는 공개 함수 직후에 등장) 순으로 정의되며 클래스를 구성한다. => 추상화 단계가 순차적으로 내려가 신문 기사처럼 읽힌다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫다. 클래스는 작아야 한다! 클래스는 작게 만드는 것이 기본 규칙 -> 하나의 클래스는 하나의 책임만 맡아야 한다. 클래스 이름은 해당 클래스 책임을 기술해야 한다. (클래스 이름이 모호하다면 클래스 책임이 너무 많아서일 확률 높음. Processor, Manager, Super 등과 같은 단어들) 클래스 설명은 만일(if), 그리고(and), 또한..

도메인에 특화된 테스트 언어 가독성을 위해 테스트 코드에서만 사용하는 특수 API를 사용하는 것도 좋다. 이중 표준 실제 환경과 테스트 환경은 요구사항이 다르다. => 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있음(메모리나 CPU 효율과 관련 있는 경우 등) 테스트 당 assert 하나 함수마다 assert 문을 단 하나만 사용해야 한다고 주장하는 의견들이 있음 assert문이 하나인 함수는 결론이 하나라 코드를 이해하기 쉽고 빠르지만, 꼭 지켜야만 하는 법칙은 아니다. => 테스트 코드를 짜다 보면 assert를 여럿 두는 편이 가장 간결하고 이해하기 쉬울 때가 있음. 다만 assert문 개수는 최대한 줄이는 편이 좋다. 테스트 당 개념 하나 테스트 함수마다 한 개념을 ..

깨끗한 경계 경계를 잘 처리하면 소프트웨어 변경에 많은 투자와 재작업이 필요하지 않다. 경계에 위치하는 코드는 깔끔히 분리하고, 테스트 케이스를 작성하여 통제할 수 있게 한다. 단위 테스트 TDD 법칙 세 가지 TDD : 실제 코드를 짜기 전에 단위 테스트부터 짜는 것 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위 세 가지 규칙을 따르면 개발과 테스트가 30초 주기로 묶여, 테스트 코드와 실제 코드가 함께 나온다. 깨끗한 테스트 코드 유지하기 테스트 코드는 유지하기 힘들지만, 테스트 코드가 없으면 시스템 결함율이 높아진다. => 코드 변경을 ..

경계 패키지, 오픈 소스 등의 외부 코드를 우리 코드에 깔끔하게 통합시키기 위한 기교를 알아보자. 외부 코드 사용하기 만약 외부에서 가져온 인터페이스를 우리 코드 여기저기에서 각자의 인스턴스를 만들어 사용한다면, 해당 인터페이스가 변할 경우 수정할 코드가 상당히 많아진다. => 경계 인터페이스를 여기저기 넘기지 않고 이를 캡슐화한 클래스를 만들어 이용하면 이를 예방할 수 있다. 경계 살피고 익히기 외부 패키지를 사용할 땐 테스트 코드를 사용하는 게 바람직하다. 학습 테스트 : 간단한 테스트 케이스를 통해 외부 코드를 익히는 기법 학습 테스트는 패키지가 예상대로 도는지 검증하며, 우리가 패키지를 익히게 해주고, 새 버전이 나올 때마다 우리 코드와 호환되는지를 검사한다. 경계 테스트가 없으면 버전 마이그레이..

Try-Catch-Finally 문부터 작성하라 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다. -> 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하고, 이를 기반으로 나머지 논리를 추가하는 방법을 권장한다. (try 블록의 트랜잭션 본질을 유지하기 쉬움) 미확인 예외를 사용하라 자바에는 확인된 예외라는 게 있는데, 이는 OCP를 위반하므로 일반적인 애플리케이션에서는 쓰지 않는 게 좋다. 예외에 의미를 제공하라 예외를 던질 때 충분한 정보를 넘겨준다. 호출자를 고려해 예외 클래스를 정의하라 예외에 대응하는 방식이 거의 동일할 경우엔, 래퍼 클래스를 하나 정의해서 중복 코드를 줄일 수 있다. 정상 흐름을 정의하라 예외 처리를 활용..