Intro 동시성과 깔끔한 코드는 양립하기 어렵다. 스레드를 하나만 실행하는 코드는 짜기가 쉽다. 간략히 알아보자. 동시성이 필요한 이유? 동시성은 결합(coupling) 을 없애는 전략이다. 즉, 무엇(what) 과 언제(when) 를 분리하는 전략이다. 그래서 디버깅을 할 때 **정지점(breakpoint)**을 정한 후 어느 정지점에 걸렸는지 살펴본다. 서블릿은 EJB컨테이너 안에서 돌아가는데, 이들은 동시성을 부분적으로 관리한다. 각 서블릿 스레드는 다른 서블릿과 무관하게 돌아간다. 서블릿 모델이 제공하는 구조적 이점이 아주 크다. 하지만 작업 처리량(throughput) 개선이라는 요구로 인해 직접적인 동시성을 구현해야 한다. 미신과 오해 동시성은 향상 성능을 높여준다. 동시성은 때로 성능을 높여준다. 동시성을 구현해도 설계는 변하지 않는다. 무엇 과 언제 를 분리하면 시스템 구조가 크게 달라진다. 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. 어떻게 …

Intro 창발적? 이라는 단어를 처음 들었다. 구글에 검색해보니, 뜻은 다음과 같다. 창발적 설계로 깔끔한 코드를 구현하자 켄트 벡이 제시한 를 적용하면 SRP나 DIP와 같은 원칙을 적용하기 쉬워진다. 켄트 벡은 다음 규칙을 따르면 설계는 ‘단순하다’고 말한다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 어떠한 프로그램을 만들었을 때, 검증되지 않으면 무용지물이다. 검증되지 않은 프로그램은 절대 출시해서는 안 된다. 그렇기에 모든 테스트를 만들어야 하는데, SRP를 준수하면 단순해진다. 결합도가 높으면 테스트 케이스를 작성하기 어렵다. DIP를 적용하고 DI, 인터페이스, 추상화 등과 같은 도구로 결합도를 낮춘다. 즉, 테스트 케이스를 작성하면 설계 품질이 높아진다. 단순한 설계 규칙 2 ~ 4: 리팩터링 리팩터링 단계에서는 소프트웨어 설계 품질을 높이는 방법이라면 뭐…

Intro 도시를 세운다면? 도시는 적절한 추상화와 묘율화로 돌아간다. 그래서 큰 그림을 이해하지 않아도 개인과 개인이 관리하는 는 효율적으로 돌아간다. 소프트웨어도 똑같다. 깨끗한 코드는 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. 이번엔 높은 추상화 수준, 즉 시스템 수준에서도 꺠끗함을 유지하는 방법을 알아보자! 시스템 제작과 시스템 사용을 분리하라 를 분리해야한다. 위와 같은 방법이 초기화 지연(Lazy Initialization) 혹은 계산 지연(Lazy Evaluation) 기법이다. 장점 실제로 필요할 때까지 객체를 생성하지 않으므로 불필요한 부하가 걸리지 않는다. 따라서 애플리케이션을 시작하는 시간이 빨라진다. 어떤 경우에도 null 포인터를 반환하지 않는다. 단점 getService 메서드가 MyServiceImpl과 생성자 인수에 명시적으로 의존한다. 의존성을 해결하지 않으면 컴파일이 안된다. MyServiceImpl이 무거운 객체라면 테스트 전용 객체(TES…

Intro 코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 클래스 체계 표준 자바 관례에 따르면, 변수 목록이 가장 먼저 나온다. : , 상수 -> -> 비공개 인스턴스 변수 -> -> 즉, 추상화 단계가 순차적으로 내려간다. 그래서 신문처럼 읽힌다. 캡슐화 같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 변수를 로 선언하거나 패키지 전체로 공개한다. 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. 클래스는 작아야 한다! 함수는 로 크기를 측정했다면, 클래스는 을 센다. 클래스 이름에 , , 등과 같이 모호한 단어가 있다면 클래스에다 여러 책임을 떠 안겼다는 증거다. 또한 클래스 설명을 , , , 을 사용하지 않고서 25단어 내외로 가능해야 한다. 단일 책임 원칙 은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다. 큰 …