1 / 16

Reflaction

Reflaction. 작성자 : 이진서 참고자료 : -POSA volume 1 -Devpia 아키텍처 마을에 YoungSu, Son. 씨 발표자료. 문제인식 (1/10). 문제. 사용기술과 요구사항이 변해감에 따라 시스템의 개방성 부족에 따른 한계성 어플리케이션 변경에 따라 모듈 구조가 변경 되면 종속된 모듈도 수정이 불가피 (tight coupling) 클래스간의 상속관계인 경우 관련된 모든 클래스를 변경해야 하는 문제점

henry
Download Presentation

Reflaction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Reflaction 작성자 : 이진서 참고자료: -POSA volume 1 -Devpia 아키텍처 마을에 YoungSu, Son. 씨 발표자료

  2. 문제인식(1/10) • 문제 • 사용기술과 요구사항이 변해감에 따라 시스템의 개방성 부족에 따른 한계성 • 어플리케이션 변경에 따라 모듈구조가 변경 되면 종속된 모듈도 수정이 불가피(tight coupling) • 클래스간의 상속관계인 경우 관련된 모든 클래스를 변경해야 하는 문제점 • 변경 작업을 진행할 때시스템의 다른 부분을 수정하거나 변경해야 하는 상황이 발생 • 예상치 못한 오류가 발생 • 시간과 비용이 많이 소요 • 관련된 기능 많은 단위테스트 필요 • 더욱더 복잡한 내부 구조를 가짐.(매개변수화,서브클래싱,copy and paste)

  3. Reflaction 패턴 탄생 배경(2/10) • 배경 • 어떻게 하면 수정과 확장에 개방되어 있는 아키텍처를 설계할수있을까? • 끊임없는 추가 요구사항, 버그수정,기능개선으로 변화무쌍 대처. • 기존 소스에 대한 수정 없이, 확장 및 변경 가능해야함.

  4. Reflection 아키텍처 패턴 (3/10) • Reflaction 1. Reflection이란? -compile 시가 아닌 run-time 시에 동적으로 특정 클래스의 정보를 객체를 통해 분석(추출)해내는 프로그래밍 기법 -관련 패키지 Java.lang.reflect • 2. Reflection 아키텍처 패턴이란? • 동적으로 소프트웨어 시스템의 행동과 구조변경을 제공하는 메커니즘 패턴 • 3. Open Close Principle? • 클래스,모듈, 함수 등 소프트웨어의 요소들은 modification에는 close되고, extention에는 open되어야 한다는 원칙 • 4. Reflaction 지원 언어 • java ,c# ,액션스크립트3.0, asp.net …. • 지원 안하는 것 . C, C++

  5. Reflection 아키텍처 패턴 사용예제(4/10) • 예제 객체를 디스크에 계속 쓰고 읽어야 하는 어플리케이션이 있다고 가정하자. 어떻게 하면, 변화에 유동적인 구조를 만들 수 있을까? 객체 타입에 독립적인'persistence component'를 만들어 보자.

  6. Solution(5/10) • 해법 어떤 객체를 저장하기 위해, 우리는 이 객체의 내부구조와 데이터 멤버들의 layout 을 알아야 하며. 이 정보를 이용해서 객체 내부 정보를 built-in 타입이 될 때까지 recursive 하게 들어간 후 저장해 준다. Meta Level : 자기자신의 구조, 행동 정보를 가짐. - metaobjects 로 구성. - 타입정보,서비스,객체생성과 같은 시스템정보를 제공해주는 역할 - metaobject 제공하는 입장 Metaobject Protocol (MOP) : meta level 와 base level 이 서로 통신하기 위해 사용하는 인터페이스. Base Level : 실질적인 로직(store, read) 구현 부분. -meta object를 사용하여 확장과 적응

  7. Structure(6/10)-1 • Meta Level • Meta Level은 metaobjects 의 집합으로 이루어진다. • Responsibility • 변화가 잦은 부분만 meta objects 로 encapsulated 되어야 한다.(type structure, algorithms, function call mechanism) • 2. 변경이 용이하게 하기위해 interface를 제공한다. • 3. 행동패턴은 controls base level과 유사하다. • Collaborator • 1. Base level과 상호작용을 한다.

  8. Structure(6/10)-2 • Base Level base level 연관되어 있는 metaobjects 와 직접 연결되어 있거나, 호출 Responsibility 1.어플리케이션의 로직을 구현한다. 2.Meta Level에서 제공하는 정보를 이용한다. Collaborator 1. Metalevel과 상호작용을 한다.

  9. Structure(6/10)-3 • MOP MOP(meta object protocol) 1.Meta Level 에 대한 명시적인 인터페이스. 2.MOP 의 client 는 base-level 컴포넌트, 다른 어플리케이션, 또는 권한을 가진 사용자가 될 수 있고, 3.이들은 MOP를 이용해서 meta objects의 수정이나 base level을 사용하는 relationship을 명시할 수 있다.

  10. Structure(6/10)-4 • Reflection Outline

  11. Dynamics(7/10)-1 • 시나리오(read) - 1 • -디스크에 파일이 저장되었다고 가정 • base레벨과 meta레벨간의 협력 관계를 설명 • 가정1: • 모든 데이터는 적절한 규칙에 따라 저장되어있다고 가정한다. • 가정2: • 저장된 파일은 타입식별자를 모두 가지고 있다고 가정한다. • 1) 사용자는 객체들이 저장되어 있는 파일 이름을 매개변수로 read() 를 호출 • 2) read() 는 readObject() 를 호출, type identifier를 찾는다. • 3) 객체를 생성하는 metaobject 를 생성 • 4) 객체의 데이타 멤버 iteratator 를 얻음. • 5) 타입식별자를 찾으면 데이터 할당하고 바로 객체 리턴 • 6)타입식별자 못찾으면 찾을때까지 계속 재귀호출하면서 완성된 객체를 리턴. * 메타객체: 객체 스스로 객체에 대한 정보를 담고 있는 것을 말합니다

  12. Dynamics(7/10)-2 • 시나리오(store) - 2 - 메타 레벨에 새로운 타입을 추가할 수 있는 클래스 라이브러리를 만들고 싶다. 1)새로운 타입의 RTTI(run-time type information) 를 MOP 에 전달(새로운 타입의 이름을 인수로 넘김) 2)MOP 는 type_info 객체 생성 3)extInfo 정보와 baseInfo 정보 생성 4)dataInfo 정보 생성. 5)dataInfo 정보를 Type-Info Metaobejct 에 등록/수정 6)이 완성된 새 타입의 객체를 'object creator' metaobject 에 등록

  13. Implementation(8/10) • 구현 1단계 : 애플리케이션의 모델을 정의한다. 2단계 :변경되는 동작을 정의한다. (어플리케이션의 어떤 부분이 자주 바뀔것인지, 어떤 부분은 stable 한지를 확인한다.) 3단계 :동작이 변경될때 기본 레벨에 영향을 미쳐선 안되는 시스템의 구조적 측면들을 정의한다. 4단계 :변경되는,변경되지 않는 구조적 세부사항들을 모두 지원하는 시스템 서비스를 정의한다. 5단계 :메타객체(metaobjects)를 정의한다. 6단계 :메타객체 프로토콜(MOP)을 정의한다. (분리된 컴포넌트로 제작) 7단계 :필요한 base level 을 정의한다.

  14. Known Uses(9/10) • Known Uses • -CLOS • The reflective programming language • -MIP • MIP is a runtime type information system for c++. • -Pgen • Pgen is persistenct component for c++ that is based on MIP. • -NEDIS • The car-dealer system NEDIS uses reflection to support its adaptation for customer and country-specific requirments • -OLE 2.0 • Provides functionality for exposint and accessing type information about OLE objects and their interface.

  15. Consequences(10/10) • 결론 • 장점: • 소스 코드를 임의로 수정하지 않아도 된다. • 소프트웨어 시스템의 변경이 쉽다. • 다양한 종류의 변경을 가능하게 한다. • 단점: • meta level 에 수정을 가할 경우 손상이 발생할수있다. • 컴포넌트 개수가 급격히 증가할수 있다. • 과하면 효율성이 떨어진다. • MOP 가 지원하는 부분 외에는 바꿀 수 없다. • 모든 언어가 리플렉션을 지원하지는 않는다.

  16. 참고예제 • 참고 Json -> VO로 변환 or VO -> JsonObject로 변환

More Related