디자인패턴

생성자를 통한 객체생성은 간편한 객체생성을 보장한다. new Object()의 형태로 손쉽게 객체를 생성할 수 있고, 자바 문법에서 가장 기초적인 방법이기도 하다. 그러나 객체생성의 수단으로 생성자가 노출된다는 말은 무분별한 객체생성을 제어할 수 없다는 말이기도 하다

보통 생성자에 필요한 매개변수가 너무 많을 때 사용Director로 사용할 Builder를 선택하고 ConcreteBuilder로 인스턴스를 생성하는 형식이다비유하자면 건설도면을 선택해서 작업반장한테 이렇게 만들어달라고 부탁하는 꼴이다Pizza 클래스가 있을 때, 이

현재 객체의 복사본을 생성하는 패턴현재 객체와 똑같은 값을 가진 새로운 객체를 생성시키는 디자인패턴이다 반복해서 사용되는 특정 형태의 인스턴스가 정해져있는 상황에서 유용하다clone() 메서드를 직접 만들어서 구현하거나 Cloneable을 상속하여 사용하는게 가능하

객체가 항상 하나임을 보장해야하는 경우예를들어 MVC에서의 Service나 Dao의 경우 한번에 여러개의 요청이 들어왔을때 요청의 개수만큼 객체가 생성될 우려가 있으므로 Singleton을 보장해야한다클래스 외부에서의 생성자 접근을 private으로 막고 static으

실제 작업의 주체가 되는 인스턴스에 접근하지않고 중간에서 대신 실행해주는 디자인패턴이다즉, 인스턴스 생성시점을 늦추거나 사전작업등의 처리가 가능하다이 패턴을 적용함으로써 얻는 이점은 다음과 같다인스턴스의 생성시점을 조절하여 자원낭비를 줄일 수 있다특정 클라이언트만 실제

여러 개의 원소를 다루는 자료구조는 List, Array, Map 등 여러가지 종류가 존재한다.이 컬렉션, 컨테이너, 어그리게이터 등으로 불리는데 각 종류별로 원소를 조작하는데 사용되는 명령이 다르다.예를들어, ArrayList의 경우 데이터를 삽입하는데 add, 삭제

출근을 위해 목적지까지 도달하는 방법에는 여러가지 방법이 존재한다.걸어서 가거나, 자전거를 타거나, 대중교통을 이용하거나, 자가용을 이용하는 방법 등 다양할 것이다.출발지에서 도착지까지 이동한다는 기능의 단위에서 여러가지 전략을 선택할 수 있고, 출근이라는 기능안에 여

최근 IKEA에서 조립형 책상을 구매했던 경험이 있다.동봉된 설계도를 보면서 책상조립을 했기에 조립에 어려움은 없었던 기억이 있다.클래스의 세계에서도 이와 유사한 경험을 할 수 있다.예를들어, 다른 클래스를 상속하여 구현하는 상황을 생각해보자.현재 클래스의 목적에 맞게

마트에 방문하면 다양한 상품들이 존재한다.필요한 상품들을 바구니에 담고나서 계산을 하기 위해 바코드를 찍으면 각 상품들에 해당하는 가격이 출력된다.이렇듯 마트라는 거대한 집합체 내의 상품들은 바코드를 찍는다는 동일한 행동에 대해 각 객체별 결과를 출력해낸다.여기서 동일

해외여행으로 일본을 가려고 계획 중이라면 휴대폰 충전을 위해 어댑터를 챙기게 된다.한국의 정격 전압은 220V지만 일본은 110V이기 때문에 한국에서 사용하는 충전기를 그대로 사용할 수 없기 때문이다.이를 위해 구입하는게 흔히들 돼지코라고 부르는 어댑터다.한국에서 사용

OOP의 주요 특징인 추상화와 상속을 이용하면 다른 클래스 또는 인터페이스의 기능을 가져오는게 가능하다.즉, 현재 클래스에 기능을 직접 정의하지 않고도 다른 클래스에 정의된 기능을 가져오는게 가능하다.Bridge 패턴은 OOP 특성을 이용하여 하나의 클래스 계층구조를

객체의 필드들은 사실 내부의 불변 데이터와 외부의 가변 데이터로 구분된다.객체 생성시점 이전에 이미 정해진 데이터와 객체 생성 시에 주어지는 데이터로 나뉘지는 것이다.만약, 클래스의 객체를 다수 생성한다면 메모리사용량이 빠르게 치솟을 것이다.프로그램 내의 메모리 사용량

메일이나 알림기능을 생각해보면 사용자의 동작( 요청 )에 의한 것이 아닌, 외부의 상태변화에 따라 동작이 발생한다.즉, 사용자가 아무런 동작을 하지않았어도 타인이 메일을 전송하면 사용자에게 메일 알림이 오는 것이다.옵저버패턴은 이와 관련된 패턴으로 발행자와 구독자로 구

애플리케이션에 클래스가 많아지면 클래스간의 관계도 증가한다. 적절한 수준에서는 괜찮지만 수가 많아질수록 복잡도가 증가하기 때문에 새로 생긴 클래스와 기존 클래스간 관계를 형성하기 위해 많은 클래스들을 돌아다녀야 한다.이렇게 클래스 간의 관계에 의한 복잡도를 완화하기 위

게임의 롤백이나 Ctrl+Z 처럼 작업을 진행하다보면 실수나 특정 의도에 의해 이전 상태를 복구해야하는 경우가 생긴다.이를 구현하기 위해서는 객체의 현재상태를 기록하는 스냅샷을 따로 관리해야한다.스냅샷 생성을 위해서는 필드들의 현재상태를 파악해야 하는데, private

기존 클래스의 기능을 확장하기 위해 사용되는 보편적인 방식은 상속에 의한 확장이다. 공통되는 작업을 하는 부분을 인터페이스나 상위 클래스로 추출해내고, 세부작업은 하위 클래스에 작성하는 방식이다.상속에 의한 확장은 손쉽게 구현할 수 있지만, 기능의 수 만큼 하위클래스가

최근 Spring Security를 학습하면서 필터체인 기반의 동작방식을 확인할 수 있었다.여러개의 필터가 순서대로 동작하면서 자신의 작업에 해당되는 경우, 자신이 처리하고 다음 필터로 요청을 넘기는 방식으로 동작했다.이렇듯 사용자 인증, 인가, 검증 필터들을 거친 뒤

라이브러리나 프레임워크를 사용하면 관련 객체를 생성하고, 이를 관리하게 된다.직접 작성한 코드가 아니기때문에 문서를 확인해가며 종속성을 관리하고 실행순서를 조정해야한다.이러한 코드들이 내 애플리케이션의 코드들에 추가되다보면 점차 복잡해지고, 동일한 유형의 작업에도 반복

HTTP요청은 요청자와 처리자가 구분되어있다.요청정보를 포함한 객체를 요청자에서 처리자로 전송하면 이를 처리하고, 응답을 반환하는 식으로 동작한다.이는 중복되는 코드작성을 막아주므로 요청자의 코드관리에 도움이 되는 방식이다.커맨드 패턴도 이와 유사하게 동작한다.하나의

어릴 적, 디지몬이라는 만화를 즐겨봤던 기억이 있다.아구몬, 파피몬 등 다양한 디지몬들이 파트너와 함께 성장해가며 탐험하는 내용으로 기억한다.디지몬의 핵심적인 특징은 "진화" 였다.진화를 통해 아구몬 -> 그레이몬 -> 메탈그레이몬 -> 워그레몬 순서대로 변화되며, 각

이미 잘 구현된 클래스 구조에 공통적인 기능을 추가하려면 어떻게 해야할까?모든 클래스들에 완벽하게 공통적인 기능이라면 최상위 클래스나 인터페이스에 기본동작을 정의하면 될 것이다하지만, 세부동작이 상이한 경우에는 하위클래스 각각에 재정의 등을 통해서 메서드를 작성해야 한