Delegation

DelegationPattern . . . . 11 matches
     클래스에 대해 기능을 확장하는 두가지 방법중 하나이다. 하나는 상속이고 하나는 위임(Delegation) 이다. 상속을 하지 않아도 해당 클래스의 기능을 확장시킬 수 있는 방법이 된다.
     example) 예전에 VonNeumannAirport 을 JuNe 과 ["1002"] 가 Pair 하던중 JuNe 이 작성했던 Refactoring 으로서의 Delegation.
     이 기능을 추가하기 위해 일단 Airport Code 를 Refactoring 하기로 했다. 이를 위해 Airport 의 기능중 Configuration 과 관련된 기능에 대해 Configuration 을 Extract 하고, 내부적으로는 Delegation 함으로서 외부적으로 보이는 기능에 대해서는 일관성을 유지한다. (Test Code 가 일종의 Guard 역할을 했었음)
     DelegationPattern을 쓸 때 중요한 점은, DelegationPattern을 사용하는 클래스의 클라이언트는 그 클래스가 Delegation을 쓰는지 안쓰는지 몰라야 한다는 것이다. 즉, 우리에게 있어 DelegationPattern이 사용된 클래스는 여느 클래스와 동일하게 인식되고 사용되어져야 한다. 게을러서 남에게 자신의 숙제를 위임하는 학생은 절대 남들에게 그 사실을 노출해선 안된다.
     ["ResponsibilityDrivenDesign"] , ["Refactoring"], ["DelegationPattern"] 을 꾸준히 지켜주면 좋은 코드가 나올 수 있다. (["DesignPattern"] 이 유도되어짐)
     See Also Seminar:DelegationPattern
     전에 SE 수업중에 컴포넌트모델의 필요성을 이야기하던중 '상속으로의 재사용이 어렵기 때문에' 이야기를 하셨는데, 왜 대안 중 하나로서의 [Delegation] 에 대한 언급이 전혀 없으셨는지 모르겠다. Delegation 만 잘 이해해도 준 컴포넌트 스타일의 모듈화 프로그래밍을 잘 진행할 수 있고, 사람들 간의 작업분담도 잘 이끌어 낼 수 있을건데.. --[1002]
1002/Journal . . . . 7 matches
     그림을 보고 나니, Inheritance 나 Delegation 이 필요없이 이루어진 부분이 있다는 점 (KeywordGenerator 클래스나 BookSearcher, HttpSpider 등) Information Hiding 이 제대로 지켜지지 않은것 같다는 점, (Book 과 관련된 데이터를 얻고, 검색하여 리스트를 만들어내는 것은 BookMapper 에서 통일되게 이루어져야 한다.) 레이어를 침범한것 (각각의 Service 클래스들이 해당 로직객체를 직접 이용하는것은 그리 보기 좋은 모양새가 아닌듯 하다. 클래스 관계가 복잡해지니까. 그리고 지금 Service 가 서블릿에 비종속적인 Command Pattern 은 아니다. 그리고 AdvancedSearchService 와 SimpleSearchService 가 BookMapper 에 촛점을 맞추지 않고 Searcher 클래스들을 이용한 것은 현명한 선택이 아니다.)
     이전에 Delegation 하는 클래스를 해당 클래스 내에 멤버로 두었는데. 예를 들면 이런식으로
     해당 클래스 내에서 생성하는 디자인은 그 클래스를 교체해줄 수가 없으니 유연한 디자인이 아니다. 그렇다고 setter 를 두는 것도 좋은 디자인은 아닌것 같고. (프로그래밍 실행 중간에 Delegation 하는 객체를 교체할 일은 드물다. State Pattern 이나 Strategy Pattern 이 아닌이상.) 아마 처음에 Mock Object 를 이용하여 BookMapper 를 만들었었다면 Connection 을 직접 이용하거나, Library 객체를 내부적으로 직접 인스턴스를 생성하여 이용하는 디자인은 하지 않았을 것이란 생각이 든다.
      * DesignPatterns 연습차 간단하게 그림판을 구현해봄. 처음 간단하게 전부 MainFrame class 에 다 구현하고, 그 다음 Delegation 으로 점차 다른 클래스들에게 역할을 이양해주는 방법을 써 보았다. 그러던 중 MFC에서의 WinApp 처럼 Application class 를 ["SingletonPattern"] 스타일로 밖으로 뺐었는데, 계속 Stack Overflow 에러가 나는 것이였다. '어라? 어딘가 계속 재귀호출이 되나?..'
     Class 의 역할들을 Delegation 으로 다른 클래스들에게 위임시켜주면서 썼던 패턴이 대강 이랬던 것 같다.
      * ["SingletonPattern"] - Application Instance를 Global 객체로. 근데, 이는 일장일단인것 같다. 잘못하면 Application 중앙집중체제가 된다. Application 내에서 Delegation하는 객체들이 많은데, 그 덕에 Application 이 너무 중간 메세지 전달역할로만 작용하는것 같다. 뭐, ["FacadePattern"] 인양 된다면 모르겠지만. 이건 코드 커지고 난 뒤 두고볼 일인것 같다.
      * 학교에서 레포트를 쓰기 위해 (["ProgrammingLanguageClass/Report2002_2"]) 도서관에 들렸다. HowToReadIt 의 방법중 다독에 관한 방법을 떠올리면서 약간 비슷한 시도를 해봤다. (오. 방법들 자체가 Extreme~ 해보인다;) 1시간 30분 동안 Java 책 기초서 2권과 원서 1권, VB책 3권정도를 훑어읽었다. (10여권까지는 엄두가 안나서; 도서관이 3시까지밖에 안하는 관계로) 예전에 자바를 하긴 했었지만, 제대로 한 기억은 없다. 처음에는 원서와 고급서처럼 보이는 것을 읽으려니까 머리에 잘 안들어왔다. 그래서 가장 쉬워보이는 기초서 (알기쉬운 Java2, Java2 자바토피아 등 두께 얇은 한서들) 를 읽고선 읽어가니까 가속이 붙어서 읽기 쉬웠다. 3번째쯤 읽어나가니까 Event Listener 의 Delegation 의 의미를 제대로 이해한 것 같고 (예전에는 소스 따라치기만 했었다.) StatePattern으로의 진화 (진화보단 '추후적응' 이 더 맞으려나) 가 용이한 구조일 수 있겠다는 생각을 하게 되었다. (Event Listener 에서 작성했던 코드를 조금만 ["Refactoring"] 하면 바로 StatePattern 으로 적용을 시킬 수 있을 것 같다는 생각이 들었다. 아직 구현해보진 않았기 때문에 뭐라 할말은 아니지만.) 시간이 있었다면 하루종일 시도해보는건데 아쉽게도 학교에 늦게 도착해서;
Refactoring/BadSmellsInCode . . . . 6 matches
      * StrategyPattern, VisitorPattern, DelegationPattern
      * 불필요한 Delegation - InlineClass
     delegation 의 남용.
     RemoveMiddleMan, InlineMethod, ReplaceDelegationWithInheritance
     MoveMethod, MoveField, ChangeBidirectionalAssociationsToUnidirectional, ReplaceInheritanceWithDelegation, HideDelegation
     ReplaceInheritanceWithDelegation
FundamentalDesignPattern . . . . 5 matches
     DesignPatterns 의 패턴들에 비해 구현이 간단하면서도 필수적인 패턴. 전체적으로 가장 기본이 되는 소형 패턴들. 다른 패턴들과 같이 이용된다. ["Refactoring"] 을 하면서 어느정도 유도되는 것들도 있겠다. (Delegation의 경우는 사람들이 정식명칭을 모르더라도 이미 쓰고 있을 것이다. Java 에서의 InterfacePattern 도 마찬가지.)
     기본적인 것으로는 Delegation, DoubleDispatch 가 있으며 (SmalltalkBestPracticePattern에서 언급되었던 것 같은데.. 추후 조사), 'Patterns In Java' 라는 책에서는 Delegation 과 Interface, Immutable, MarkerInterface, Proxy 를 든다. (Proxy 는 DesignPatterns 에 있기도 하다.)
      * DelegationPattern
     근데, 지금 보면 저건 Patterns in Java 의 관점인 것 같고.. 그렇게 '필수적 패턴' 이란 느낌이 안든다. (Proxy 패턴이 과연 필수개념일까. RPC 구현 원리를 이해한다던지 등등이라면 몰라도.) Patterns in Java 에 있는건 빼버리는 것이 좋을 것 같다는 생각. (DoubleDispatch 는 잘 안이용해서 모르겠고 언어 독립적으로 생각해볼때는 일단은 Delegation 정도만?) --["1002"]
Refactoring/DealingWithGeneralization . . . . 4 matches
     == Replace Inheritance with Delegation ==
     http://zeropage.org/~reset/zb/data/ReplaceInheritanceWithDelegation.gif
     == Replace Delegation with Inheritance ==
      * You're using delegation and are ofter writing many simple delegations for the entire interface.[[BR]]''Make the delegating class a subclass of the delegate.''
     http://zeropage.org/~reset/zb/data/ReplaceDelegationWithInheritance.gif
SelfDelegation . . . . 3 matches
     == Self Delegation ==
     앞장에 나온 두가지 질문을 상기해보자. 위임한 객체의 주체성이 필요한가? 위임한 객체의 상태가 필요한가? 이 두가지에 yes라고 대답하면 Simple Delegation을 쓸수 없다.
     Self Delegation의 가장 뛰어난 예제는 Visual Smalltalk 3.0의 Dictionary구현이다. Dictionary는 각각의 상태에 대해 최적화된 HashTable을 여러개 가지고 있다. 이때, 자기 자신(Dictionary)를 넘겨주게 된다.
SimpleDelegation . . . . 2 matches
== Simple Delegation ==
위임을 사용할때, 당신이 필요한 위임의 묘미(?)를 분명하게 해주는 도와주는 두가지 이슈가 있다. 하나는, 위임하는 객체의 주체성이 중요한가? 이다. 위임된 객체는 자신의 존재를 알리고 싶지 않으므로 위임한 객체로의 접근이 필요하다.(?) 다른 하나는, 위임하는 객체의 상태가 위임된 객체에게 중요한것인가? 그렇다면 위임된 객체는 일을 수행하기 위해 위임한 객체의 상태가 필요하다.(너무 이상하다.) 이 두가지에 no라고 대답할 수 있으면 Simple Delegation을 쓸 수 있다.
Delegation . . . . 1 match
See Also [DelegationPattern]
MineFinder . . . . 1 match
* [http://zeropage.org/~reset/zb/download.php?id=KDP_board_image&page=1&page_num=20&category=&sn=&ss=on&sc=on&keyword=&prev_no=&select_arrange=headnum&desc=&no=57&filenum=1 1차일부분코드] - 손과 눈에 해당하는 부분 코드를 위한 간단한 예제코드들 모음. 그리고 지뢰찾기 프로그램을 제어하는 부분들에 대해 Delegation 시도. (CMinerControler 클래스는 처음 '막 짠' 코드로부터 지뢰찾기 제어부분 함수들을 클래스화한것임)
ProjectPrometheus/Journey . . . . 1 match
이 부분도 일종의 Architecture 의 부분일것인데, 지금 작성한것이 웬지 화근이 된것 같다는. Architecture 부분에 대해서는 Spike Solution 을 해보던지, 아니면 TDD 를 한뒤, Data Persistence 부분에 대해서 내부적으로 Delegation 객체를 추출해 내고, 그녀석을 Mapper 로 빼내는 과정을 순차적으로 밟았어야 했는데 하는 생각이 든다.

Found 10 matching pages out of 7555 total pages (5000 pages are searched)

Full text search for "Delegation"

You can also click here to search title.