주요글: 도커 시작하기
GoF Design Pattern, GoF 디자인 패턴, Object oriented, Visitor Pattern, Visitor 패턴, 객체 지향, 비지터 패턴

비지터 패턴 요약



저작자표시비영리변경금지
Command 패턴, GoF Design Pattern, GoF 디자인 패턴, GoF 설계 패턴, Object oriented, 객체 지향, 커맨드 패턴

GoF 커맨드 패턴 요약




저작자표시비영리변경금지
Chain of responsibility, GoF Design Pattern, GoF 디자인 패턴, Object oriented, 객체 지향, 책임 사슬, 책임 체인

GoF 패턴 Chain of Responsibility 요약



저작자표시비영리변경금지
GoF Design Pattern, GoF 디자인 패턴, Object oriented, Template Method Pattern, TransactionTemplate, 객체 지향, 태그를 입력해 주세요., 템플릿 메서드 패턴

GoF 디자인 패턴의 Template Method (템플릿 메서드) 패턴 요약




저작자표시비영리변경금지
GoF Design Pattern, GoF 디자인 패턴, Object oriented, Strateg pattern, strategy, 객체 지향, 스트래티지 패턴, 전략 패턴

GoF Strategy 패턴 요약



저작자표시비영리변경금지
GoF Design Pattern, GoF 디자인 패턴, Object oriented, state, state pattern, State 패턴, 객체 지향, 상태 패턴

GoF 패턴 State 요약




저작자표시비영리변경금지
Dependency, Object oriented, 객체, 객체 지향, 디펜던시, 의존

요즘 이런 저런 것들을 정리해보고 있는데, 그 중 일부 내용을 적어본다.


의존의 양면성


다음 코드를 보자.


public class Authenticator {

    public boolean authenticate(String id, String password) {

        Member m = findMemberById(id);

        if (m == null) return false;


        return m.equalPassword(password); // password가 m의 암호와 동일하면 true

    }

    ...

}


이 클래스를 사용하는 코드는 다음과 같이 checkPassword() 메서드를 이용해서 사용자가 입력한 암호가 올바른지 여부를 판단할 것이다.


public class AuthenticationHandler {


    public void handleRequest(String inputId, String inputPassword) {

        Authenticator auth = new Authenticator();

        if (auth.authenticate(inputId, inputPassword)) {

            // 아이디/암호 일치할 때의 처리

        } else {

            // 아이디/암호 일치하지 않을 때의 처리

        }

    }


}


위 코드에서 AuthentcationHandler 클래스는 Authenticator 클래스를 사용하고 있다. 즉, AuthenticationHandler 클래스가 Authenticator 클래스에 의존하고 있고, Authenticator 클래스에 변화가 생기면 AuthenticationHandler 클래스도 영향을 받게 된다.


그런데, 잘못된 아이디를 입력한 것인지 아니면 암호가 틀린 것인지 여부를 확인해서 시스템상에 로그로 남겨달라는 요구가 추가되었다. 이 요구를 충족시키려면 Authenticator의 authenticate() 메서드는 단순히 boolean 값을 리턴하면 안 된다. 아이디가 잘못되었는지 암호가 잘못되었는지 여부를 알려줄 수 있어야 한다. 예를 들면 AuthenticationHandler 클래스의 코드는 다음과 같이 익셉션을 통해서 인증 실패 이유를 구분할 수 있어야 한다.


public class AuthenticationHandler {

    public void handleRequest(String inputId, String inputPassword) {
        Authenticator auth = new Authenticator();
        try {
            auth.authenticate(inputId, inputPassword);
            // 아이디/암호가 일치하는 경우의 처리
        } catch(MemberNotFoundException ex) {
            // 아이디가 잘못된 경우의 처리
        } catch(InvalidPasswordException ex) {
            // 암호가 잘못된 경우의 처리
        }
    }

}


AuthenticationHandler 클래스를 위와 같이 작성하려면 Authenticator 클래스의 authenticate() 메서드가 다음과 같이 변경되어야만 한다.


public class Authenticator {

    public void authenticate(String id, String password) {

        Member m = findMemberById(id);

        if (m == null) throw new MemberNotFoundException();


        if (! m.equalPassword(password)) throw new InvalidPasswordException();

    }

    ...

}


AuthenticationHandler 클래스가 Authenticator 클래스에 의존하고 있는 상황에서, AuthenticationHandler 클래스의 변경 요구 때문에 Authenticator 클래스에 변화가 발생한 것이다. 이는 의존이 다음과 같이 상호간에 영향을 준다는 것을 보여준다.

  • 내가 변경되면 나에게 의존하고 있는 코드에 영향을 준다.
  • 나의 요구가 변경되면 내가 의존하고 있는 타입에 영향을 준다.

저작자표시비영리변경금지
GoF Design Pattern, GoF 디자인 패턴, Mediator 패턴, Object oriented, 객체 지향, 미디에이터 패턴

GoF Mediator 패턴 요약:



참고자료:


저작자표시비영리변경금지
GoF Design Pattern, GoF 디자인 패턴, Object oriented, Observer 패턴, publisher, pubsub, Subscriber, 객체 지향, 옵저버 패턴

GoF Observer 패턴 요약:



저작자표시비영리변경금지
  1. 훈이 2013.04.24 14:29

    굿

    # Delete Reply
Facade 패턴, GoF Design Pattern, GoF 디자인 패턴, object, Object oriented, 객체 지향, 파사드 패턴

GoF Facade 패턴 요약



저작자표시비영리변경금지
Decorator 패턴, GoF Design Pattern, GoF 디자인 패턴, Object oriented, 객체 지향, 데코레이터 패턴, 클래스 상속

GoF Decorator 패턴 요약



저작자표시비영리변경금지
Composite 패턴, GoF Design Pattern, GoF 디자인 패턴, Object oriented, 객체 지향, 컴포지트 패턴, 컴포짓 패턴

GoF Composite 패턴 요약



저작자표시비영리변경금지
builder, Design Pattern, GoF, 객체 지향, 디자인 패턴, 빌더 패턴

GoF Builder 패턴 요약한 것



저작자표시비영리변경금지
  1. 백명석 2013.04.10 09:14

    Exporter가 Fluent Interface를 제공하면 Employee에서

    exp.id(this.id)
    .name(this.name)
    .address(this.address)
    .build();

    이렇게 가독성이 좀 나아질 듯. 그리고 내게 builder는 한마디로 정의한다면 복잡한 설정이 필요한 객체 생성을 담당하는 놈. 즉 생성을 위한 정보 설정과 생성. 2가지 기능을 제공하는 놈. 만일 정보 설정 기능을 제공하지 않는다면 위 코드는.

    exp.build(this.id, this.name, this.address);

    가 될텐데... 3개의 파라미터가 다 String이라면 순서를 지키거나, 각 파라미터의 의미를 명확히하기 어려움. 하지만 처음의 코드는 각 this.id가 아니라 String s라고 되어 있어도 아 이게 id구나라고 알 수 있음. 그런 면에서 Builder가 보다 대중적으로 사용될 수 있다고 생각함. XML Node Composite 생성처럼 꼭 객체 생성 과정이 복잡하지 않더라도...

    그냥 그렇다고...

    # Delete Reply
Design Pattern, FactoryMethod, GoF, 객체 지향, 디자인 패턴, 팩토리메서드

GoF 패턴 FactoryMethod 요약한 것.




저작자표시비영리변경금지
  1. 백명석 2013.04.10 09:40

    범균님도 언근한 것 처럼 Factory Method는 Template Method의 일종이라고 생각됨.

    # Delete Reply
    • 최범균 madvirus 2013.04.10 13:21 신고

      객체 생성이 템플릿 메서드에서 많이 호출되는 경우도 있어서, 템플릿메서드와 함께 자주 사용되는 듯 합니다.

      # Delete
AbstractFactory, Design Pattern, GoF, 객체 지향, 디자인패턴, 추상팩토리 패턴

GoF 패턴 AbstractFactory 요약한 것



저작자표시비영리변경금지
  1. 백명석 2013.04.10 09:44

    나한테 참 어려운 패턴 중 하나였는데. 예제(JDBC)가 훌룡 ^^

    # Delete Reply
    • 최범균 madvirus 2013.04.10 13:19 신고

      일반적인 웹 개발에서 접하는 것 중에 JDBC가 잘 들어맞는 것 같아요. 객체 군을 생성해주는 팩토리를 만들어본 기억이.. 음.... 없는 것 같기도 하고 말이죠...

      # Delete

+ Recent posts