추상 팩토리 패턴 정의 객체들을 통째로 묶어서 팩토리 클래스로 만들고, 이들 팩토리를 조건에 따라 생성하도록 다시 팩토리를 만들어서 객체를 생성하는 패턴이다. 이전에 팩토리 메서드 패턴을 좀 더 캡슐화한 방식이라고 보면 될 것 같다. 팩토리 메서드와 다른점 팩토리 메서드: 객체 생성을 위임한다 추상 팩토리: 서로 관련이 있는 객체들을 묶어서 새로운 팩토리 클래스를 만든다. 장점 구체적인 제품과 클라이언트 코드 간의 긴밀한 결합을 피한다. 단일 책임 원칙: 제품 생성 코드를 한 곳으로 추출하여 코드를 더 쉽게 지원할 수 있다. 기존 클라이언트 코드를 손상시키지 않고 제품의 새로운 변형을 도입 할 수 있다. 단점 새로운 인터페이스와 클래스가 패턴과 함께 도입되기 때문에 코드가 생각보다 복잡해질 수 있다. 패..
팩토리 메서드 패턴 정의 객체 생성과 관련된 디자인 패턴으로 객체 생성 역할을 담당하면서 각 클라이언트에서 구현 클래스에 직접 의존하지 않도록 분리하는 패턴이다. 물론 새로운 클래스가 추가 되었을때 Facotory클래스를 수정해야하긴 한다. 한마디로, 인스턴스를 생성을 서브 클래스로 책임을 넘겨준다. 장점 확장에 열려있고 변경에 닫혀있게 된다. 중복된 코드가 줄어들고 상속하는 모든 클래스가 동일한 공통 로직을 사용할 수 있다. 객체가 변화할 여지가 있을때 상속하는 클래스를 하나 더 만들어서 구현해주면 된다. 단점 많은 클래스 파일이 생긴다. 패턴 적용전 이미지 표현 코드 간략하게 PizzaStore코드만 보여주겠다 PizzaStore.java public class PizzaStore { Pizza or..
템플릿 메서드 패턴 정의 부모 클래스에서 알고리즘의 골격을 정의하지만, 해당 알고리즘의 구조를 변경하지 않고 자식 클래스들이 알고리즘의 특정 단계들을 오버라이드(재정의)할 수 있도록 하는 행동 디자인 패턴이다. 전체적으로는 동일하면서 부분적으로는 다른 구문으로 구성된 메서드의 코드 중복을 최소화할때 유용하다. 또한 동일한 기능을 상위 클래스에서 정의하면서 확장/변화가 필요한 부분만 서브 클래스에서 구현할 수 있도록 한다. 예시로 커피와 홍차를 만들때 2개다 물을 끓여야한다고 하면 boiWater을 템플릿 메서드로 정의할 수 있다 장점 알고리즘 구조의 재사용성: 템플릿 메서드는 알고리즘의 일반적인 구조를 부모 클래스에 정의하므로, 여러 하위 클래스에서 이 구조를 재사용할 수 있습니다. 유연성과 확장성: 부..
데커레이터 패턴 정의 데커레이터는 어떤 기능에 추가적으로 기능을 덧붙이고 싶은 경우, 그 기능들을 Decorator로 만들어서 덧붙이는 방식입니다. 예시 토스트를 만들때 일반빵, 밀빵, 버터빵, 우유빵 선택사항이 존재하고 토핑으로 햄, 야채, 치즈, 달걀, 새우 그리고 마지막으로 소스로 마요네즈, 케찹, 칠리가 존재한다고 할때 토핑과 소스가 데커레이터가 됩니다. 왜냐면 보통 토스트는 빵(1개)+토핑(여러개)+소스(여러종류) 로 이루어지기 때문에 빵을 제외한 토핑과 소스를 더 추가 할 수 있는 데커레이터로 표현합니다. 장점 확장성(Extensibility): 데커레이터 패턴은 기존 클래스를 수정하지 않고도 새로운 기능을 추가할 수 있다. 즉 코드의 확정성을 향상시켜 새로운 동작을 간단하게 추가한다. 유연성..
옵저버 패턴 정의 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다. 다른 객체의 상태 변화를 별도의 함수 호출 없이 즉각적으로 알 수 있기 때문에 이벤트에 대한 처리를 자주해야 하는 프로그램에 매우 효율적이다. 장점 실시간으로 한 객체의 변경사항을 다른 객체에 전파할 수 있다. 느슨한 결합으로 시스템이 유여하고 객체간의 의존성을 제거할 수 있다. 단점 너무 많이 사용할 경우 상태 관리가 힘들 수 있다. 데이터 배분에 문제가 발생하면 큰 문제로 발전할 수 있다. 옵저버 패턴 적용전 Client public class Client { public static void main(String[] args) { Scor..
커맨드 패턴 정의 이벤트가 발생했을 때 실행될 기능이 다양하면서 변경이 필요한 경 우 이벤트를 발생시키는 클래스의 변경없이 재사용하고자 할 때 기술적정의: 실행될 기능을 캡슐화 함으로써 기능의 실행 요구하는 호출자 클래스(Invoker)와 실제 기능을 실행하는 수신자 클래스(Receiver, ex.Lamp)사이의 의존서을 제거한다. 따라서 기능의 변경에도 호출자 클래스를 수정없이 사용 가능 버튼이 눌렸을때 수행 될 기능을 캡슐화 기존의 코드는 OCP를 위배함 따라서 Command라는 인터페이스를 생성해서 새로운 기능이 추가되도 버튼에는 코드가 추가되지않는다. 커팬드 패턴 예시 이미지 출처 실습 인보커 로딩 순서 클라이언트 커맨드 객체 생성 SetCommand() 호출 클라이언트에서 인보커에서 명령 요청 ..
빌더패턴 집을 생각해보면 각각의 집들은 다른 요소들이 있을 수 있다.(주차장, 창문, 수영장, 정원) 근데 이런 집을 다 따로 만들자니 종류가 너무 많아지고 이거를 파라미터값으로 다 넣어주자니 메서드 하나에 파라미터값이 많아진다. 해결법: 빌더 패턴은 복잡한 객체들을 단계별로 생성할 수 있다. 그리고 빌더는 제품이 생성되는 동안 다른 객체들이 제품에 접근 하는 것을 허용하지 않는다. 자세한 내용은 아래 실습 예제를 보여주면서 설명하겠다. 실습 예제 Builder패턴 적용 이전 객체에 값을 할당하는 방법 생성자 생성 Setter 생성 Task클래스와 Client 클래스 코드 Task import java.util.Date; public class Task{ //항상 외부에서 사용못하게 하는 변수는 priv..
싱글톤 싱글톤 개념 싱글톤은 하나의 클래스 인스턴스를 전역적으로 공유하기 위한 디자인 패턴으로, 해당 클래스의 인스턴스가 오직 하나만 생성되고 어디서든 접근 가능하도록 보장한다. 클래스 내부에서 생성자를 private으로 선언하고, 유일한 인스턴스를 반환하는 정적 메서드를 제공한다. 다수의 객체 생성을 피하고 공유 리소스를 효율적으로 활용하는 패턴이다. ※디자인 패턴: 소프트웨어를 보다 모듈화하고 확장가능하며 유지보수가 쉽도록 만드는 해결책을 정리한 것이다 싱글톤 생성 예제 -> 문제점 -> 새로운 예시를 드는 방식으로 설명하겠다 public class Singleton { private static Singleton uniqueInstance; //하나뿐인 정젹 변수로 객체 선언 private Sing..
