Adapter

1. Adapter

2. Adapter - 의도 • 그래픽 에디터를 구현하고 있다 • 사각형, 선, 원 같은 도형 클래스는 구현하기 쉽지만, 텍스트 클래스는 비교적 어려운 편이다 • 외부에서 잘 구현된 TextView 클래스를 구해왔다. • 인터페이스가 맞지 않기 때문에 그냥 이용할 수는 없다 • TextView 의 소스를 수정하지 않고 그래픽 에디터에서 이용할 수 있는 방법은 없을까? • 소스코드를 수정하여 재사용 하는 것은 바람직하지 않다

3. Adapter - 구조 표준 TextView 를 표준에 맞게 중간에서 변환하기 위한 adapter

4. Adapter - 구조 • Text 클래스가 adapter class 이다 • TextView 클래스는 adaptee class 이다

5. Adapter - 위임으로 해결 • TextView를 이용해서 Text 클래스를 구현한다 • TextView에 비슷한 메소드가 있으면 그것을 이용하여 구현 • delegation(위임)으로 구현 void Text::Move(int x, int y) { textView.SetLocation(x, y); } void Text::Resize(int x, int y) { textView.SetSize(x, y); }

6. Adapter - 의도 • factoryMethod.Example23.java 에서 구현된 MyArray 는배열의 크기가 고정되었다 • java.util.ArrayList 는 배열의 크기가 동적으로 변하는배열 형태의 자료구조이다 • java.util.ArrayList 는 MyCollection, MyIterator 표준 인터페이스를 지원하지 않기 때문에 MyArray, MyList 와는 사용방법이 다르다 • java.util.ArrayList 를 이용하여MyArrayList 를 구현하자

7. Adapter - 구현

8. 실습: 구현 분석 • Example1.java • 위임으로 구현 • MyArrayList, MyArrayListIterator 가 adapter class • ArrayList, ArrayList 의 Iterator 가 adaptee class

9. Figure TextView + CreateManipulator () : Manipulator + Clone () : Figure + SetLocation ( in x : int , in y : int ) + Move ( in x : int , in y : int ) + SetSize ( in x : int , in y : int ) + Resize ( in x : int , in y : int ) Line Text + CreateManipulator () : Manipulator + CreateManipulator () : Manipulator + Clone () : Figure + Clone () : Figure + Move ( in x : int , in y : int ) + Move ( in x : int , in y : int ) + Resize ( in x : int , in y : int ) + Resize ( in x : int , in y : int ) Adapter - 구조 표준 TextView 를 표준에 맞게 중간에서 변환하기 위한 adapter

10. Adapter - 상속으로 해결 • inheritance(상속)으로 구현 void Text::Move(int x, int y) { SetLocation(x, y); } void Text::Resize(int x, int y) { SetSize(x, y); }

11. Adapter - 위임과 상속 • 상속을 하여 adapter class를 만들 때는 • protected member 도 사용 가능하다난 장점이 있다 • 위임을 하여 adapter class를 만들 때는 • adapter class와 adaptee class 사이에 polymorphism이 존재할 수 있다 • 즉 adaptee class가 abstract class이고 이것을 상속하는 많은 클래스들이 있는 경우

12. Adapter - 위임

13. Adapter - 위임 • Text 클래스는 MultiLineTextView 와 SingleLineTextView 의 adapter 가 될 수 있다

14. 실습: 생각해 봅시다 • 표준화와 위임(delegation)이 어떻게 활용되었나 살펴봅시다

15. Composite

16. Composite –의도 • 그래픽 에디터에서 그려진 도형의 그룹 객체를 생성할 수 있다 • 그룹 객체의 조작도 도형과 같아야 한다 • 그룹 객체 내부에 그룹 객체가 포함될 수 있다 • 코드에서 그룹 객체와 도형이 똑 같이 다뤄질 수 있어야 한다 • 이동, 크기 변경, 속성 변경, copy cut paste ... • 그룹 객체를 어떻게 설계하는 것이 바람직한가?

17. Composite –구조

18. Composite –구조 • Group 와 Figure 사이의 aggregation • Group 은 Figure 나 그 하위 객체로 구성된다 • 즉 Group 객체의 멤버는 Line, Text 같은 도형뿐만 아니라 Group 객체도 될 수 있다 • Recursive 구조 • Group 은 Figure 사이의 inheritance • Group 은 Figure 의 하위 클래스이므로 • Group 은 다른 Figure 객체와 똑 같이 다뤄질 수 있다

19. Composite –구조

20. Composite – Participants Component Client Leaf Leaf Composite

21. Composite –결과 • graphic editor 는 group 객체와 primitive 객체의 구분하지 않고 코딩될 수 있다 • graphic editor 코드가 단순해 진다 • 여러 단계의 group 이 가능하다 • 새 도형이 추가되어도 • group 기능을 수정할 필요 없이 • 새 도형도 group 으로 묶일 수 있다

22. Composite –구조

23. Composite –구조

24. Composite –결과 • MyCollection, MyArray, MyList 도 다른 모든 Java 클래스처럼Object 클래스를 상속 받는다 • MyArray, MyList 에 String, Interger 객체뿐만 아니라MyArray, MyList 객체도 add() 될 수 있다

25. 실습: 구현 분석 • Example1.java • Example2.java

26. Façade

27. Façade –의도 • 모듈/서브 시스템의 인터페이스가 너무 복잡한 경우 • public 클래스가 많고 public 메소드도 많다 • 어떤 작업을 하려면 복잡한 절차를 실행해야 한다 • 사용하기 간편한 인터페이스를 새로 만들자

28. Façade –의도 • Facade 패턴을 적용하면 • 서브시스템 사이의 호출 관계가 단순해진다

29. Façade –구조 Façade Subsystem

30. Façade –구조 • 복잡한 서브시스템을 대표하는 인터페이스 클래스  Façade 클래스 • Visual Studio와 같은 통합 환경에는 컴파일러 서브시스템과 텍스트 에디터 서브시스템이 포함된다 • 컴파일러 서브시스템의 내부는 매우 복잡하다 • Façade 클래스를 도입하여 복잡한 내부를 숨기자 • 외부에서는 Façade 클래스만을 호출

31. Façade –결과 • 서브시스템 사용법이 단순해 진다 • 클라이언트는 서브시스템 내부의 클래스들을 직접 호출하지 않는다 • 서브시스템 사이의 호출 관계가 단순해 지기 때문에 • 재사용성이 향상된다 • 서브시스템 경계가 분명해 진다

32. 하향식 설계 • 하향식 설계 • 먼저 시스템을 서브시스템들로 나누고 • 서브시스템들 사이의 상호작용과 인터페이스를 정의한다 • 각 서브시스템 내부를 모듈로 나누고 • 모듈들 사이의 상호작용과 인터페이스를 정의한다 • 각 모듈 내부를 클래스로 나누고 • 클래스들 사이의 상호작용과 인터페이스를 정의한다 • Façade 클래스 • 단계 2에서 정의된 서브시스템 인터페이스를 서브시스템을 대표하는 Façade 클래스로 구현 • 단계 4에서 정의된 모듈인터페이스를 모듈을 대표하는 Façade 클래스로 구현

33. 실습: 생각해 봅시다 • 객체지향 설계는 상향식인가? 하향식인가? • 상향식 설계 vs 하향식 설계

34. 객체지향 분석 • actor 와 시스템 사이의 상호작용을 설계 • actor 와 시스템 사이의 인터페이스를 설계 시스템 actor

35. 모듈 설계 • 모듈들 사이의 상호작용과 모듈 인터페이스를 설계 • 모듈을 대표하는 facade 클래스들간 상호작용과 façade 클래스 인터페이스를 설계 시스템 모듈1 facade 모듈2 actor facade facade 모듈3

36. 상세 설계 • 상세 클래스들 사이의 상호작용을 설계 • 상세 클래스의 인터페이스를 설계 시스템 actor

37. Proxy

38. Proxy - 의도 • 객체가 제공하는 기능은 일정하지만경우에 따라 그 객체에 대한 접근 방법이 달라져야 하는 경우가 있다 • 세금 계산을 해주는 클래스들 여러개 있다 • 어떤 경우는 아무나 세금 계산 메소드를 접근할 수 있지만 • 어떤 경우는 인가된 사용자만 가능하다 • 사용자의 권한을 검사하는 기능을 어디에 구현해야 하나? • 사용자의 권한을 검사하는 기능을 • 세금 계산 클래스에 구현? • 세금 계산 클래스를 사용하는 클라이언트에 구현?

39. Proxy - 의도 • 바람직한 방안 • 권한 검사를 별도의 클래스로 분리해서 구현 • 클라이언트는 권한 검사와 무관하게 구현됨 • 세금 계산 클래스도 권한 검사와 무관하게 구현됨 • 권한 검사가 필요할 때만 권한 검사 클래스를 중간에 삽입 • 어떻게 구현하면 • 클라이언트도 권한 검사와 무관하고 • 세금 계산 클래스도 권한 검사와 무관하게 될 수 있나?

40. Proxy - 구조

41. Proxy - 구조 • 권한검사가 세금계산을 상속받는다 • 권한검사의 사용방법이 세금계산과 같다 • 권한검사가 필요없는 세금계산은 클라이언트에서 바로 접근 • 권한검사가 필요한 세금계산은 권한검사를 거쳐서 접급

42. Proxy - 구조 Proxy Proxy

43. Proxy - 결과 • 권한 검사가 필요하면 • 적절한 권한 검사 객체를 선택하여 • 클라이언트와 세금 계산 객체 사이에 끼워 넣으면 된다 • 권한 검사가 필요 없으면 • 클라이언트와 세금 계산 객체를 바로 연결하면 된다

44. Proxy - 결과 • 클라이언트 코드는 권한 검사 클래스와 무관하다 • 클라이언트 코드는 세금계산과 그 메소드만 참조하여 구현된다 • 세금 계산 클래스도 권한 검사와 무관하게 구현된다 • 세금 계산 기능과 무관하게 권한 검사가 추가될 수 있다 • 권한 검사와 무관하게 세금 계산이 추가될 수 있다

45. Proxy - 의도 • 자료구조 클래스가 여러개 있다 • 대게 병렬성이 없는 환경에서 자료구조들이 사용되지만어떤 경우엔 다중 스레드 환경에서 사용되기도 한다 • 자료구조 클래스가 10개 있다고 하면thread safe 한 버전 10개를 다시 또 만들어야 하나?

46. Proxy - 구조

47. Proxy - 구조

48. 실습: 구현 분석 • Example1.java • Example2.java • Example3.java