11. 시스템

Author: HanweeeeLee

11. 시스템/README.md

@@ -0,0 +1,72 @@
+# 시스템
+## 복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다. - Ray Ozzie, Microsoft CTO
+
+## 시스템 제작과 시스템 사용을 분리하라
+### 소프트웨어 시스템은 준비과정과 런타임 로직을 분리해야한다. -> 관심사 분리
+ex)
+```
+public Service getService() {
+    if (service == null)
+        service = new MyServiceImpl(...); // 모든 상황에 적합한 기본값일까?
+    return service;
+}
+```
+-> lazy 
+장점 : 객체를 호출하기전까진 객체를 생성하지 않으므로 자원을 아낄 수 있고, 실행을 빠르게 할 수 있다. + Null을 불러 올 일이 없다.
+단점 : 하지만 getService메소드가 MyServiceImpl과 생성자 인수에 명시적으로 의존된다. <- 문제 1
+         문제 2 -> 테스트가 힘듦 .. Mock Data를 저 함수 안에 넣어야 한다.
+         문제 3 -> 런타임 로직에 객체 생성로직을 섞어놓음으로써 service가 Null인 경우등을 체크해야한다.
+         문제 4 -> 저 service객체는 모든 상황에 유효한 객체인가?
+
+### 해결방법 제시
+
+### Main 분리
+<img width="484" alt="1" src="https://user-images.githubusercontent.com/60125719/112974329-4c36ad00-918d-11eb-862e-4324d30efb86.png">
+
+#### 시스템에 필요한 객체를 모두 main에서 생성한 후 어플리케이션에 넘긴다. 그림을 보면 알겠지만 어플리케이션에선 어떻게 객체를 생성했는지 알 필요가 없다.
+
+
+### 팩토리
+<img width="626" alt="2" src="https://user-images.githubusercontent.com/60125719/112974486-7daf7880-918d-11eb-9495-27785cedc78c.png">
+
+#### Main분리와 비슷하지만 팩토리의 그림을 예로들자면 LineItem의 생성시점은 어플리케이션단이 결정하지만 어떤 비지니스 로직으로 LineItem을 만드는지는 Main이 알고있다.
+
+
+### 의존성 주입
+#### 사용과 제작을 분리하는 강력한 매커니즘중 하나. 
+```
+MyService myService = (MyService)(jndiContext.lookup(""NameOfMyService"))
+```
+<img width="411" alt="스크린샷 2021-03-30 오후 8 37 21" src="https://user-images.githubusercontent.com/60125719/112982763-d08e2d80-9197-11eb-98d2-629973d884e5.png">
+
+예제 별첨
+
+
+## 확장
+ 처음부터 어떤방향으로 확장하게 나갈지 예측하는것은 불가능. 소프트웨어 시스템은 물리적인 시스템과는 다르게 관심사를 적절히 분리해 관리해야만 점진적으로 발전할 수 있다.
+ 
+ EJB2? 횡단관심사? 설명해주세요.. 현기선생님..
+ 
+ ## 자바프록시
+ ## 순수 자바 AOP 프레임워크 AspectJ
+ 아이폰 개발자라 넘어가겠습니다.. 뭔소린지 모르겠어요  설명해주세요.. 현기선생님..
+
+
+
+
+## 테스트 주도 시스템 아키텍쳐 구축
+ 최선의 시스템 구조는 각기 POJO (또는 다른) 객체로 구현되는 모듈화된 관심사 역역(도메인)으로 구성된다. 이렇게 서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다. 이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있다.
+ 
+ #### POJO? 
+ ##### Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다. - 위키
+ ##### 우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고. — 마틴 파울러
+ <img width="691" alt="스크린샷 2021-03-30 오후 9 01 23" src="https://user-images.githubusercontent.com/60125719/112985455-2dd7ae00-919b-11eb-89ac-6e30d0981ad2.png">
+ 
+ ## 의사 결정을 최적화하라
+ 관심사를 나누자. 복잡성을 줄이자
+ 
+ ## 명백한 가치가 있을 때 표준을 현명하게 사용하라
+  표준을 사용하면 아이디어와 컴포넌트를 재사용하기 쉽고, 경험을 가진 사람을 구하기 쉬우며, 아이디어를 캡슐화하기 쉽고, 컴포넌트를 엮기 쉽다.
+  
+  ## 시스템은 도메인 특화 언어가 필요하다.
+