[Week] 6주차 진도

[DaehunGwak]

• 발표자를 제외한 인원은 느낀점, 질문사항을 코멘트로 남겨주세요.
• 발표자는 발표자료를 준비하시고 공유해주세요.

이번 주 발표자

• @DaehunGwak

진도

• chapter 11: 시스템
• chapter 12: 창발성

발표자료

• chapter 11: 시스템
• chapter 12: 창발성

[ChoMk]

11장

도시를 세운다면?

도시가 돌아가는 또 다른 이유는 적절한 추상화와 모듈화 때문이다!!!

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

• 무엇보다 MyServiceImple이 모든 상황에 적합한 객체인지 모른다는 사실이 가장 큰 우려라고 한다.(예시에서..)
• 애플리케이션 곳곳에 위와 같은 초기화 지연 로직이 곳곳에 흩어져 있다. 모듈성은 저조하며 대개 중복이 심각하다.

main 분리

• main이나 main이 호출하는 모듈로 옮기고 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다..?..(누군가가 대신 만들어 줬다고 생각해도 될 듯?)

팩토리

아이템 생성 시점은 시스템이 결정하지만 아이템 생성하는 코드는 시스템이 모르게...

(예제에서는 인터페이스로 팩토리를 정의하고 이에 대한 factoryimpl에 대한 구현체를 따로 만들고 main에서는 이를 통하여 factoryimpl을 통하여 아이템을 만들고 어플리케이션에서는 이 팩토리를 factory(인터페이스)를 봐라보게하여 팩토리에서 직접적인 아이템의 만들어지는 로직을 모르도록 유지하는 예제로 보인다.)

DI

클레스 내부에서 만드는 것이 아닌 클레스가 만들어지는 시점에서 외부에서 생성이 필요한 친구들을 주입하는 방식 정도? 이렇게 된다면 재사용성이 높아지고 의존도가 떨어진다는 장점이 있는 듯 하다...(의존도가 떨어진다는 장점이란 새로운 A라는 객체에서 B를 만들 때 A의 어떠한 상황?(context)가 들어가게 된다면 A의 상황에 따라서 B의 객체가 달라질 수 있으니... A의 의존되지 않게 외부에서 B를 만들어 주입 받는 다면 다른 C라는 객체에서 B라는 객체를 사용하더라도 A에서 사용했던 B와 같은 B를 사용할 수 있는 점이 아닐까???)

확장

소프트웨어 시스템은 물리적인 시스템과 다르다. 관심사를 적절히 분리해 관리 한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.

프록시

개별 객체나 클레스에서메서드 호출을 감사는 경우가 좋은 예다.

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

• 서로다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다. 이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있다.

의사 결정을 최적화하라

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

12장

• 테스트 실행한다.
• 중복을 없앤다.
• 개발자 의도를 표현한다.
• 클래스와 메서드 수를 최소로 줄인다.

[minSW]

[Chapter 11] 시스템

📖 기억에 남는 부분 & 느낀점

시스템 역시 깨끗해야 한다.

도시를 세운다면?

• 도시가 돌아가는 이유
  • 각 분야를 관리하는 팀이 있기에 => 개인과 개인이 관리하는 '구성요소'
  • 적절한 추상화와 모듈화
• 소프트웨어 팀 vs 도시
  • 비슷한 수준으로 관심사 분리하거나 추상화 잘 이루지 못함
  • 깨끗한 코드 -> 낮은 추상화 수준에서 관심사 분리 O
  • 그렇다면, 높은 추상화 수준(시스템)에서도 깨끗함을 유지하는 방법?

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

• 제작(construction) vs 사용(use)
• 관심사(concern) 분리
  • 가장 오래되고 중요한 설계 기법 중 하나
  • 애플리케이션이 풀어야할 관심사 분리 => 시작 단계
• 일반 실행 논리와 설정 논리도 분리해야 모듈성 ↑
• 시스템 생성 <-> 시스템 사용을 분리하는 방법
  • Main 분리
  • 팩토리 (Factory)
  • 의존성 주입 (DI, Dependency Injection)

확장

• "처음에는 전력, 상수도, 하수도, 인터넷(허걱!)과 같은 서비스가 없었다."
  • 군락이 마을로, 도시로 성장하듯 시스템도 '확장' 되는 것
  • 하지만 성장에는 고통이 따른다
• '처음부터 올바르게' 시스템을 만들 수 없다
  • 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현하고, 내일은 또 맞춰서 조정하고..
  • => 반복적이고 점직적인 애자일 방식의 핵심
• 시스템은?
  • 물리적인 시스템과 소프트웨어 시스템은 다르다
  • 소프트웨어 시스템은 '수명이 짧다'는 본질로 인해 아키텍쳐의 점진적 발전 가능
  • 관심사를 적절히 분리해서 관리

결론

• 깨끗하지 못한 아키텍쳐
  • -> 도메인 논리를 흐림 -> 제품 품질이 떨어짐 (버그, 스토리 구현 Hard)
  • -> 기민성이 떨어짐 -> 생산성 감소 (TDD 장점 X)
• 모든 추상화 단계에서 의도는 명확히 표현할 것
  • POJO 작성, 관점(Aspect)과 같은 메커니즘으로 각 구현 관심사를 분리해야함
• 시스템이든 개별 모듈이든, 실제로 돌아가는 가장 단순한 수단을 사용할 것

[Chapter 12] 창발성

📖 기억에 남는 부분 & 느낀점

창발성 _ 하위 계층(구성요소)에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상 (ref. wikipedia)

단순한 설계 규칙을 따른다면 (오랜 경험 후에야 익힐) 우수한 기법과 원칙을 단번에 활용할 수 있다.

단순한 설계 규칙 네가지

• 켄트 벡이 제시한 규칙으로, 다음 규칙을 따르면 설계는 '단순하다'
• 규칙 순서는 중요도 순
  • 모든 테스트를 실행한다
  • 중복을 없앤다
  • 프로그래머 의도를 표현한다
  • 클래스와 메서드 수를 최소로 줄인다

표현하라

• 코드를 명백히 짤수록 결함과 유지보수 비용이 줄어듦
  • 좋은 이름을 선택한다
  • 함수와 클래스 크기를 가능한 줄인다
  • 표준 명칭을 사용한다
  • 단위 테스트 케이스를 꼼꼼히 작성한다
• 표현력을 높이는 가장 중요한 방법은 노력

[jin5335]

Ch11. 시스템

느낀점

• 소프트웨어 시스템은 준비과정과 런타임 로직을 분리해야 한다.
  • 준비과정: 어플리케이션 객체를 생성하고 의존성을 서로 연결하는 과정
  • 런타임 로직: 실제 애플리케이션이 수행하는 역할.
• 체계적이고 탄탄한 시스템을 구현하고 싶다면, 손쉬운 기법으로 모듈성을 파괴하면 안된다.
• 처음부터 올바르게시스템을 만들 수 있다는 믿음은 미신이다. -> 주어진 사용자 스토리에 맞춰 시스템을 구현 및 조정, 확장

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

• Lazy Initialization(초기화 지연) 및 Lazy Evaluation(계산 지연) -> 어플리케이션 시작 시점이 아닌, 실제 사용 시점에 객체를 생성 혹은 계산을 수행하는 것 -> 작게나마 SRP 위배.

Main 분리

• 생성과 관련한 코드를 모두 main 및 main이 호출하는 모듈로 이동.
• 애플리케이션은 main이 생성해준 객체를 사용할뿐 main에 대해서 알지 못함.

팩토리

• 애플리케이션이 객체 생성 시점을 결정할 때 사용하는 디자인 패턴
• abstract factory.

의존성 주입(DI, dependency injection)

• IoC(Inversion of Control, 제어 역전) 기법을 의존성 관리에 적용
  • IoC에서는 한 객체가 맡은 보조 책임을 새로운 객체 떠넘긴다.
• 의존성 주입: 클래스가 의존성을 해결하지 않는다. 의존성을 주입하는 setter method나 constructor를 제공.
• Spring framework: 가장 널리 알려진 자바 DI 컨테이너를 제공.
• Lazy Initialization으로 인한 장점도 가져갈 수 있다. 많은 DI 컨테이너들 실제 객체가 필요할 때 까지 객체를 생성하지 않는다.

확장

횡단 관심사(cross-cutting) 관심사

자바 프록시

순수 자바 AOP 프레임 워크

AspectJ 관점

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

의사 결정을 최적화하라.

명백한 가치가 있을 때 표준을 현명하게 사용하라.

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

결론

Ch12. 창발성(Emergence)

• 창발성 이란? - 단순한 것들의 결합이, 복잡한 결과(긍정적인 의미) 를 만들어 내는 것.
  • 창발성 설계: 간단한 규칙 4가지의 반복으로, 우수한 설계를 만듦.

느낀점

• 켄트백이 제안한 4가지 규칙을 반복하자.
• 경험을 대신할 단순한 개발 방법은 없다.

켄트백이 제안한 4가지 규칙

1. 모든 테스트를 실행한다.
   • “테스트 케이스를 만들고 계속 돌려라” -> 시스템은 낮은 결함도와 높은 응집력을 가지게 된다.
2. 중복을 없앤다.
   • 잦은 리팩토링을 할 수 잇는 환경을 조성하자
     • 처음부터 완벽하고, 이쁜 코드를 작성할 수는 없다. 리팩토링의 반복을 통해 예쁜 코드가 탄생한다.
   • “코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다!! -> 테스트 케이스가 존재하니까!!!”
3. 프로그래머 의도를 표현한다.
   • 명백하고 쉽게 구현하려. <- 노력
4. 클래스의 메소드 수를 최소로 줄인다.
   • 중복을 제거하고, 의도를 표현하며, SRP를 준수하는 개념도 극단적이게 되면, 득보다 실이 많다.
   • 함수와 클래스 크기를 작게 유지하면서, 동시에 시스템 크기도 작게 유지하자.

[KimYealynn]

Chaptor 11.시스템

높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법.

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

초기화 지연(계산 지연) 등의 좀스러운? 설정 기법을 수시로 사용하다 보면 전반적인 설정 방식이 어플리케이션 곳곳에 흩어지게 된다. 따라서 모듈성이 저조하고 중복이 심하다. 체계적인 시스템을 위하여 설정 논리와 실행 논리를 분리해 모듈성을 높이고, 주요 의존성을 해소하기 위하여 전반적인 일관 적인 방식이 필요하다.

• Main 분리
• 팩토리
• 의존성 주입

확장

시스템을 처음 부터 올바르게 만들 수 없다. 반복적이고 점진적인 애자일 방법을 통해 오늘의 요구에 맞추어 시스템을 조정하고 확장한다. TDD와 리펙토링을 통해 얻어지는 깨끗한 코드는 코드 수준에서 시스템 조정을 쉽게 만든다. 시스템 수준에서는 관심사를 적절히 분리해 관리한다면 점진적으로 발전 할 수 있다.

POJO

POJO ? 진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

• 어플리케이션 도메인 논리를 POJO로 작성할 수 있다면 (== 코드 수준에서 아키텍처 관심사 분리 가능) 테스트 주도 아키텍처 구축이 가능해진다. 아주 단순하고 멋지게 분리된 아키텍처로 프로젝트를 진행해 결과물의 재빨리 출시한 후 기반 구조를 추가하며 조금씩 확장해 나가도 괜찮다.
• 관심사를 모듈로 분리한 POJO 시스템은 최신 정보에 기반해 최선의 시점에 최적의 (복잡성도 낮은)결정을 내리기 쉬워진다.
• 도메인 특화언어를 사용하여 모든 추상화 수준과 모든 도메인을 POJO로 표현 할 수 있다.

결론

실제로 돌아가는 가장 단순한 수단을 사용하자.

Chaptor 12. 창발성

창발성을 촉진하는 단순한 설계 규칙

• 모든 테스트를 실행한다.
  • 테스트가 가능한 시스템을 만드려고 애쓰면 SRP를 준수하게 된다.
  • 결합도가 높으면 테스트 케이스를 작성하기 어려워 결합도를 낮추게 된다.
  • 낮은 결합도 + 높은 응집력 → 객체 지향 방법론이 지향하는 목표 달성
  • 리펙터링을 하며 테스트 케이스로 인해 시스템이 깨질 것을 걱정할 필요가 없다.
• 중복을 없앤다.
• 프로그래머 의도를 표현한다.
• 클래스와 메서드 수를 최소로 줄인다. → ??????????

[DaehunGwak]

Q

• 뭐를 위해 프록시 패턴을 사용하는 것인가!!?!?!?!!????!!!?!!
  • 필터라는 표현...
  • 왜 필요한지.. 어디서 쓰는지.. 더 공부해야 할듯 하옵니다...