개발자를 위한 코드리뷰

코드리뷰를 왜 해야 하는가 ?

• 시장과 비지니스의 요구사항

  • 항상 변한다.
    • 빠르게, 자주, 안정적으로 배포 해야 한다.

• 릴리즈별 개발자 수(기하급수적 늘어남) , 릴리즈별 생산성 (늘어나지않음) , 릴리즈별 코드작성 비용 (늘어남)

• 동작 > 복붙 > 공유부족으로 인한 개발 인력에 대한 의존도 높아짐

아키텍처의 중요성

클린코드, 좋은설계, 아키텍처에 대한 중요성

• 중복이 하나도 없게 하는것도 리소스가 너무 들어감 (3개까지는..인정)

• Big ball of mud

  • 뚜렷한 아키텍처 없이 구현된 시스템

• 지속적으로 변화하는 요구사항 수용

코드를 잘짜는게 중요한 설계다.

• Agile 더 좋은 sw개발 , 단순절자변경 개발 역량
• Transformation ?

코드리뷰 목적

• 주목적: 품질문제 검수 (버그/장애)
• 부가 목적
  • 서로에게 관심
  • 지식공유
  • 집단 코드 오너십 및 결속 증대
• 컴퓨터가 할수 있는건 컴퓨터에게 맡겨라
• 스타일같은걸로 힘빼지 말자
• 기분안상하게 조심

리뷰는 즉시 시작

• 속도를 위해. PR은 작고, 범위가 좋은 사이즈로
• 너무 크면 PR을 분리하라
• 예제코드 제공에 관대해라 .
  • 다 알려줄 필요는 없지만 헤메는걸 보고있을 필요도 없다.

공격적 리뷰 자제

• 코드작성자에 대한 지적은 제외해라.
• 명령하지 마라. 요청해라
• 의견을 줄때는 레퍼런스로 .
• PR에 포함되지 않은 라인은 리뷰범위가 아님.

칭찬해라

• 잘못된 부분에 집중하지 말고 좋은변경에 대한 진심어린 칭찬을 해라 (특히 주니어에게)

교착상태를 피해라.

• 만나서 얘기해라 텍스트로는 한계가 있다.

• 인정하거나 Escalate 해라. (그냥 승인해라)

• 다른 리뷰어에게 할당

• 오프라인 리뷰 최소화 (오프라인상에서 선배가 하는 리뷰는 지시로 받아들일수 있다.)

• 코드 비난에 대한 두려움을 극복해라 - 그냥 받아들여라

DDD Start- 최범균

도메인주도 설계 구현과 핵심 개념 익히기.

1. 도메인 모델 시작

도메인 모델 패턴

도메인 규칙을 객체 지향 기법으로 구현하는 패턴

• 핵심 규칙을 구현한 코드는 도메인 모델에만 위치, 규칙이 바뀌거나 규칙을 확장해야 할때 다른코드에 영향을 덜주고 변경내역을 모델에 반영
• 점진적으로 만든 도메인 모델은 요구사항 정련을 위해 도메인 전문가나 다른 개발자와 논의하는 과정에서 공유 하기도 한다.

엔티티와 벨류

• 엔티티의 가장 큰 특징은 식별자를 갖는다. (ID)
• 타입을 보고 유추가 가능하게 해서 자연스럽게 코드가 이해되도록 한다.

도메인 모델에 set 넣지 않기

밸류타입은 불변으로 구현한다.

• set 메소드는 도메인의 핵심개념이나 의도를 코드에서 사라지게 한다.
• 생성자를 통해 받을수 있도록 한다.

도메인 용어

• 도메인 용어를 사용하여 구현하는 불필요한 변환과정을 하지 않아도 된다.
• 코드로 해석하는 과정이 줄어들어 이해하는 시간을 절약한다.

도메인 영역의 주요 구성요소

• DB엔티티와 도메인모델 엔티티의 차이.
  • 도메인 모델의 엔티티는 데이터와 도메인기능을 함께 제공한다.

2. 아키텍쳐 개요

DIP

Dependency Inversion Principle

• 저수준 모듈이 고수준 모듈에 의존
• 도메인과 응용 영역에 대한 영향을 주지 않거나 최소화 하면서 구현기술을 변경
• 중간에 요구사항(저수준)이 바뀌어도 응용영역을 변경하지 않아도 된다.

애그리거트 (Aggregate)

• 도메인 모델의 구성요소는 규모가 커질수록 복잡해진다.
• 관련객체를 하나로 묶은 군집 이다.
• 전체구조를 이해하는데 도움이 된다.

리포지터리 (Repository)

도메인 객체를 영속화 하는데 필요한 기능을 추상화

• 실제 구현 클래스는 인프라 스트럭처 영역에 속한다.

인프라 스트럭처 개요 (Infrastructure)

• 표현영역/응용영역/도메인영역을 지원
• 인터페이스를 도메인영역과 응용영역에서 구현하는것이 시스템을 유연하게 만든다. ex. @Transaction - 한줄로 트랜잭션을 처리한다. > 시스템을 유연하게 만든다.

3. 애그리거트

관련한 모델을 하나로 모아 복잡한 모델을 관리하는 기준을 제공

도메인 규칙과 일관성

• set 을 안넣는 이유
  • 자연스럽게 불변 타입으로 구성하게 되어 일관성이 깨질 확률이 낮아진다.
  • 의미가 드러나는 이름을 사용하게 될 확률이 높아진다.

트랜젝션 범위

• 한 트렌젝셔에서는 한 애그리거트만 수정 해야 충돌의 가능성이 줄어든다.
• 한 애거리거트 내부에서 다른 애거리거트 상태를 변경하는 기능을 실행하면 안된다.
• 한 애거리거트가 다른 애거리거트의 기능에 의존하면 결합도가 높아지게 된다.

ID를 통한 애그리거트 참조

모델의 복잡도가 하향한다.

ID를 통한 참조와 조회 성능

• N+1 조회 문제 : 조회대상이 N개면 N번 조회 (잘못된 ORM 설계)
• join 또는 query 를 통해 해결하자.

확장

• 초기에는 단일서버에 단일 DBMS로 구성이 가능하다.
• 사용자가 늘고 트래픽이 증가한다.
• 자연스럽게 부하를 분산하기 위해 도메인별로 시스템을 분리한다.

4. 리포지터리 모델구현

JPA를통한 리포지터리 구현

• ID로 조회/애그리거트 저장
• 밸류는 @Embededable 로 매핑 설정
  • 하이버네이트는 clear() 메소드를 호출하면 delete 쿼리로 삭제를 수행
  • 수행되길 원하지 않으면 단일클래스로 구현
• 밸류타입 프로퍼티는 @Embedded 로 매핑
• 조회시점에서 완전한 상태가 되게 하려면 Fetch.EAGER (반대는 Fetch.LAZY)

영속성 전파

• 삭제메소드는 애거리거트에 속한 모든객체를 삭제 해야 한다.
• CascadeType.PERSIST, CascadeType.REMOVE

5. 리포지터리 조회 기능

• Specification 을 구현해야 한다.
• JPA 정적메타모델
  • @StaticMetamodel(~~.class)
  • Criteria 를 사용할때 StaticMetamodel을 통해 구현하는것이 코드의 안정성이나 생산성측면에서 유리하다. (오타의 위험 및 자동완성)
• Criteria 의 문제점
  • 도메인모델은 구현기술에 의존하지 않아야한다.
  • Specification 인터페이스는 toPredicate() 가 JPA 의 Root 와 CriteriaBuilder 에 의존하고 있다.

동적 인스턴스 생성

• JPQL - select 절에 new ~~Enttiy()를 넣을 수 있따.
  • ex)SELECT new OrderView(o, m, p) FROM Order o, Member m, Product p ~~
• 장점 : JPQL을 그대로 사용, 객체 기준으로 쿼리를 작성할 수 있다.
• @Imutable, @Subselect, @Syncronize : 하이버네이트 전용 애노테이션 테이블이 아닌 쿼리결과를 @Entity로 매핑 할 수 있다.
• Update가 불가하므로 @Immutable 을 선언한다.
  • 생성된 모델기준으로 생기기때문에 매핑필드변경시 불가

6. 응용서비스와 표현영역

실제 사용자가 원하는 기능을 제공하는것은 응용영역에 위치한 서비스이다.

• 도메인 로직을 넣고싶은 욕심을 참아야 한다.
• ex) if member.checkPwd() { member.changePwd() } // 도메인에서 체크하고 구현해야한다.

분산구현

장점 : 한눈에 들어와서 코드의 가독성 증가 
단점 : 코드의 응집력약화, 알아보는데 분석이 필요하다.

응용서비스의 구현

하나의 클래스에서 모두 구현할 때

관련없는 서비스, 코드가 뒤섞이는것을 조심해야 한다.
클래스의 크기(줄 수)가 커질수 있다.
분리하는게 좋음에도 억지로 끼워넣게 된다.

• 표현영역 코드
  • 애거리거트 자체를 데이터로 주고받으면 코드의 응집도를 낮추게 된다.

HttpServletRequest 나 Session 을 주고받지 말자.

• 단독 테스트가 어려워지고, 세션, 쿠키 등 표현 서비스에 있어야 하는 정보가 응용서비스로 넘어가게 되어 표현영역의 응집도가 깨지게 된다.

7. 도메인 서비스

• 여러 애거리거트가 섞이게 되면 코드의 위치 등 책임의 문제가 드러나게 된다.
• 도메인 개념이 애거리거트에 숨어들어 명시적으로 드러나지 않게 된다.

도메인 서비스를 별도로 구현한다.

• 하위 패키지를 구분하여 위치 시킨다.

8. 어그리거트 트랜잭션 관리

선점 (Pessimistic) 비선점 (Optimisitic)

• 선점
  • 사용이 끝날때가지 다른스레드가 해당 애거리거트를 수정하는것을 막는다.
  • 보통 DBMS가 제공하는 행단위 Lock 을 통해 구현한다.
  • LockModeType.PESSIMISTIC_WRITE
  • 교착상태 방지를 위해 최대 대기 시간을 설정해야 한다.
• 비선점
  • 변경한 데이터를 싲레 DBMS 에 반영하는 시점에 변경 가능 여부를 확인하는 방식
  • 구현
    • 애거리거트 버전을 함께 보내어 확인한다.

9. 도메인 모델과 BOUNDED CONTEXT

• 도메인을 완벽히 표현하는 단일 모델을 만드는 시도. 이는 실행할 수 없다.
• 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트 라고 부른다.

10. 이벤트

• 트렌젝션 처리가 복잡해짐에 따라 속도 및 로직이 뒤섞이는 문제가 발생한다.
• 이러한 강한 결합 (high coupling)이 생기고, 이를 해결하기 위한 방법중 하나는 이벤트를 활용하는 추상클래스를 활용하는 것이다.
• 비동기 이벤트 처리 ex)
  • 로컬 핸들러를 비동기로 실행
  • 메시지 큐를 사용 - 글로벌 트렌젝션 문제
  • 이벤트 저장소와 이벤트 포워더 사용
  • 이벤트 저장소와 이벤트 제공 API 사용

11. CQRS

Command Query Responsibility Segregation, 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴

• 도메인 로직을 구현하는데 집중
• 구현해야 할 코드가 더 많아짐
• 더 많은 구현 기술이 필요

객체지향적 사고와 설계를 해야하는 이유는 사용자(관리자)의 서술적인 니즈를 비즈니스에 맞는 모델링을 하기위한 최적의 방법이기 때문이다.

1. 객체지향 사물의 분류
1. 사물(Things)은 곧 객체이다.
2. 사물에는 형태를 가진 것과 개념만 존재하는 것으로 분류할 수 있다.
3. 소프트웨어 분석 설계 구현을 한다는 것은 실세계의 사물을 가상세계의 사물로 전환 하는 것이다.
4. 객체 모델링, 데이터 모델링도 다 사물들을 관리하는 기준에 맞춰 분류하는 것이다.
5. 타입, 클래스는 객체 즉 사물을 분류했을 때 정의하는 것에 지나지 않는다.
2. 사물을 어떻게 분류할 것인가?
1. 책을 예시로 보면 책은 객체이다. 책에 대한 정보만 관리하는 것은 개념 객체이고 책의 실물을 관리하는 사물을 관리하는 객체가 구별되어 관리되어야 한다. 
2. 책이라는 객체가 책 정보에 대한 분류 기준으로 도서문헌상의 분류 규칙을 따르므로 다양한 분류체계를 관리하는 객체도 발생할 수 있다.
3. 사물은 단순이 존재한다고 하나의 객체만은 아니다.
4. 보는 관점, 각 비즈니스 도메인별로 차이가 발생하므로 사물의 분류 기준을 비즈니스 에 맞춰 모델링이 되어야 한다.

출처(http://www.slideshare.net/dahlmoon/20160131)

객체지향 5대 원칙

SOLID

SRP - 단일 책임의 법칙 : 클래스는 단 하나의 책임만을 가져야 한다.

OCP - 개방 폐쇄의 법칙 : 수정에는 닫혀있고 확장에는 열려있어야한다.

LSP - 리스코프의 치환법칙 : 자식은 부모로 대체 가능해야한다.

ISP - 인터페이스 분리의 법칙 : 범용 인터페이스 보다는 세분화된 인터페이스가 낫다.

DIP - 의존 관계역전의 법칙 : 구체 클래스에 의존하지 말고 인터페이스에 의존해라.

디자인 패턴

생성 (5)

Singleton : 하나의 클래스로 어디서든 접근 가능한 객체

Abstract Factory : 추상적인 부품을 통한 추상적 제품의 조립 (팩토리도 인터페이스 기반으로 만들자)

Factory Method : 변하지 않는 것은 부모가, 변하는것(객체생성이라) 자식이 오버라이딩

Builder : 동일한 공정에 다른 표현을 가진 객체 생성

Prototype : 복사본(clone) 을 통한 객체 생성

구조 (7)

Adapter : 인터페이스 변경을 통해 다른 클래스 처럼 보이기

Bridge : 확장 용이성을 위한 계층의 분리

Proxy : 기존 요소를 대신하기 위한 클래스(대리자)

Remote : 원격 객체를 대신

Virtual : 기존 객체의 생성 비용이 클 때

Protection : 기존 객체에 대한 접근 제어.

Facade : 하위 시스템 단순화하는 상위 시스템

Composite : 복합객체를 만들기 위한 패턴

Decorator : Composite와 같은데 기능의 확장

Flyweight : 동일한 속성을 가진 객체는 공유

행위 (11)

Iterator : 열거. 복합객체의 내부구조와 관계없이 동일한 구조로 열거 (Iterable, Iterator<T>)

Visitor : 복합객체 요소의 연산을 수행

Observer : 하나의 사건 발생 시 등록된 여러 객체에 전달

State : 상태에 따른 동작의 변화

Chain of Responsibility : 사건 발생 시 첫번째 객체가 처리 불가 시 다음으로 전달

Mediator : M:N 의 객체관계를 객체와 중재자 간의 1:1 관계로 단순화

Template Method : 변하지 않는것은 부모가, 변하는 것은 자식이 오버라이딩

Strategy : 알고리즘의 변화를 인터페이스기반의 클래스로 분리

Memento : 캡슐화를 위반하지 않고 객체의 상태를 저장 및 복구

Command : 명령의 캡슐화를 통한 Redo/Undo Macro

Interpreter : 간단한 언어를 설계하고 언어 해석기를 만들어 사용

Facade 패턴

 - 코드 랩핑(Code Wrapping)을 통해 의존성을 낮춘다.

1. class Hotel {
2.         // 호텔 정보
3. }
4.  
5. class Flight {
6.         @SuppressWarnings("unchecked")
7.         public List<Flight> getFlightsFor(Date from, Date to) {
8.                 return Collections.EMPTY_LIST;
9.         }
10. }
11.  
12. class HotelBooker {
13.         @SuppressWarnings("unchecked")
14.         public List<Hotel> getHotelNamesFor(Date from, Date to) {
15.                 return Collections.EMPTY_LIST;
16.         }
17. }
18.  
19. class FlightBooker {
20.         @SuppressWarnings("unchecked")
21.         public List<Flight> getFlightNamesFor(Date from, Date to) {
22.                 return Collections.EMPTY_LIST;
23.         }
24. }
25.  
26. class TravelFacade { // 코드 랩핑, 사용자는 Hotel, FLight에 대해 알 필요 없다.
27.         private HotelBooker hotelBooker;
28.         private FlightBooker flightBooker;
29.  
30.         public void getFlightAndHotels(Date from, Date to) {
31.         }
32.  
33.         public HotelBooker getHotelBooker() {
34.                 return hotelBooker;
35.         }
36.  
37.         public FlightBooker getFlightBooker() {
38.                 return flightBooker;
39.         }
40. }
41.  
42. public class Ex1 {
43.  
44.         public static void main(String[] args) {
45.         }
46.  
47. }

Bridge Pattern

 - 기능과 구현을 분리하는 패턴. 

 - 기능과 구현을 별도의 클래스로 정의하여 서로 분리하는 방법

 1. 계층 구조를 완만하게 만드는 효과

 2. 구현을 사용자로부터 완벽하게 숨김

 상속을 완만하게 만든다.

1. interface IMp3 {
2.         void play();
3.  
4.         void stop();
5. }
6.  
7. class IPod implements IMp3 {
8.  
9.         @Override
10.         public void play() {
11.                 System.out.println("play ipod");
12.         }
13.  
14.         @Override
15.         public void stop() {
16.                 System.out.println("stop ipod");
17.  
18.         }
19.  
20. }
21.  
22. // 사용자가 imp3 를 직접 사용하게 하지말고 중간층을 도입.
23. // 내부적으로 imp3를 사용.
24. // 내부의 구현을 사용자로부터 완벽하게 숨긴다.
25. // 기능과 구현을 구분한다.
26. class Mp3 {
27.         IMp3 mp3;
28.  
29.         public Mp3(IMp3 mp3) {
30.                 this.mp3 = mp3;
31.         }
32.  
33.         void play() {
34.                 mp3.play();
35.         }
36.  
37.         void stop() {
38.                 mp3.stop();
39.         }
40.  
41.         // 1분간 플레이 요구사항 발생
42.         public void playOneMinute() {
43.                 // 1분
44.                 mp3.play();
45.         }
46. }
47.  
48. class People {
49.         public void useMp3(Mp3 mp3) {
50.                 mp3.play();
51.         }
52.  
53. }
54.  
55. public class Ex1 {
56.         public static void main(String... args) {
57.                 People p = new People();
58.                 Mp3 mp3 = new Mp3(new IPod());
59.                 p.useMp3(mp3);
60.         }
61.  
62. }

Memento Pattern 

 - 객체의 상태 저장을 위한 패턴

 - 클래스 내부에 인스턴스 내부의 상태를 나타내는 역할을 도입해서 캡슐화의 파괴에 빠지지 않고  저장과 복원을 실행하는 패턴

 - 커맨드 패턴과 비슷하니 잘 분리를 해서 사용해야함.

Ex. 직렬화 (Serialization), Date, snap shot. 자바 내부에서 거의 쓰이지 않는다.

1. class Machine {
2.         private int state1;
3.         private int state2;
4.  
5.         private class Memento {
6.                 int state1;
7.                 int state2;
8.         }
9.  
10.         private List<Memento> backup = new ArrayList<>();
11.  
12.         public int createMemento() {
13.                 Memento m = new Memento();
14.                 m.state1 = this.state1;
15.                 m.state2 = this.state2;
16.                 backup.add(m);
17.  
18.                 return backup.size() - 1; // 특정 토큰을 반환한다.
19.         }
20.        
21.         void restoreState(int token) {
22.                 Memento m = backup.get(token); // 저장된 토큰으로 복구한다.
23.                 this.state1 = m.state1;
24.                 this.state2 = m.state2;
25.                
26. //              backup.remove(token); // 복구 시 삭제하는 것은 정책으로 결정.
27.                
28.         }
29.         void setState(int a, int b) {
30.                 this.state1 = a;
31.                 this.state2 = b;
32.         }
33.  
34.         @Override
35.         public String toString() {
36.                 return "Machine [state1=" + state1 + ", state2=" + state2 + ", backup="
37.                                 + backup + "]";
38.         }
39.        
40. }
41.  
42. public class Ex2 {
43.  
44.         public static void main(String[] args) {
45.                 Machine m = new Machine();
46.                 m.setState(1, 2);
47.                 System.out.println(m.toString());
48.                 int token = m.createMemento();
49.                
50.                 m.setState(30, 40); // 중간에 상태가 바뀌어도
51.                 System.out.println(m.toString());
52.                 m.restoreState(token); // 기억된 토큰으로 복구 시킬 수 있다.
53.                 System.out.println(m.toString());
54.                
55.         }
56.  
57. }

 Command Pattern

 - 명령들을 캡슐화(클래스)

 -  명령을 수행 단위로 묶음

 -> 명령을 추상화

 -  특정 객체에 대한 특정 작업을 캡슐화 하여 요청을 하는 객체와 수행하는 객체를 분리한다.

 - 요청을 객체화 형태로 캡슐화 하면 요청에 대한 저장 및 로깅, 연산의 취소를 지원할 수 있다.

1. interface Shape {
2.         void draw(); // LSP(리스코프의 치환 법칙) : 자식은 부모로 대체 가능해야 한다.
3. }
4.  
5. class Rect implements Shape {
6.         @Override
7.         public void draw() {
8.                 System.out.println("Draw Rect");
9.         }
10. }
11.  
12. class Circle implements Shape {
13.         @Override
14.         public void draw() {
15.                 System.out.println("Draw Circle");
16.         }
17. }
18.  
19. interface ICommand {
20.         void execute();
21.  
22.         boolean canUndo();
23.  
24.         void undo();
25. }
26.  
27. abstract class AddCommand implements ICommand {
28.         private final List<Shape> shapes;
29.  
30.         public AddCommand(List<Shape> s) {
31.                 this.shapes = s;
32.         }
33.  
34.         @Override
35.         public void execute() {
36.                 shapes.add(createShape());
37.         }
38.  
39.         @Override
40.         public boolean canUndo() {
41.                 return true;
42.         }
43.  
44.         @Override
45.         public void undo() {
46.                 shapes.remove(shapes.size() - 1);
47.         }
48.  
49.         public abstract Shape createShape();
50. }
51.  
52. class AddRectCommand extends AddCommand {
53.         public AddRectCommand(List<Shape> s) {
54.                 super(s);
55.         }
56.  
57.         @Override
58.         public Shape createShape() {
59.                 return new Rect();
60.         }
61. }
62.  
63. class AddCircleCommand extends AddCommand {
64.         public AddCircleCommand(List<Shape> s) {
65.                 super(s);
66.         }
67.  
68.         @Override
69.         public Shape createShape() {
70.                 return new Circle();
71.         }
72. }
73.  
74. class DrawCommand implements ICommand {
75.         private final List<Shape> shapes;
76.  
77.         public DrawCommand(List<Shape> s) {
78.                 shapes = s;
79.         }
80.  
81.         @Override
82.         public void execute() {
83.                 for (Shape e : shapes) {
84.                         e.draw();
85.                 }
86.         }
87.  
88.         @Override
89.         public boolean canUndo() {
90.                 return true;
91.         }
92.  
93.         @Override
94.         public void undo() {
95.                 System.out.println("Screen Cleared!!!");
96.         }
97. }
98.  
99. class MacroCommand implements ICommand {
100.         // Composite Pattern
101.         private List<ICommand> commands = new ArrayList<>();
102.  
103.         public void addCommand(ICommand c) {
104.                 commands.add(c);
105.         }
106.  
107.         // Ctrl + C  / Ctrl + D
108.         // Ctrl + D
109.        
110.         @Override
111.         public void execute() {
112.                 for (ICommand e : commands) {
113.                         e.execute();
114.                 }
115.         }
116.  
117.         @Override
118.         public boolean canUndo() {
119.                 for (int i = 0; i < commands.size(); i++) {
120.                         if (commands.get(i).canUndo() == false)
121.                                 return false;
122.                 }
123.  
124.                 return true;
125.         }
126.  
127.         @Override
128.         public void undo() {
129.                 int n = commands.size() - 1;
130.                 while (n >= 0) {
131.                         commands.get(n).undo();
132.                         n--;
133.                 }
134.         }
135.  
136. }
137.  
138. public class Ex1 {
139.         private static Scanner scanner;
140.  
141.         public static void main(String[] args) {
142.                 scanner = new Scanner(System.in);
143.                 List<Shape> shapes = new ArrayList<>();
144.  
145.                 Stack<ICommand> commandStack = new Stack<>();
146.                 Stack<ICommand> redoStack = new Stack<>();
147.                
148.                 MacroCommand mc = new MacroCommand();
149.                 mc.addCommand(new AddRectCommand(shapes));
150.                 mc.addCommand(new AddCircleCommand(shapes));
151.                 mc.addCommand(new DrawCommand(shapes));
152.                 mc.execute();
153.                
154.                 commandStack.add(mc);
155.  
156.                 ICommand command = null;
157.                 while (true) {
158.                         System.out.print("choice : ");
159.                         int cmd = scanner.nextInt();
160.  
161.                         switch (cmd) {
162.                         case 1:
163.                                 command = new AddRectCommand(shapes);
164.                                 command.execute();
165.                                 commandStack.push(command);
166.                                 break;
167.  
168.                         case 2:
169.                                 command = new AddCircleCommand(shapes);
170.                                 command.execute();
171.                                 commandStack.push(command);
172.                                 break;
173.  
174.                         case 9:
175.                                 command = new DrawCommand(shapes);
176.                                 command.execute();
177.                                 commandStack.push(command);
178.                                 break;
179.  
180.                         case -1:
181.                                 command = redoStack.pop();
182.                                 command.execute();
183.  
184.                         case 0:
185.                                 // Undo(ctrl + z)
186.                                 command = commandStack.pop();
187.  
188.                                 if (command.canUndo()) {
189.                                         command.undo();
190.                                         redoStack.add(command);
191.                                 }
192.                                 break;
193.                         }
194.  
195.                 }
196.         }
197. }

 Proxy Pattern (대리자 패턴)

 -- 처리과정이 복잡하거나 시스템의 리소스를 많이 필요하거나 하는 객체가 필요할 때,

 -- 간단한 처리는 대리자가 하고 실제객체가 필요할 때 생성하여 처리하는 패턴.

 1. Remote Proxy : 원격 객체에 대한 로컬의 대리자

  : RMI(Remote Method Invoke)

: C# WCF(SOAP), Android(Proxy), COM(RPC)

 2. Virtual Proxy : 많은 비용이 요구되는 객체를 생성하는 경우 실제 객체가 사용되기 전 까지 

  해당하는 객체에 대한 로딩을 지연할 수 있다.

Flyweight Pattern과 함께 사용한다. (Cache)

 3. Protection Proxy : 보호가 요구되는 객체에 대한 접근을 통제하고, 대리자를 통해 접근 제어하는 방법

객체의 타입에 따른 접근 제어 (ex. 리플렉션)

1. package com.tistory.metalbird;
2.  
3. import java.util.ArrayList;
4. import java.util.List;
5.  
6. class Calc {
7.         public void plus() {
8.  
9.         }
10. }
11.  
12. class CalcProxy {
13.         public void plus() {
14.                 new Calc().plus(); // RMI 기술의 예. 중간객체를 둠으로써 문제를 해결
15.         }
16. }
17.  
18. // 인터페이스 기반의 설계
19. interface Image {
20.         void showImage();
21. }
22.  
23. class ImageProxy implements Image {
24.         private String url;
25.        
26.         public ImageProxy(String url) {
27.                 this.url = url;
28.         }
29.         @Override
30.         public void showImage() {
31.                 // show image 가 호출 되었을때 로딩을 한다.
32.                 // 부하가 많이 걸리는 작업을 대리자에게 넘긴다.
33.                 System.out.println("lazy load");
34.                 RealImage image = new RealImage(url);
35.                 image.showImage();
36.         }
37.  
38. }
39.  
40. // 라이브러리 형태로 존재
41. class RealImage implements Image {
42.         private String url;
43.  
44.         public RealImage(String url) {
45.                 this.url = url;
46.                 // downloading from url.
47.                 // 부하가 많이 걸린다.
48.         }
49.  
50.         public void showImage() {
51.                 System.out.println("ShowImage : " + url);
52.         }
53.  
54. }
55.  
56. public class Ex1 {
57.  
58.         public static void main(String[] args) {
59.                 List<Image> images = new ArrayList<>();
60.                 images.add(new ImageProxy("http://a.net/1.jpg"));
61.                 images.add(new ImageProxy("http://a.net/2.jpg"));
62.                 images.add(new ImageProxy("http://a.net/3.jpg"));
63.                 images.add(new ImageProxy("http://a.net/4.jpg"));
64.  
65.                 for (Image i : images) {
66.                         i.showImage();
67.                 }
68.         }
69.  
70. }

Iterator Pattern 

- 컬렉션의 내부구조와 상관없이 그 집합체 안의 모든 항목을 열거하는 패턴

 - Java에서는 Iterable<E> / Iterator<E> 라는 인터페이스를 구현하면 사용 가능하다.

1. class Node<E> { //Generiec - type argument
2.         public final E data;
3.         public final Node<E> next; // Object
4.        
5.         public Node(E data, Node<E> next) { // Object
6.                 this.data = data;
7.                 this.next = next;
8.         }
9.        
10. }
11.  
12. class SList<E> implements Iterable<E> {
13.         private Node<E> head;
14.        
15.        
16.         public SList() {
17.                 head = null;
18.         }
19.         public void addFront (E n) {
20.                 head = new Node<E>(n, head);
21.         }
22.         public E front() {
23.                 return head.data;
24.         }
25.        
26.         @Override
27.         public Iterator<E> iterator() {
28.                 return new SListIterator<E>(head);
29.         }
30.        
31.         // 외부로 노출되지 않기 위해 private class 로 구현하는게 일반적이다.
32.         @SuppressWarnings("hiding")
33.         private class SListIterator<E> implements Iterator<E> {
34.                 private Node<E> current;
35.                
36.                 public SListIterator(Node<E> node) {
37.                         this.current = node;
38.                 }
39.                
40.                 @Override
41.                 public boolean hasNext() {
42.                         return current != null;
43.                 }
44.  
45.                 //현재의 요소를 반환하며 다음으로 이동
46.                 @Override
47.                 public E next() {
48.                         E value = current.data;
49.                         current = current.next;
50.                         return value;
51.                 }
52.  
53.                 @Override
54.                 public void remove() {
55.                         // 지원하지 않음
56.                         throw new UnsupportedOperationException("remove() unsupported!");
57.                        
58.                 }
59.                
60.         }
61. }
62. public class Ex2 {
63.        
64.         public static void main(String[] args) {
65.                 SList<String> s = new SList<>();
66.                 s.addFront("aaa");
67.                 s.addFront("bbb");
68.                 s.addFront("ccc");
69.                 Iterator<String> iter = s.iterator();
70.                
71.                 while(iter.hasNext()) {
72.                         System.out.println(iter.next());
73.                 }
74.                
75.                 for(String e : s) { // 내부적으로 iterator 를 사용한다.
76.                         System.out.println(e);
77.                 }
78.                
79.                 //Collections, List<T>  // interface
80.                
81.         }
82.  
83. }