검색결과 리스트
글
기본적인 알고리즘 골격을 잡는 것에 좋다.
일부는 추상 클래스 내에서 구현을 하고, 일부는 상속받는 클래스 내에서 구현을 할 수가 있다.
기본적인 추상 클래스를 이용하여 짤 경우 많이 볼 수가 있다.
얼추보면 팩토리 패턴과 비슷한 느낌이기는 하나, 최상위 클래스 내에 그 행동들을 실행하는 템플릿 메소드가 존재한다.
뭐.. 단지 이런 차이가 아닐까 라는 생각도 든다.
팩토리 메소드 경우는 중간에 클래스를 두고 각기 해당하는 내용들에 대해서 처리 할 수 있지만
템플릿 메소드의 경우 각 해당하는 부분 부분을 나눠서 구현이 가능하고, 그 실행 주체를 최상위 클래스에 둔다는 점에서 다른 듯 하다.
일부는 추상 클래스 내에서 구현을 하고, 일부는 상속받는 클래스 내에서 구현을 할 수가 있다.
기본적인 추상 클래스를 이용하여 짤 경우 많이 볼 수가 있다.
얼추보면 팩토리 패턴과 비슷한 느낌이기는 하나, 최상위 클래스 내에 그 행동들을 실행하는 템플릿 메소드가 존재한다.
뭐.. 단지 이런 차이가 아닐까 라는 생각도 든다.
팩토리 메소드 경우는 중간에 클래스를 두고 각기 해당하는 내용들에 대해서 처리 할 수 있지만
템플릿 메소드의 경우 각 해당하는 부분 부분을 나눠서 구현이 가능하고, 그 실행 주체를 최상위 클래스에 둔다는 점에서 다른 듯 하다.
설정
트랙백
댓글
글
퍼사드 패턴..
뭐랄까..
그냥 나누어진 기능 덩어리를 한 클래스에 다 넣어놓고
각기 해당하는 기능의 메소드를 따로 정의 하여 그놈을 호출하면 된다.. 라는 느낌이 강하게 든다.
리모컨을 생각해보면 리모컨 안에는 많은 기능들이 있다.
그 기능을 감싸고 있는건 리모컨 박스..
그 안에서 각기 해당하는 놈들을 작동 시킨다고 생각하면 이해가 더 빠를거 같다.
즉 어떤 하위 시스템의 기능을 통합한 인터페이스를 제공하느 방식이다.
퍼사드는 이게 전부이다.
여기에서 보면 Mp3와 Movie가 하위 시스템이다
Facade 내부에는 이 모든 것을 포함하고 있고
클라이언트에서는 Facade 내부의 해당하는 메소드를 이용하여 각기 그 기능을 실행한다.
뭐랄까..
그냥 나누어진 기능 덩어리를 한 클래스에 다 넣어놓고
각기 해당하는 기능의 메소드를 따로 정의 하여 그놈을 호출하면 된다.. 라는 느낌이 강하게 든다.
리모컨을 생각해보면 리모컨 안에는 많은 기능들이 있다.
그 기능을 감싸고 있는건 리모컨 박스..
그 안에서 각기 해당하는 놈들을 작동 시킨다고 생각하면 이해가 더 빠를거 같다.
즉 어떤 하위 시스템의 기능을 통합한 인터페이스를 제공하느 방식이다.
퍼사드는 이게 전부이다.
Facade 내부에는 이 모든 것을 포함하고 있고
클라이언트에서는 Facade 내부의 해당하는 메소드를 이용하여 각기 그 기능을 실행한다.
설정
트랙백
댓글
글
어댑터 패턴.
어릴적.. 110V 콘덴서가 기억이 난다.
220V 바뀌고 난 다음 어쩔 수 없이 110V 연결 위에서 콘덴서를 이용 했던 적이!!
그 콘덴서가 바로 Adapter 역할을 하는 것이다.
하나의 인터페이스를 타겟으로 할 경우에는 Adapter Pattern을 이용하면 좋다.
여러 상황을 보면 다중 어댑터를 구현 해야 할 경우도 있다.
Turkey를 어댑터를 이용하여 Duck 로 변환하고자 할 경우
Duck duck = new U_adapter() 방식으로 변환하여 쓴다.
물론 U_adapter에는 그에 맞게 행동하는 내용들이 변환된 호출한 내용을 포함을 한다.
어릴적.. 110V 콘덴서가 기억이 난다.
220V 바뀌고 난 다음 어쩔 수 없이 110V 연결 위에서 콘덴서를 이용 했던 적이!!
그 콘덴서가 바로 Adapter 역할을 하는 것이다.
하나의 인터페이스를 타겟으로 할 경우에는 Adapter Pattern을 이용하면 좋다.
여러 상황을 보면 다중 어댑터를 구현 해야 할 경우도 있다.
Turkey를 어댑터를 이용하여 Duck 로 변환하고자 할 경우
Duck duck = new U_adapter() 방식으로 변환하여 쓴다.
물론 U_adapter에는 그에 맞게 행동하는 내용들이 변환된 호출한 내용을 포함을 한다.
RECENT COMMENT