이번주는 10장과 11장이다. 이제 절반정도 읽었다!

10장 클래스

• 클래스 체계

  • public static 변수
  • private static 변수
  • private 인스턴스 변수 → public 변수는 캡슐화를 위해 거의 안쓸듯
  • public 함수
  • private 함수는 호출하는 public 함수 아래로
  • 이렇게 하면 추상화 단계가 순차적임

  나는 이렇게 잘하고 있었다! 하하

• 클래스는 작게!!

  • 클래스가 맡은 책임을 하나로 → 객체지향 5원칙중 SRP를 지키라는 뜻 아닐까?
  • SRP(Single Responsibility Principle) - 바로 설명이 나온다 ㄷㄷ
    • 클래스는 책임, 즉 변경할 이유가 하나여야 한다
    • 우리는 깨끗하고 체계적인 소프트웨어 보다 돌아가는 소프트웨어에 초점을 맞추다보니 이 규칙을 잘 지키지 않게 된다 → 지금 만들고 있는 스터디봇 리팩토링하는 나같다..
  • 응집도
    • 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높다
    • 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다
  • 응집도를 유지하면 작은 클래스 여럿이 나온다.

이번에 리팩토링을 진행하면서 거대한 클래스를 계속 쪼개고 있는데 쪼개도 쪼개도 부족한 느낌이다..
응집도가 높은 상태를 유지하면서 쪼개봐야겠다

• 변경하기 쉬운 클래스
  • 새 기능에 개방적인 동시에 다른 클래스를 닫아놓는 방식으로 구현
  • 예시를 보면 SQL 이라는 클래스에 있던 메서드들을 SQL 클래스를 상속받는 CreateSQL, SelectSQL 등등으로 쪼개서 관리한다 → 이 방식은 새로운 기능을 추가할 때 기존의 클래스를 수정하는게 아닌 기존 클래스를 상속받아 확장 하라는 의미인 것 같다

딱 변경하기 쉬운 클래스라는 소제목만 봤을때 OCP 를 위반하는게 아닌가? 라는 생각이 들었는데 추상화하라는 뜻 같다!
마침 오늘 리팩토링 하면서 Commands 인터페이스를 상속받는 TextCommands와 RecordCommands로 나눠서 확장성을 고려해줬는데 딱 나오니까 기분이 좋다 ㅎㅎ

• 변경으로부터 격리
  • 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리
  • 결합도를 낮추면 유연성과 재사용성이 더욱 높아진다
  • 코드 예시를 보면 자동차 미션을 진행할 때 사용했던 전략 패턴 같은 것들을 이용해 유연한 코드를 짤 수 있도록 보여준다

11장 시스템

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

  • 소프트웨어 시스템은 애플리케이션 객체를 제작하고 의존성을 서로 연결하는 준비 과정과 준비 과정 이후에 이어지는 런타임 로직을 분리해야 한다. → 어떻게 하지
  • 관심사

    public Service getService() {
    	if (service == null) {
        	service = new MyServiceImpl(....);	// 모든 상황에 적합한지?
        }
      	return service;
    }

    • 위의 코드는 초기화 지연 혹은 계산 지연 이라는 기법 - 필요할 때까지 객체 생성 X - 불필요한 부하 없음, null 반환 안함
    • 의존성이 생기는게 문제, 테스트에서도 문제가 생김

• Main 분리

  • main 함수에서 시스템에 필요한 객체를 생성한 후 애플리케이션에 넘김 - 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모름

• 의존성 주입

  • 호출하는 객체는 실제로 반환되는 객체의 유형을 제어하지 않는다. 대신 호출하는 객체는 의존성을 능동적으로 해결

• 확장

  • '처음부터 올바르게' 시스템을 만들 수 있다는 믿음은 미신이다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장해야 한다. → 반복적이고 점진적인 애자일 방식의 핵심

• 자바 프록시

  • 와 이건 어렵네;; 나중에 다시 봐야겠다 - SpringBoot 만 해보고 Spring은 안해봐서 모르는 부분도 좀 있다..

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

  • 설계가 최대한 분리되면 각 추상화 수준과 범위에서 코드가 적당히 단순함
  • 좋은 API는 걸리적거리지 않아야 한다.
  • 최선의 시스템 구조는 각기 POJO 객체로 구현되는 모듈화된 관심사 영역(도메인)으로 구성된다. 이렇게 서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 괒ㄴ점이나 유사한 도구를 사용해 통합한다. 이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있다.

• 의사 결정을 최적화하라

  • 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다.

• 결론

  • 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 도메인 논리가 흐려지면 제품 품질이 떨어진다. 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다. 기민성이 떨어지면 생산성이 낮아져 TDD 가 제공하는 장점이 사라진다.
  • 시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

11장은 좀 어려운 것 같다....