도시를 세울 때

• 도시 관리 팀의 각 분야
• 추상화와 모듈화 - 큰 그림을 이해 못해도 구성요소는 효율적으로 돌아간다.
• 깨끗한 코드를 유지하면 낮은 추상화 수준에서 관심사 분리가 쉬워진다.
• 높은 추상화 수준 = 시스템 수준에서 깨끗함을 유지하는 방법

1. 시스템 제작과 시스템 사용을 분리하라.

• 시스템 제작 & 시스템 사용
• 준비 과정 : 객체 제작하고 의존성 연결
• 런타임 로직 : 준비 과정 이후의 작업

1. 상세 내용

• 객체 생성 및 의존성 주입

  • 초기화 지연 / 계산 지연 : 상위 타입으로 객체를 호출할 때 구현체를 주입한다. Service getService() { if (service = null) service = new ServiceImpl(); return service; }

    → 장점 : 과부하 감소. nullPointerExcpetion 방지

    → 단점 : 의존성이 주입되지 않으면 컴파일이 되지 않는다. 테스트시에 주입되는 구현체를 적절히 할당해야하고, null 테스트도 해야한다. 메소드가 두 가지 일을 한다. = SRP 위반 구현체가 모든 상황에 적합한지 알 수 없다.

  • Main을 분리

  • 생성과 관련된 코드는 main으로, 나머지는 객체를 생성하고 의존성이 연결됐다 가정

  

  • 팩토리

    • 추상 팩토리 패턴 : 서로 관련이 있는 객체들을 통째로 묶어서 팩토리 클래스로 만들고, 이들 팩토리를 조건에 따라 생성하도록 다시 팩토리를 만들어서 객체를 생성하는 패턴

    public class LGKeyboard implements Keyboard {
        public LGKeyboard(){
            System.out.println("LG 키보드 생성");
        }
    }
    
    public class SamsungKeyboard implements Keyboard {
        public SamsungKeyboard(){
            System.out.println("Samsung 키보드 생성");
        }
    }
    

    public class ComputerFactory {
        public void createComputer(String type){
            KeyboardFactory keyboardFactory = new KeyboardFactory();
            MouseFactory mouseFactory = new MouseFactory();
    
            keyboardFactory.createKeyboard(type);
            mouseFactory.createMouse(type);
            System.out.println("--- " + type + " 컴퓨터 완성 ---");
        }
    }
    

    

  • 의존성 주입 (DI)

    • 제어의 역전 (IoC) 기법을 의존성 관리에 적용한 매커니즘
    • 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다.
    • 새로운 객체는 넘겨받은 책임만 받기에 SRP 원칙을 지키게 된다.
    • main이나 특수 컨테이너를 사용한다. (ex. spring contrainer)
    • JNDI 검색은 의존성 주입을 부분적으로 구현한 기능이다.
      • 객체는 디렉터리 서버에 이름을 제공하고, 그 이름에 일치하는 서비스를 요청한다.

• 확장

  • 처음부터 완벽한 시스템은 없다.
  • 애자일 방법론 : 빠른 변화에 대응하기 위한 개발 방법론으로 고객의 요구사항에 맞추어 스프린트 계획을 세우고 스크럼 작업을 하는 스크럼 방법론이 있다.

  애자일 방법론은 소프트웨어 개발 방법론 중 하나로, 빠른 변화에 대응하기 위한 방법론으로 개발되었습니다. 애자일 방법론은 원활한 커뮤니케이션과 적극적인 고객 참여를 강조합니다.
  
  애자일 방법론에는 다양한 종류가 있지만, 가장 대표적인 것은 스크럼(Scrum) 방법론입니다. 스크럼 방법론은 일정 주기마다 일을 진행하고, 이를 스프린트(Sprint)라고 부릅니다. 각 스프린트는 고객 요구사항 중 일부를 구현하는 것을 목표로 합니다.
  
  스크럼 방법론에서는 팀원들이 자율적으로 업무를 분담하고, 매일 짧은 회의를 통해 진행 상황을 공유합니다. 또한 스프린트 회고를 통해 이전 스프린트에서 발생한 문제점을 분석하고, 개선 방법을 도출합니다.
  
  애자일 방법론은 비교적 빠른 시간 안에 결과물을 도출할 수 있고, 고객의 요구사항에 신속하게 대응할 수 있으므로 인기가 높습니다. 그러나 정해진 일정과 비용이 없는 프로젝트에서는 적합하지 않을 수 있습니다. 또한 팀원 간의 커뮤니케이션과 협업 능력이 중요하므로, 팀의 구성원과 문화가 적합하지 않을 경우 효과가 떨어질 수 있습니다.
  

  • 소프트웨어는 수명이 짧다. → 점진적인 발전이 필요 / 관심사의 분리 필요
  • EJB는 관심사 분리가 어려웠다.

• 관심사의 분리

  • 횡단(cross - cutting) 관심사
    • EJB2는 일부 영역에서 관심사를 완전히 분리했다.
  • 자바 프록시
  • 순수 자바 AOP 프레임워크
    • 스프링의 빈 = PoJo
  • AspectJ 관점

• 테스트 주도 시스템 아키텍처 구축

  • 간단한 아키텍처에서 시작해서 빌드업을 해라

• 시스템은 도메인 특화 언어가 필요하다

  • DSL (Domain Specific Language)