White Whale Studio

싱글톤 패턴은 하나의 Class 에 하나의 Instance를 가지는 패턴입니다. 개인적으로 가장 이해하기 쉬웠던 예는 TraceManager의 예제였습니다. 에러나 프로세스 정보를 기록하기위해서 사용하는 TraceManager는 다양한 클래스에서 참조할 것이고 참조할 때마다 객체를 생성해서 사용 해야만 한다면 분명히 자원을 많이 잡아먹게 될것입니다. 이러한 경우에 TraceManager를 구현 시에 싱글톤 패턴으로 구현을 하면 될것 같군요. 구현 후에는 프로그램 구동 후 종료가 될때까지 TraceManager의 1개의 인스턴스로 로깅을 남길 수 있습니다. 객체 중에서 하나 이상 존재하게 되는 경우 프로그램에 문제가 될수있다거나 자원을 많이 잡아먹을 가능성이 있는 다른 예를 들어보면, 대화상자나 사용자 설..

SOLID 원칙 중 2번째인 개방 폐쇄 원칙입니다. OCP : Open Closed Principle 이 원칙은 다음과 같습니다. - 기능을 변경하거나 확장은 할 수 있으면서 - 그 기능을 사용하는 코드는 수정하지 않는다. 첨엔 이게 뭔 소린가 싶습니다. 풀이를 해보면 Entity(클래스, 메서드, 모듈 등)는 Interface와 같은 추상화 클래스에 대해 개방 되어 있어야 하지만변경에는 폐쇄되어 있어야 한다는 말입니다. 즉, Interface를 통해 기능을 변경하거나 확장을 하는 것은 가능하나, 외부에서 참조하는 코드는 수정하지 않는다는 것입니다. 아래의 그림에서 보시면 Interface를참조하는 Plus, Minus의 메서드가 있는데, 이러한 메서드에 추가적으로 곱하기나 나누기가 기능이 추가가 되야 ..

SOLID 설계 원칙은 객체 지향 프로그래밍을 할 때 중요한 원칙들입니다. 단일 책임 원칙 : Single Responsibility Principle - SRP 개방 폐쇄 원칙 : Open-Closed Principle - OCP 리스코프 치환 원칙 : Liskov Substitution Principle - LSP 인터페이스 분리 원칙 : Interface Segregation Principle - ISP 의존역전 원칙 : Dependency Inversion Principle - DIP 위에서 보시는 바와 같이 총 5개의 원칙들의 앞 자만을 따서 SOLID라고 합니다.각 원칙들에 대해서 찬찬히 살펴보겠습니다. 우선 해당 포스팅에서는 단일 책인 원칙에 대해서 살펴보겠습니다.단일 책임원칙은 다음과 같습..

Facade Pattern 파사드, 퍼사드, 파사아드 등등 Facade 는 정면, 앞면, 표면을 뜻합니다. 은닉성을 표현한 패턴이라고도 하더군요. 개념상으로 은닉성과 의미를 같이하며 하위 메서드들을 숨기고 표면에 나서서 다른 요청 메서드들에게 기능을 제공한다고 보시면 되겠습니다. 위에서 보시는 클래스 다이어그램을 예시로 살펴보겠습니다. 주제는 다른 블로그에서 Facade 패턴을 설명하면서 예시를 든 내용인데 제가 이해하는 과정에서 설명을 더했습니다.SmartManager는 그림상으로는 일반 클래스입니다만, 다이어그램을 그리기 위해서 표현한 것이고 실제로는 추상화합니다. (인터페이스) 우선 기본 데이터인 PictureItem이 있고해당 객체에 직접 접근하는 PictureManager와 Compensator..

이 패턴은 처음에는 이해하기가 난해했던 패턴입니다. 객체에 추가적인 요건을 동적으로 첨가합니다.데코레이터는 서브 클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공합니다.라고 하는데 이름에서 어느정도 유추를 할 수 있는것처럼 Decorate : 꾸미다. 장식하다. 라는 의미를 가집니다. 즉, 특정 객체가 있으면 데코레이터를 통해 기능을 추가하는(장식하는) 것이 가능합니다.위임/상속으로 구현되어 감싸는 데코레이터의 개수에는 제한이 없습니다. 간단한 예를 들어볼까요.크리스마스가 되면 집집마다 분위기를 내기 위해 크리스마스 트리를 장식합니다.이 크리스마스 트리를 장식하는 것을 빗대어 보면 객체는 크리스마스 트리, 데코레이터는 트리에 장식을 달기 위한 규칙(추상 클래스), 트리에 달기 위한..

객체지향 개발을 위해서는 캡슐화를 잘 하라고 합니다. 캡슐화는 내부적으로 기능 구현을 어떻게 한건지 숨기는 것을 말합니다.메서드 내부에 기능구현이 변경되더라도 해당 메서드를 호출하는 코드에서는 영향을 받지 않도록 또는 최소화하기 위함입니다. 절차지향적 구현방법과 객체지향적 방법으로 살펴보겠습니다. 123456789101112 // 절차지향 // item.getExpiryDate() => 만료 일자 데이터를 가져옴 if (item.getExpiryDate() != null && item.getExpiryDate().getDate()

템플릿 메서드 패턴은1. 실행 과정을 구현한 상위 클래스2. 실행 과정의 일부 단계를 구현한 하위 클래스로 구성됩니다. 1.번의 상위 클래스는 기능 구현 시 필요한 각 단계를 정의하며, 일부는 추상 메서드로 구성됩니다.이 추상 메서드는 하위클래스에서 구현됩니다. 간단하게 그림으로 살펴보면, 요런 모양이 되겠네요. 정리 해보면,상위 클래스는 공통기능을 구현한 템플릿 메서드와 하위 클래스에서 개별적으로 기능 구현을 할 수 있도록 규약을 지정하는 추상 메서드로 구성이 됩니다.하위 클래스는 이 상위 클래스를 상속받아서 공통기능인 템플릿 메서드는 상위 클래스의 흐름을 따르고 하위 클래스에서 개별적으로 작성해야하는 추상 메서드의 실제 구현을 수행하게 되겠네요.우선 예제로 음료를 만드는 과정으로 해당 패턴을 살펴볼까..

전략 패턴의 중점- 알고리즘을 추상화 -> 전략(Strategy) - 알고리즘을 사용하는 책임을 가지고 있는 콘텍스트(Context)에서 알고리즘(전략)을 분리하는 설계방법- 흐름 : Client가 전략을 고른다.(어떤 전략을 쓸까나~) → 선택된 전략을 Dependency Injection으로 Context에 넘겨준다. → Context는 전달받은 전략으로 초기화하여 필요한 자원(프로퍼티, 메서드 등)을 사용한다. 전략 패턴을 사용해서 콘텍스트 코드의 변경없이 새로운 전략을 추가, 수정이 용이하다는 점이다.필요한 전략을 직접 선택해서 Context에 넘겨주기 때문에 Context에서는 전략과 관련된 부분에서는 코드를 수정하는 수고를 하지 않아도 되는 것이다.주로 if-else를 사용하면서도 비스무리한 ..