관찰과 질문, 그리고 데이터

Facade Facade 패턴은 '하위 시스템을 보다 쉽게 사용할 수 있게 해주는 인터페이스를 정의하는 것' Adapter 패턴과 거의 같은 방식으로 작동하지만, 목적이 다르다. Adapter : 원래 코드를 다른 코드와 작동할 수 있도록 하는 Wrapper를 제공 Facade : 원래 코드를 더 쉽게 처리할 수 있는 Wrapper를 제공 객체나 클래스, 인터페이스가 복잡할 경우, 쉽게 사용할 수 있도록 프론트 인터페이스를 제공하는 형태. 캡슐화되지 않은 코드를 처리할 때 / 원하는 코드를 다시 작성할 수 없을 때 주로 사용한다. 단, 원래의 클래스, 인터페이스 코드가 변경될 경우 Facade 패턴도 변경해야 한다. 패턴의 특징 여러 복잡한 클래스를 하나로 간주해서 편하게 다루는 방법 따라..

Strategy 패턴 여러 알고리즘을 하나의 추상적인 접근점 (인터페이스)을 만들어서, 인터페이스에서 알고리즘이 서로 교환 가능하도록 하는 패턴. 동일한 목적의 알고리즘 여러 개 중 특정 알고리즘을 선택해야 할 때. 인터페이스는 '기능의 선언 (구현부와 분리)' 역할을 담당. 하나의 인터페이스로 여러 가지 기능을 구현하기 위한 단일 통로를 생성하는 것. ex) 워드에서 프린터 명령어 -> 어느 기종의 프린터를 사용하건 상관없이 프린트 명령어가 실행됨 기능 위임 (Delegation) 예시코드. // AObject : 객체 정의. 이 객체에서 수행할 기능을 인터페이스에 위임하는 방식 public class AObject { BInterface bInterface; // 객체 생성 시, 기능을..

Bridge 두 가지 개념을 먼저 정리해야 한다. 기능 클래스 계층. = 새로운 기능을 추가하고 싶은 경우 구현 클래스 계층. = 새로운 구현을 추가하고 싶은 경우 즉, 클래스를 생성할 때 생성의도를 먼저 고민해야 한다. 기능을 추가할 것인가? 구현을 추가할 것인가? public interface IRobot { void powerOn(); void powerOff(); } public class RobotModel1 implements IRobot { @Override public void powerOn() { System.out.println("type1 : power on"); } @Override public void powerOff() { System.out.println("type1 : pow..

Decorator 객체 결합으로 기능을 동적으로 유연하게 확장할 수 있게 하는 패턴. 기본 기능에 추가할 수 있는 기능 종류가 많은 경우, 각 추가 기능을 Decorator 클래스로 정의한 뒤 필요한 Decorator 객체를 조합하는 식으로 설계함 상속을 통해 확장할 수도 있지만, 디자인 유연성 면에서 상속은 비추천 기존 코드를 수정하지 않고도 확장할 수 있도록 Decorator 패턴 사용 ex) 자바 입출력의 Filter Stream 기능. 단점 자잘한 객체가 많이 추가되므로, Decorator 패턴을 너무 많이 사용할 경우 코드가 필요 이상으로 복잡해질 수 있다. Component를 초기화하기 위한 코드가 복잡해진다. Decorator로 Wrapping해야 하는 경우가 종종 생김. 따라서 보통 Fac..

Adapter Pattern 한 클래스의 인터페이스를, 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환하는 역할. 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스를 연결하는 역할. 이미 제공되어 있는 것 / 필요한 것 사이의 차이를 없앤다고 보면 된다 Wrapper 패턴이라고도 불림. 다른 용도로 사용할 수 있도록 변경해주는 개념 두 가지 종류가 있다. Class 기반 Adapter (상속을 사용한 방법) Instance 기반 Adapter (위임을 사용한 방법) 기존의 클래스를 개조해서 필요한 클래스를 생성하는 방법. 일반적으로 기존의 클래스 == "잘 만들어졌고, 버그가 발생하지 않는다는 걸 오랜 시간 사용하며 증명한 코드". 이 클래스를 더 많은 곳에서 다양한 방식으로 사용하기 위해 고..

Observer 패턴 한 객체의 상태가 바뀌면, 해당 객체에 의존하는 다른 모든 객체에게 notice 전송 + 자동으로 내용이 갱신되는 one to many 방식의 의존성을 정의한 객체. Subject 객체의 bCheck 변수 - 해당 객체가 변경되었는지 여부를 알리는 boolean. bCheck가 false이면, Subject 객체에 의존하는 Observer 객체에게 값 변경이 있음을 알린다. Observer 객체는 update() 메소드로 Subject값이 어떻게 변경되었는지 확인하고, 변경된 값에 대응되는 메소드를 실행한다. 자바의 Observer 내장패턴 사용하기 Push방식, Pull방식 모두 사용가능함. java.util.Observer 인터페이스 구현 후 Observable 객체의 addOb..

Builder 패턴 객체 생성 시 흔히 사용되는 패턴. Dot chain 문법이라고도 부른다. 빌더 패턴을 다루는 두 가지 설명 GoF Design Pattern: 객체의 생성 / 조립 방법을 분리할 목적 Effective Java의 builder Pattern GoF의 패턴보다는 좀 더 코딩위주의 활용법. 코드 가독성 / 유지보수성을 위해 빌더 패턴을 권장함 객체 일관성, 불변성 (변경불가능) 등의 특징을 강조 규칙, 생성자 인자가 많을 경우 builder 패턴을 권장하는 편. effecitve java의 builder pattern은 깔끔하고 유연하게 객체를 생성하기 위한 기법. @Getter @Setter @AllArgsConstructor // 생성자에서 특정 필드만 제거한 채 구현하려면, 그만큼..

FlyWeight 패턴 생성 비용이 큰 객체를 공통으로 사용할 수 있도록 만드는 패턴. 중복 생성될 가능성이 높은 객체 동일한 리소스가 자주 사용될 가능성이 높다는 의미이므로, 공통자원 형태로 관리하는 편이 효율적이다 생성비용은 크지만 사용빈도는 낮은 객체 이런 경우 매리 객체를 생성해두는 건 낭비. 요청이 있을 때에만 생성해서 제공한다. FlyWeight 패턴은 위 두 가지 목적을 위해 존재함. 객체 생성을 담당하는 Factory 역할과 객체 관리 역할을 분리하는 편이 유용한 경우도 있으나, 일반적으로는 역할의 크기가 크게 다르지 않으므로 하나의 클래스 안에 있어도 무방하다. 장점 많은 객체를 생성할 때 생성시간 / 메모리소모를 줄일 수 있음 state pattern과 결합이 용이함 단점 개별 설정이 ..

SingleTon 객체가 많아지면 리소스 사용이 많아지고, 리소스가 많으면 프로그램 전체 속도가 떨어진다. -> 생성할 수 있는 객체의 최대 개수를 제한할 필요가 생김 Singleton 패턴: 객체 생성을 단 한번만 허용하는 패턴. 객체의 생성개수 제한이라는 조건이, 객체를 활용하려는 쪽에서 일일이 신경쓰지 않아도 되도록 하는 게 핵심. 용례 DB Connection Pool Log Writer ... @Getter public class Database { private static Database singleton; private String name; // getInstance()로 객체 불러오기. // 객체가 없을 경우 singleton 변수에 새 인스턴스를 할당하고, // 있으면 해당 객체를 그..