Design Pattern

Abstract Method (추상 메소드)추상 클래스 내부에 선언되며, 하위 클래스에서 반드시 구현해야 한다.모든 하위 클래스가 공통적으로 가져야 하지만, 구현 내용은 다를 때 사용한다.예시: display() 모든 오리는 자신을 화면에 표시할 수 있어야 한다.

문제점:새로운 디스플레이를 추가하려면 코드 수정 필요실행 중에 디스플레이를 추가/제거 불가능WeatherData가 모든 디스플레이를 알아야 함 (강한 결합)"나를 관찰하고 싶으면 등록하세요"Observer 관리의 규격만 정의"has-a" 관계 (Subject는 Obse

문제점:새로운 기기를 추가하려면 RemoteControl 클래스 수정 필요리모컨이 모든 기기의 구체적인 클래스를 알아야 함 (강한 결합)실행 취소, 매크로, 큐잉 등의 기능 추가 어려움버튼 동작을 동적으로 변경할 수 없음"이렇게 실행하세요"실행의 규격만 정의캡슐화 관계

각 조합마다 클래스 만들자고? 너무 복잡해!아까보다는 나아보임has\*\* 함수를 봐라 너무 과하게 많다. 더블 추가면 어떻게 할건데? 불가능함녹차에 휘핑크림 넣을 수 없게 어떻게 막을건데? 못막음문제점:새로운 첨가물 추가 시 기존 코드 수정 필요 (OCP 위반)첨가물

문제점:구체적인 클래스에 직접 의존 (강한 결합)새로운 타입 추가 시 코드 수정 필요실행 중에 객체 타입 변경 불가능객체 생성 로직이 여러 곳에 중복"객체 생성 로직을 별도의 클래스로 분리"장점:객체 생성 로직을 한 곳에 캡슐화여러 클라이언트에서 재사용 가능단점:여전히

문제점:기존 시스템은 특정 인터페이스(Target)를 기대함새로운 벤더 라이브러리는 다른 인터페이스(Adaptee)를 제공소스 코드 수정이 불가능하거나 최소화하고 싶음직접 사용하면 호환되지 않음 (강한 결합)실제 상황 예시:레거시 시스템에 새로운 결제 시스템 통합구 버

문제점:클라이언트가 서브시스템의 모든 세부 클래스를 알아야 함 (강한 결합)서브시스템 사용법이 복잡하고 진입 장벽이 높음서브시스템이 변경되면 모든 클라이언트 코드 수정 필요너무 많은 옵션과 클래스로 인해 초보자가 어디서 시작해야 할지 모름복잡한 서브시스템에 대한 단순화

문제점:시스템 리소스가 낭비됨 (프린터 스풀러, 윈도우 매니저, 로그 등)전역 상태 관리가 어려움여러 인스턴스 간 데이터 불일치 발생 가능new 연산자로 누구나 인스턴스를 생성할 수 있음"외부에서 함부로 인스턴스를 만들 수 없게"생성자를 private으로 선언하여 ne

문제점:모든 메서드마다 복잡한 조건문 (if-else, switch) 반복새로운 상태 추가 시 모든 메서드 수정 필요상태 전환 로직이 여러 곳에 분산코드 유지보수가 매우 어려움OCP(Open-Closed Principle) 위반"각 상태마다 할 수 있는 행동의 규격"모

문제점:코드가 여러 클래스에 중복됨 (boilWater, pourInCup)알고리즘 변경 시 여러 곳을 수정해야 함새로운 음료 추가 시 중복 코드 증가알고리즘의 구조가 각 클래스에 분산되어 관리 어려움Abstract Class를 사용하는 이유:공통 구현 코드 공유boi

문제점:구체적인 구현(ArrayList, Array)에 직접 의존내부 자료구조가 변경되면 클라이언트 코드도 수정 필요각 컬렉션마다 다른 순회 방법을 알아야 함코드 중복 발생"컬렉션의 요소들을 순회하는 방법"순회 동작의 규격만 정의"can-traverse" 관계 (순회할

문제점:계층 구조(트리 구조)를 표현하기 어려움개별 객체(Leaf)와 복합 객체(Composite)를 다르게 처리해야 함타입 체크와 캐스팅이 필요 → 코드가 복잡해짐새로운 타입 추가 시 모든 조건문 수정 필요"모든 객체가 따라야 할 공통 규격"개별 객체와 복합 객체를

문제점:객체들이 서로를 직접 참조 (강한 결합)관계가 복잡해질수록 코드 유지보수가 어려움새로운 객체를 추가하거나 관계를 변경하려면 여러 클래스 수정 필요객체 간 통신 흐름을 이해하기 어려움"객체들 간의 통신을 나를 통해 하세요"객체 간 통신을 중재하는 규격 정의"coo

문제점:새로운 타입을 추가할 때마다 코드 수정 필요런타임에 동적으로 새로운 타입 추가 불가능복잡한 객체를 매번 처음부터 생성해야 함 (비용 증가)Factory 클래스 계층이 Product 클래스 계층과 병렬로 증가"나를 복제하고 싶으면 clone()을 호출하세요"복제

문제점:생성자 매개변수가 너무 많아서 순서를 기억하기 어려움선택적 매개변수 처리가 불편 (null 사용)다양한 표현(representation)의 객체를 만들기 어려움객체 생성 로직이 변경되면 모든 클라이언트 코드 수정 필요생성 과정이 복잡한 경우 단계별 제어 불가능"

문제점:무거운 객체를 매번 생성하면 성능 저하원격 객체에 직접 접근할 수 없음객체 접근 제어가 필요한 경우 처리 불가능네트워크 통신이 필요한 객체를 로컬 객체처럼 사용 불가능"RealSubject와 Proxy가 동일한 인터페이스를 제공하세요"클라이언트가 실제 객체인지

문제점:새로운 처리자를 추가하려면 코드 수정 필요요청을 보내는 객체가 처리자를 명시적으로 알아야 함 (강한 결합)실행 중에 처리 순서 변경 불가능처리자 추가/제거 시 클라이언트 코드 변경 필요"요청을 처리하거나 다음으로 넘기세요"요청 처리의 인터페이스 정의success

문제점:같은 데이터를 다른 형태로 표시하려면 코드 전체 수정 필요 (막대그래프 ↔ 파이차트)UI를 바꾸면 비즈니스 로직까지 영향 받음테스트 어려움 - UI 없이 로직만 테스트 불가능다중 뷰 지원 불가 - 하나의 데이터를 여러 화면에서 동시에 표시 어려움"데이터와 비즈니

문제점: 클래스 폭발 (Combinatorial Explosion)새 도형 추가 시: 모든 Drawing 버전마다 새 클래스 필요새 Drawing 라이브러리 추가 시: 모든 도형마다 새 클래스 필요M개 추상화 × N개 구현 = M×N개 클래스 😱추상화(도형 종류)와