객체 생성 처리를 서브 클래스로 분리해 처리하도록 캡슐화하는 패턴 - 객체의 생성 코드를 별도의 클래스와 메서드로 분리해 객체 생성의 변화에 대비 가능 - 특정 기능의 구현은 개별 클래스를 통해 제공되는 것이 바람직한 설계 --> 기능의 변경이나 상황에 따른 기능의 선택은 해당 객체를 생성하는 코드의 변경을 초래 --> 상황에 따라 적절한 객체를 생성하는 코드는 자주 중복 가능 --> 객체 생성 방식의 변화는 해당하는 모든 코드 부분을 변경해야 하는 문제 발생 Product: Factory Method로 생성될 객체의 공통 인터페이스 ConcreteProduct: 구체적으로 객체가 생성되는 클래스 Creator: 팩토리 메서드를 갖는 클래스 ConcreteCreator: 팩토리 메서드를 구현하는 클래스로..

데코레이터 패턴이란, 기능을 동적으로 유연하게 확장할 수 있게 해주는 패턴이다. 기본 기능 + "추가 기능" 추가 가능한 기능의 종류가 많은 경우에 각 추가 기능을 Decorator 클래스로 정의한 후 필요한 Decorator 객체를 조합해 추가 기능의 조합을 설계하는 방식 EX) 기본 도로 표시 기능 + 차선 표시/교통량 표시/교차로 표시/단속 카메라 표시 => 추가 기능의 모든 조합 = 13(4+6+2+1) *** 기본 기능에 추가할 수 있는 많은 종류의 부가 기능에서 파생되는 다양한 조합을 동적으로 구현할 수 있는 패턴 *** Component - 기본기능(ConcreteComponent)와 추가기능(Decorator)의 공통 기능을 정의 - 클라이언트는 Component를 통해 실제 객체를 사용함..

Observer Pattern이란, 한 객체의 상태 변화에 따라 다른 객체의 상태도 연동되도록 1:多 객체 의존 관계를 구성하는 패턴 데이터 변경이 발생하는 경우, 상대 클래스나 객체에 의존하지 않으면서 데이터 변경을 통보하고자 할 때 유용 Observer(Interface) 데이터 변경을 통보받는 인터페이스 Subject가 Observer 인터페이스의 update() 메서드를 호출 -> ConcreteSubject의 데이터 변경을 ConcreteObserver에 통보 Subject(Class) ConcreteObserver 객체를 관리하는 요소 Observer 인터페이스를 참조해서 ConcreteObserver를 관리하므로, ConcreteObserver를 관리하므로, ConcreteObserver의 ..

템플릿 메서드 패턴 이란, 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴이다. 전체적으로 동일하면서 부분적으로는 다른 구문으로 구성된 메서드의 코드 중복을 최소화할 때 유용 동일한 기능은 상위 클래스에서 정의하면서, 확장/변화가 필요한 부분만 서브 클래스에서 구현할 수 있도록 한다. AbstractClass -템플릿 메서드를 정의하는 클래스 -하위 클래스에 공통 알고리즘을 정의하고, 하위 클래스에서 구현될 기능을 primitiveMethod 또는 hookMethod로 정의 하는 클래스 ConcreteClass -물려받은 Primitive 메서드 또는 hook 메서드를 구현하는 클래스 -상위 클래스에서 구현된 템플..

부모 클래스로부터 상속받은 필드나 메소드를 자식 클래스에서 참조하는데 사용하는 참조 변수 인스턴스 변수명과 지역 변수명이 동일한 경우, this.인스턴스변수로 사용하는 것 처럼 부모클래스와 자식크래스 멤버의 이름이 같은 경우 super를 사용해 구별 class Parent{ int a=10; } class Child extends Parent{ int a= 20; void display(){ System.out.println(a); //20 System.out.println(this.a); //20 System.out.println(super.a); //10 } } public class Inheritance{ public static void main(String[] args){ Child ch = n..

Command Pattern이란, 실행될 기능을 캡슐화해 주어진 여러 기능을 실행할 수 있는 재사용성 높은 클래스를 설계하는 패턴 이벤트 발생시 실행될 기능이 다양하면서도 변경이 피요한 경우 이벤트를 발생시키는 클래스를 변경하지 않고 재사용하고자 할 때 유용 실행될 기능을 캡슐화해 기능의 실행을 요구하는 호출자(Invoker)클래스와 실제 기능을 실행하는 수신자(Receiver)클래스 사이의 의존성을 제거 -> 수신자의 변경에도 호출자의 수정없이 그대로 사용 가능 Invoker 기능의 실행을 요청하는 호출자 클래스 Command 실행될 기능에 대한 인터페이스 -> 실행될 기능에 대해 execute 메서드로 선언 ConcreteCommand 실제로 실행될 기능을 구현 -> Command 인터페이스를 구현 ..