From Gargantua

메소드에서 알고리즘의 골격을 정의함. 알고리즘의 여러 단계 중 일부는 서브클래스에서 구현할 수 있음. 알고리즘의 구조는 유지하면서 서브클래스의 특정 단계를 재정의 가능. public abstract class CaffeineBeverage { //전체적인 처리 과정을 관리 final void prepareRecipe() { //템플릿 메소드. 아무렇게나 음료를 만들지 못하도록 final 선언 boilWater(); brew(); pourInCup(); addCondiments(); } abstract void brew(); //서로 다른 방식으로 처리되는 메소드를 추상화 abstract void addCondiments(); //메소드를 일반화시켜서 베이스 클래스에 등록 void boilWater() {..

어떤 서브시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공 퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브시스템을 더 쉽게 사용 가능 인터페이스를 단순화 시키고 클라이언트와 구성요소들로 이루어진 서브시스템을 분리 public class HomeTheaterTestDrive { public static void main(String[] args) { Amplifier amp = new Amplifier("Top-O-Line Amplifier"); Tuner tuner = new Tuner("Top-O-Line AM/FM Tuner", amp); DvdPlayer dvd = new DvdPlayer("Top-O-Line DVD Player", amp); CdPlayer cd = new CdPla..

한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 사용 가능 호환되지 않는 인터페이스를 사용하는 클라이언트를 그대로 활용 가능 클라이언트와 구현된 인터페이스를 분리 인터페이스가 바뀌더라도 변경 내역은 어댑터에서 캡슐화되기 때문에 클라이언트는 바뀔 필요 없음 public interface Duck { void quack(); void fly(); } public interface Turkey { void gobble(); void fly(); } public class WildTurkey implements Turkey{ @Override public void gobble() { System...

커맨드 패턴 커맨드(Command) 패턴은 객체지향 디자인 패턴 중 하나로, 요청을 객체의 형태로 캡슐화하여 사용자가 서로 다른 요청을 실행할 수 있도록 합니다. 즉, 요청을 발생시키는 객체와 요청을 처리하는 객체 사이의 결합도를 낮추는 데에 사용됩니다. 요청을 하는 객체(Invoker)와 요청을 수행하는 객체(Receiver)를 분리 Command 객체가 Receiver 객체를 캡슐화 Command 객체를 이용해서 요청을 매개변수화 가능 Command 인터페이스: 수신자 객체와 관련된 작업을 수행하는 execute 메서드를 제공합니다. ConcreteCommand 클래스: Command 인터페이스를 구현하는 구체적인 커맨드 클래스입니다. 요청을 수신자 객체에 전달하는 책임을 갖습니다. Receiver ..

싱글턴 패턴 클래스 인스턴스가 하나만 만들어지도록 하고, 그 인스턴스에 대한 전역 접근을 제공 전역 변수에 객체를 대입하면 애플리케이션이 시작될 때 객체가 생성 한 번도 쓰지 않더라도 자원을 차지 싱글턴 패턴은 필요할 때만 객체 생성 고전적인 싱글턴 패턴 public class Singleton { private static Singleton uniqueInstance;//유일한 인스턴스를 저장하는 정적 변수 private Singleton() {}//외부에서 생성 불가능 public static Singleton getInstance() {//유일한 인스턴스를 반환하는 정적 메소드 if (uniqueInstance == null) { uniqueInstance = new Singleton();//게이른..

추상 팩토리 패턴 인터페이스를 이용하여 서로 연관된, 의존하는 객체를 구상 클래스를 지정하지 않고 생성 클라이언트에서 추상 인터페이스를 통해 제품들을 공급받을 수 있음 클라이언트와 팩토리에서 생산되는 제품을 분리 클라이언트는 제품을 직접 만들 필요없이, 팩토리를 선택하기만 하면 적당한 제품 생산 가능

정적 팩토리 (static factory method) 객체를 생성하기 위한 메소드를 실행시키기 위해서 객체의 인스턴스를 만들지 않기 위해 사용 서브클래스를 만들어서 객체 생성 메소드의 행동을 변경시킬 수 없다는 단점 팩토리 메소드 패턴 객체를 생성하기 위한 인터페이스를 정의, 어떤 클래스의 인스턴스를 만드는 일을 서브클래스에서 결정 디자인 원칙 1. 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다. (캡슐화) 2. 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다. 3. 상속보다는 구성을 활용한다. 4. 서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다. 5. 클래스는 확장에 대해서는 열려 있어야하지만 코드 변경에 대해서는 닫혀 있어야 ..

데코레이터 패턴 객체에 추가적인 요건을 동적으로 첨가한다. (구성과 위임을 통해) 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공한다. 데코레이터 패턴에서는 구상 구성요소를 감싸주는 데코레이터들을 사용한다. 데코레이터 클래스의 형식은 그 클래스가 감싸고 있는 클래스의 형식을 반영한다. (상속, 인터페이스 구현을 통해 자신이 감쌀 클래스와 같은 형식을 가지게 된다.) 데코레이터에서는 자기가 감싸고 있는 구성요소의 메소드를 호출한 결과에 새로운 기능을 더함으로써 행동을 확장한다. 구성요소의 클라이언트 입장에서는 데코레이터의 존재를 알 수 없다. 데코레이터 패턴을 사용하면 자잘한 객체들이 매우 많이 추가될 수 있고, 코드가 복잡해질 수 있다. public abstrac..

* 옵저버 패턴 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다 의존성을 정의 * Java 내장 옵저버 패턴 작동 방식 Observer 객체 : java.util.Observer 구현 Subject 객체 : java.util.Obervable 상속 * java.util.Observable 단점 . 클래스이기 때문에 상속해서 사용해야한다. 그래서 재사용성에 제약. . 인터페이스가 없기 때문에 Observer API와 잘 맞는 클래스를 직접 구현 불가. . Observable 클래스의 핵심 메소를 외부에서 호출 불가. 서브클래스를 인스턴스 변수로 사용 불가. -> 직접 API 구현해서 사용 * 디자인 원칙 1. 애플리케이션에서 달라지는 부분을..

소프트웨어 개발에 있어서 바뀌지 않는 것 : 변화 나중에 어떻게 바뀔 것인지 생각해라 디자인패턴 소프트웨어 디자인 과정에서 자주 발생하는 문제들에 대한 전형적인 해결책 훌륭한 객체지향 디자인 품질을 갖추고 있는 시스템을 개발하는 방법을 제공 구상 (Concreate) 클래스란? 추상 (Abstract) 클래스와 대조적으로 모든 메서드를 구현한 클래스 구성(Composition) : A has B (캡슐화, 느슨한 결합) 상속(Inheritance) : A is B 전략 패턴 알고리즘을 캡슐화하고 이를 교환하여 사용하는 패턴 전략 패턴은 코드의 유연성과 재사용성을 높여주며, 알고리즘의 변경이나 추가에 용이 비슷한 작업을 수행하지만 다양한 알고리즘을 적용해야 하는 경우에 전략 패턴을 사용하여 코드를 구현 C..