Skip to main content

진소희

1. 📌 핵심 개념 정리

✅ 요약하기

  1. 도시를 세운다면?
    • 도시를 세운다면? 온갖 세세한 사항을 혼자서 직접 관리할 수 있을까? 불가능하다.
    • 수도 관리 팀, 전력 관리 팀, 교통 관리 팀, 치안 관리 팀, 건축물 관리 팀 등 각 분야를 관리하는 팀이 있기 때문에 잘 돌아간다.
    • 도시가 잘 돌아가는 또 다른 이유는 적절한 추상화와 모듈화 때문이다. 그래서 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다.
  1. 시스템 제작과 시스템 사용을 분리하라
    • 우선 제작은 사용과 아주 다르다는 사실을 명심한다.
    • 소프트웨어 시스템은 (어플리케이션 객체를 제작하고 의존성을 서로 연결하는)준비과정과 (준비 과정 이후에 이어지는)런타임 로직을 분리해야 한다.
    • 시작 단계는 모든 애플리케이션이 풀어야 할 관심사다. 관심사 분리는 우리 분야에서 가장 오래되고 가장 중요한 설계 기법 중 하나다.
    • 불행히도 대다수 애플리케이션은 시작 단계라는 관심사를 분리하지 않는다. 준비 과정 코드를 주먹구구식으로 구현할 뿐만 아니라 런타임 로직과 마구 뒤석는다. 
      public Service getService() {
  if(service == null)
    service = new MyServiceImple(...);
  return service;
}
    • 이것이 초기화 지연 혹은 계산 지연이라는 기법이다. 이것의 장점은 여러가지다. 우선 실제로 필요할 때까지 객체를 생성하지 않으므로 불필요한 부하가 걸리지 않는다. 따라서 애플리케이션을 시작하는 시간이 그만큼 빨라진다. 둘째, 어떤 경우에도 null 포인터를 반환하지 않는다.
    • 하지만 getService 메서드가 MyServiceImpl과 생성자 인수에 명시적으로 의존한다. 런타임 로직에서 MyServiceImpl 객체를 전혀 사용하지 않더라도 의존성을 해결하지 않으면 컴파일이 안된다.
    • 테스트도 문제이다. MyServiceImpl이 무거운 객체라면 단위 테스트에서 getService 메서드를 호출하기 전에 적절한 테스트 전용 객체를 service 필드에 할당해야 한다.
    • 또한 일반 런타임 로직에다 객체 생성 로직을 섞어놓은 탓에 모든 실행 경로도 테스트해야 한다.
    • 책임이 둘이라는 말은 메서드가 작업을 두 가지 이상 수행한다는 의미다. 즉 작게나마 단일 책임 원칙을 깬다는 말이다.
    • 무엇보다 MyServiceImpl이 모든 상황에 적합한 객체인지 모른다는 사실이 가장 큰 우려다.
    • 초기화 지연 기법을 한번정도 사용한다면 별로 심각한 문제가 아니다. 하지만 많은 애플리케이션이 이처럼 좀스러운 설정 기법을 수시로 사용한다. 그래서 전반적인 설정 방식이 애플리케이션 곳곳에 흩어져 있다. 모듈성은 저조하며 대개 중복이 심각하다.
    • 체계적이고 탄탄한 시스템을 만들고 싶다면 흔히 쓰는 좀스럽고 손쉬운 기법으로 모듈성을 깨서는 절대로 안된다. 객체를 생성하거나 의존성을 연결할 때도 마찬가지다. 설정 논리는 일반 논리와 분리해야 모듈성이 높아진다. 또한 주요 의존성을 해소하기 위한 방식, 즉 전반적이며 일관적인 방식도 필요하다.
    • Main 분리
      • 시스템 생성과 시스템 사용을 분리하는 한 가지 방법으로, 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.
  1. 확장
    • o
  1. 자바 프록시
    • o
  1. 순수 자바 AOP 프레임워크
    • o
  1. AspectJ 관점
    • o
  1. 테스트 주도 시스템 아키텍처 구축
    • o
  1. 의사 결정을 최적화하라
    • o
  1. 명백한 가치가 있을 때 표준을 현명하게 사용하라
    • o
  1. 시스템은 도메인 특화 언어가 필요하다
    • o

2. 🤔 이해가 어려운 부분

🔍 질문하기

책을 읽으며 이해하기 어려웠던 개념이나 명확하지 않았던 내용을 정리합니다.

  1. 개념 또는 원칙의 이름
    • 어려웠던 부분
      해당 개념이 헷갈리거나 명확하지 않았던 점을 구체적으로 설명합니다.
    • 궁금한 점
      해당 개념이 어떤 원리로 동작하는지, 실무에서 어떻게 활용되는지 등을 질문 형태로 정리합니다.

3. 📚 참고 사항

📢 논의하기

관련된 자료가 있다면 공유하고, 더 깊이 논의하고 싶은 아이디어나 의견을 정리합니다.

  1. 관련 자료 공유
    • 추가 자료
      관련 블로그 글이나 공식 문서 링크를 제공합니다.
  1. 논의하고 싶은 주제
    • 주제
      논의하고 싶은 내용을 간략히 정리합니다.
    • 설명
      논의하고 싶은 이유를 작성합니다.
Back to top