AJAX가 뭘까요? 

AJAX는 Asynchronous Javascript And Xml의 약자입니다.

이름에서 알 수 있듯이 비동기식 자바스크립트와 XML을 말합니다. 

이름에 XML이 나오기는 하지만 XML을 알 필요는 없습니다.  

AJAX를 사용하기 위해서는 기본적으로 HTML과 Javascript를 알고있어야 합니다.

그럼 가장먼저 AJAX가 어떻게 동작하는지에 대해서 알아보도록 할까요?

AJAX는 아래와 같은 순서를 거칩니다.

1. 클라이언트(IE 7+, 크롬, 사파리, 파이어폭스, etc. )에서 XMLHttpRequest객체를 생성하고 메시지를 담아 서버로 보낸다.

2. 서버에서 메시지를 받으면 메시지에 해당하는 정보를 읽어서 다시 브라우저한테 응답해준다.

3. 클라이언트 브라우저가 서버로부터 응답을 받으면 해당 정보를 특정 영역에 refresh해준다.

AJAX를 사용함에 있어서 가장 기본은 XMLHttpRequest 객체입니다. 이 객체는 서버로부터 데이터를 전송받을 때 사용이 됩니다. ( IE 5, 6 버전에서는 ActiveXObject 라는 객체가 사용됩니다. )

그럼 이 객체를 어떻게 만드는지 예제를 통해서 알아보겠습니다.

자, 이제 객체를 생성했으니까 이 객체를 이용해서 메시지를 서버로 전송해야겠죠?

다음 포스팅에서 서버로 메시지를 전송해보도록 하겠습니다.

이클립스 사용시 웹앱 프로젝트를 처음 만들면 이 에러를 볼 수 있습니다.

이 에러는 서블릿 클래스가 클래스 빌드패스에 잡혀있지 않아서 발생하는 문제입니다.

아래와 같이 해결하시면 됩니다.

안녕하세요~ 이번에는 CSS에 대해서 알아볼텐데요~

CSS가 뭔지를 알려면 뭐의 약자인지부터 알아봐야 겠죠?

CSS는 Cascading Style Sheets의 약자입니다. 캐스케이딩 스타일 시트. 스타일이라는 단어라 들어갔으니 뭔가 스타일링하기위한 어떤거라고 생각해볼 수 있으려나요?  

CSS는 html태그내의 속성값들을 따로 분리해서 저장해놓기 위해서 사용이 됩니다.

왜 따로 저장해놓을까요??

여러 페이지에서 적용이 되야하는 스타일값들을 분리해서 저장해놓고 여러 페이지에서 그냥 호출해서 사용하기 때문에 재사용성이 높아지고 똑같은 속성을 타이핑해야하는 수고도 덜 수 있으며 시간도 단축될 것이고 유지보수도 쉬워지겠죠?

그래서 점점 html내의 속성들이 사라지고 대신 CSS를 이용하는 것이 표준이 될거라는 말도 있습니다.

(2020년 현재 이미 그렇게 되어버렸습니다. html 내에 inline style을 정의해서 쓰는 일은 거의 없죠)

그러면 기본적인 문법을 여기서 한번 짚고 넘어가볼까요??

에이 그냥 다음에 알아보기로 하죠 ㅋㅋ

기본적으로 오라클에는 특수기호에 대해서 검사를 하고 대체할 수 있도록 정의를 해놓은 것이 있는데 이 중에 특수기호 '&'도 포함이 되어있다. 

따라서 insert into table1 values ( 'a & b'); 라는 문장을 실행하면 SQLDeveloper에서는 대체문자를 설정하라고 팝업창이 뜬다.

처음에는 이게 뭐지? 하고서 그냥 엔터를 쳤었는데 나중에 보니 그렇게 엔터쳤던 것 때문에 insert할 때 &가 공백으로 바뀌어져서 내용이 들어가있었다.

그런데 이렇게 특수기호가 들어간 문장을 수 백개 insert해야 한다면....???

일일히 다 대체문자를 입력할 수가 없다!!!

이럴 때 유용하게 쓸 수 있는게

SQL> set define off;

이다.

위 명령어는 현재 세션에 대해서 "특수기호 대체 검사"를 하지 않도록 해준다. 

How to increase the number of processes at database level in Oracle?

1.  Log on to the database as system administrator

•  In SQL Plus enter: "connect / as sysdba"

2. Set the number of processes to be desired value <num_processes>

• In SQL Plus "alter system set processes=<num_processes> scope=spfile"

3. Shutdown the database

• In SQL Plus "shutdown immediate"

4. Startup the database 

• In SQL Plus "startup"

5. Check the changes have taken effect.

• In SQL Plus "show parameter sessions" and "show parameter processes"

​출처 : http://knowledgebase.progress.com/articles/Article/P164971

CentOS 6에 오라클 11g 설치시에 설정해주는 커널 파라미터 의미

ㅇ 커널 파라미터 설정

/etc/sysctl.conf 파일

fs.aio-max-nr = 1048576
fs.file-max = 6815744
#kernel.shmall = 2097152
#kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576

아래 링크를 참조하시길 바랍니다.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html-single/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/#sect-Oracle_9i_and_10g_Tuning_Guide-Setting_Semaphores-Setting_Semaphore_Parameters

Red Hat Enterprise Linux Oracle Tuning Guide

access.redhat.com

https://docs.oracle.com/cd/E11882_01/install.112/e24326/toc.htm#BHCCADGD

Oracle® Database Quick Installation Guide

docs.oracle.com

select 

owner, segment_name, segment_type, sum(bytes)/1024/1024 as MB

from 

dba_segments

where

owner='{username in uppercase}' 

group by owner, segment_name, segment_type order by MB

요새는 거의 쓰이지 않고있는 Dos 명령어를 쓸 일이 있어서 구글링해서 썼는데 기록으로 남겨봅니다.

아래 명령어는

1. dir명령어를 이용해서 C: 드라이브 하위에 있는 디렉토리 목록을 뽑은 뒤

2. findstr을 이용해서 \bin\ 디렉토리를 포함하는 목록만 추출한 뒤에

3. .svn 으로 디렉토리명이 시작하는 것들은 제외시키고

4. 그렇게 뽑은 명령어를 auxclasspath.txt파일로 저장

을 하는 명령어입니다. 

조금만 바꾸면 여러분들이 원하는 파일만 추출이 가능합니다.

C:\> dir /a:d /s/b | findstr "\\bin\\" | findstr /v /i "\.svn" > auxclasspath.txt

하나씩 뜯어볼까요?

1) dir /a:d /s/b

- 현재 디렉토리 하위의 디렉토리를 출력합니다.

2) findstr "\\bin\\"

- 하위 디렉토리 중에 bin 이라는 이름을 가진 디렉토리를 포함하고있는 경로만 뽑아냅니다.

( 이 명령어가 실제로 하는 일은 특정 스트링을 찾는 것입니다. )

3) findstr /v /i "\.svn"  

- 위 디렉토리 중 .svn 으로 디렉토리명이 시작하는 목록은 제외시키고 출력합니다.

4) > auxclasspath.txt

- 지금까지 나온 목록을 auxclasspath.txt 파일로 저장합니다.

dir 명령어 문법 및 옵션 보기

findStr 명령어 문법 및 옵션 보기

Creational Patterns ( 생성 패턴 )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다. 

 Structural Patterns ( 구조적 패턴 )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

구조적 패턴들은 클래스와 객체의 구성에 관여한다.

 Behavioral Patterns ( 행위적 패턴 )

These design patterns are specifically concerned with communication between objects.

이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.

오늘 살펴볼  Interpreter 패턴은 Behavioral 패턴에 속합니다. 

Interpreter Pattern Structure

패턴의 목적 ( Intent ) :  

패턴이 나오게 된 동기 ( Motivation ) :

   
A class of problems occurs repeatedly in a well-defined and well-understood domain. If the domain were characterized with a "language", then problems could be easily solved with an interpretation "engine".

GoF의 디자인 패턴에서는 아래와 같은 예제가 나옵니다.

expression ::= literal | alternation | sequence | repetition |
                   '(' expression ')'

유용성 ( Applicability ) :

등장 인물 ( Participants ) :

원리 ( Collaborations ) :  

관련 패턴들 :  

• Considered in its most general form (i.e. an operation distributed over a class hierarchy based on the Composite pattern), nearly every use of the Composite pattern will also contain the Interpreter pattern. But the Interpreter pattern should be reserved for those cases in which you want to think of this class hierarchy as defining a language.
• Interpreter can use State to define parsing contexts.
• The abstract syntax tree of Interpreter is a Composite (therefore Iterator and Visitor are also applicable).
• Terminal symbols within Interpreter's abstract syntax tree can be shared with Flyweight.
• The pattern doesn't address parsing. When the grammar is very complex, other techniques (such as a parser) are more appropriate.

출처 :  http://sourcemaking.com/design_patterns/interpreter

Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )  

Creational Patterns ( 생성 패턴 )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다. 

 Structural Patterns ( 구조적 패턴 )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

구조적 패턴들은 클래스와 객체의 구성에 관여한다.

 Behavioral Patterns ( 행위적 패턴 )

These design patterns are specifically concerned with communication between objects.

이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.

오늘 살펴볼  Observer 패턴은 Behavioral 패턴에 속합니다. 

옵저버라고 하니까 10년전에 스타크래프트에서 나왔던 옵저버가 생각이 나네요. cloaking상태로 여기저기 맵을 뒤지고 다녔던 녀석이죠. HP는 어찌나 적은지 한방에 그냥 펑 터져서 죽어버리던 녀석이었죠 ㅎㅎ.

이 옵저버 패턴은 한 객체의 상태를 지켜보고 있다가 이 객체의 상태가 변경이 되면 이 객체의 상태에 의존적인 다른 객체들의 상태를 자동으로 업데이트할 수 있게끔 해주는 패턴이라고 합니다.  

아래에서 좀 더 자세히 알아보도록 하겠습니다.

Observer Pattern Structure

패턴의 목적 ( Intent ) :  

패턴이 나오게 된 동기 ( Motivation ) :

유용성 ( Applicability ) :

등장 인물 ( Participants ) :

추가 정보 :       

• Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Chain of Responsibility passes a sender request along a chain of potential receivers. Command normally specifies a sender-receiver connection with a subclass. Mediator has senders and receivers reference each other indirectly. Observer defines a very decoupled interface that allows for multiple receivers to be configured at run-time.
• Mediator and Observer are competing patterns. The difference between them is that Observer distributes communication by introducing "observer" and "subject" objects, whereas a Mediator object encapsulates the communication between other objects. We've found it easier to make reusable Observers and Subjects than to make reusable Mediators.
• On the other hand, Mediator can leverage Observer for dynamically registering colleagues and communicating with them.

출처 :  http://sourcemaking.com/design_patterns/observer

Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )    

Creational Patterns ( 생성 패턴 )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다. 

 Structural Patterns ( 구조적 패턴 )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

구조적 패턴들은 클래스와 객체의 구성에 관여한다.

 Behavioral Patterns ( 행위적 패턴 )

These design patterns are specifically concerned with communication between objects.

이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.

오늘 살펴볼  Mediator 패턴은 Behavioral 패턴에 속합니다. 

Mediator Pattern Structure

패턴의 목적 ( Intent ) :  

패턴이 나오게 된 동기 ( Motivation ) :

    We want to design reusable components, but dependencies between the potentially reusable pieces demonstrates the "spaghetti code" phenomenon. 개발자들은 보통 재사용 가능한 컴포넌트들을 만들고 싶어하지만 잠재적으로 재사용가능한 코드들의 의존성이 일명 "스파게티 코드"를 발생시키게 됩니다. 스파게티 코드라는 것은 거미줄처럼 뒤죽박죽 의존성이 존재하는 것을 의미합니다.

유닉스나 리눅스 시스템에 있는 사용자 퍼미션 시스템을 예로 들어보겠습니다. 한 사용자는 여러 그룹에 속해있을 수 있으며 한 그룹은 여러 사용자를 가질 수 있습니다. 아래 그림 처럼 말이죠. 

위 시스템을 구현한다고 해보자구요. 그럼 User 객체들과 Group객체들 사이에 연결고리가 있겠죠? 그 연결고리 때문에 User객체나 Group객체가 변경될 때 서로 영향을 미치게 될겁니다. 그러면 둘 사이의 관계만을 정의하는 객체를 따로 만들면 어떨 까요? User객체나 Group객체가 변경되어도 서로에게 영향을 미치게 될 일이 사라지게 됩니다. 또한, 수많은 관계들을 쉽게 관리할 수 있게 될 뿐아니라 수정하는 일도 쉬워질 겁니다. 

여기서 관계를 정의하는 객체를 중재자 객체라고 생각할 수 있습니다. 중재자 객체는 다음 역할들을 수행합니다. 

1. encapsulates all interconnections
2. acts as the hub of communication
3. is responsible for controlling and coordinating the interactions of its clients
4. promotes loose coupling by keeping objects from referring to each other explicitly

유용성 ( Applicability ) :

등장 인물 ( Participants ) :

추가 정보 :      

• Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Chain of Responsibility passes a sender request along a chain of potential receivers. Command normally specifies a sender-receiver connection with a subclass. Mediator has senders and receivers reference each other indirectly. Observer defines a very decoupled interface that allows for multiple receivers to be configured at run-time.
• Mediator and Observer are competing patterns. The difference between them is that Observer distributes communication by introducing "observer" and "subject" objects, whereas a Mediator object encapsulates the communication between other objects. We've found it easier to make reusable Observers and Subjects than to make reusable Mediators.
• On the other hand, Mediator can leverage Observer for dynamically registering colleagues and communicating with them.
• Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely "adds value", and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn't add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

출처 :  http://sourcemaking.com/design_patterns/mediator

Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )   

디자인 패턴에 대해서 한번 훑어보긴 했었는데 다시한번 복습하는 차원에서 하나하나 정리하는 시간을 갖고 싶었다. 그리고 오늘은 그 첫째 날.

오 늘 함께 볼 디자인패턴은 Iterator 패턴이다. 내용의 대부분은 GoF의 디자인패턴 책에서 발췌를 하게될 것임을 밝힌다. 그리고 영문을 한글로 번역을 하게 될텐데 전문번역가가 아니므로 한글 번역본이 이해가 안간다고 느끼면 영문 원본을 읽어보시길 권유한다.

그럼 시작해 볼까?

우선 GoF의 디자인 패턴은 아래와 같이 크게 3가지 종류로 분류된다.

 Creational Patterns ( 생성 패턴 )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다. 

 Structural Patterns ( 구조적 패턴 )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

구조적 패턴들은 클래스와 객체의 구성에 관여한다.

 Behavioral Patterns ( 행위적 패턴 )

These design patterns are specifically concerned with communication between objects.

이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.

이제 살펴볼 Iterator 패턴은 Behavioral 패턴에 속한다. 

Iterator는 자바의 Iterator와 같은 것을 말한다. 사전적 의미로 "반복자"라고 불리는 iterator는 자바의 경우 collection객체에서 사용이 된다. 오라클에서 제공하는 Iterator에 대한 정보는 이곳에서 확인하면된다. 이처럼 앞으로 살펴볼 모든 패턴들은 그 이름에서 이 패턴이 어떤 패턴인지 파악할 수가 있다.

Iterator Pattern Structure

패턴의 목적 :
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Iterator 패턴의 목적은 aggregate object ( ex. List )를 순차적으로 액세스 할 수 있는 방법을 제공하는 것이다. 물론 이 과정에서 개발자는 object가 어떤식으로 구현이 되어있는지는 알 필요가 없으므로 object의 구현부를 노출시키지 않는다.

유용성 ( Applicability ) :

· to access an aggregate object's contents without exposing its internal representation.

내부 구현을 노출시키지 않으면서 집약 객체의 내용물에 접근하고자 할 때
· to support multiple traversals of aggregate objects.

집약(집합) 객체들에 대해 다양한 탐색경로(?)를 지원하고자 할 때
· to provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration).

다른 집약(집합)구조들을 탐색하기위한 통일된 인터페이스를 제공하고자 할 때 (즉, 다형적 iteration을 지원하고자 할 때 )

등장 인물 :
· Iterator
o defines an interface for accessing and traversing elements.
· ConcreteIterator
o implements the Iterator interface.
o keeps track of the current position in the traversal of the aggregate.
· Aggregate
o defines an interface for creating an Iterator object.
· ConcreteAggregate
o implements the Iterator creation interface to return an instance of the proper ConcreteIterator.

장단점 :
1. It supports variations in the traversal of an aggregate.Complex aggregates
may be traversed in many ways. For example, code generation and semantic checking involve traversing parse trees. Code generation may traverse the parse tree inorder or preorder.Iterators make it easy to change the traversal algorithm: Just replace the iterator instance with a different
one. You can also define Iterator subclasses to support new traversals.
2. Iterators simplify the Aggregate interface.Iterator's traversal interface obviates the need for a similar interface in Aggregate, thereby simplifying the aggregate's interface.
3. More than one traversal can be pending on an aggregate.An iterator keeps track of its own traversal state. Therefore you can have more than one traversal in progress at once.

관련 패턴들 : 

Composite : Iterators are often applied to recursive structures such as Composites.
Factory Method : Polymorphic iterators rely on factory methods to instantiate theappropriate Iterator subclass.
Memento is often used in conjunction with the Iterator pattern. An iterator can use a memento to capture the state of an iteration. The iterator stores the memento internally. 

출처 : Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )

Creational Patterns ( 생성 패턴 )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다. 

 Structural Patterns ( 구조적 패턴 )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

구조적 패턴들은 클래스와 객체의 구성에 관여한다.

 Behavioral Patterns ( 행위적 패턴 )

These design patterns are specifically concerned with communication between objects.

이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.

오늘 살펴볼  Composite 패턴은 Structural 패턴에 속한다.  

Composite Pattern Structure

A typical Composite object structure might look like this:

패턴의 목적 ( Intent ) : 

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

컴 포지트 패턴은 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴으로, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 하는 패턴이다. 따라서, {객체의 그룹}과 {하나의 객체}가 동일한 행위를 할 때 적용되야 하며, 또한 트리구조를 생성할 때 사용될 수 있다. 

패턴이 나오게 된 동기 ( Motivation ) :

그 래픽 툴은 사용자들로 하여금 간단한 컴포넌트 ( ex. 선, 사각형, 문자, 그림 등등 )부터 복잡한 컴포넌트 ( ex. 글씨가 들어간 사각형 )에 이르기까지 간단하게 표현할 수 있도록 해준다. 이를 간단히 구현하자면 각각의 클래스를 정의하는 것이다. Line클래스, Rectangle 클래스를 각각 정의해서 가져다가 쓰면 되는데 단순히 이렇게 구현을 하면 나중에 큰 문제가 발생 할 수 있다. 왜냐하면 프리미티브 객체와 컨테이너 객체를 다르게 다루어야 하기 때문이다. 이게 무슨 소리냐 하면, 그림판에서 하나의 직선을 그었다고 하자. 이 직선은 시작점과 끝점 좌표를 가지고 있는 하나의 객체겠지? 그런데 또다른 직선을 그었다. 두번째 직선 역시 시작점과 끝점 좌표를 가지고 있겠지. 그런데 이 두개를 한꺼번에 저장하려면 두개의 직선 객체를 가지고있는 또다른 wrapper 클래스가 있어야 할 것이다. 그런데 직선이 몇개가 될지 누가 아냐? 그리는 사람이 몇개를 그릴지는 아무도 모르잖아? 그래서 이런 식으로 접근하다가는 평생해도 제대로된 그래픽 툴을 못 만들 것이다. 그래서 나온 것이 바로 이 컴포지트 패턴인 것이다. 아래 다이어그램을 보자.

위 다이어그램은 직선, 사각형, 문자, 그림을 모두 그래픽 객체를 구현하는 클래스로 만들어 버리고 각 그래픽 클래스는 자식으로 그래픽 클래스를 가질 수 있도록 했다. 그래픽 클래스가 그래픽 클래스를 자식으로 갖는다? 이해가 되는가? 예를 들어보자.

내 가 어제 하나의 그림을 그렸다. 이 그림은 사각형과 직선 그리고 문자를 가지고 있다. 그리고 오늘 나는 두번째 그림을 그리면서 어제 그린 그림과 또 다른 선, 사각형을 그려넣었다. 이것을 다이어그램으로 표현한 것이 아래 그림이다.

유용성 ( Applicability ) :

 Use the Composite pattern when
· you want to represent part-whole hierarchies of objects.
· you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.

등장 인물 ( Participants ) :

· Component (Graphic)
o declares the interface for objects in the composition.
o implements default behavior for the interface common to all classes, as appropriate.
o declares an interface for accessing and managing its child components.
o (optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate.
· Leaf (Rectangle, Line, Text, etc.)
o represents leaf objects in the composition. A leaf has no children.
o defines behavior for primitive objects in the composition.
· Composite (Picture) 

o defines behavior for components having children.
o stores child components.
o implements child-related operations in the Component interface.
· Client
o manipulates objects in the composition through the Component interface.

원리 ( Collaborations ) :

패턴 사용의 장단점 ( Consequences ): 

The Composite pattern

· defines class hierarchies consisting of primitive objects and composite objects. Primitive objects can be composed into more complex objects, which in turn can be composed, and so on recursively. Wherever client code expects a primitive object, it can also take a composite object.  

· makes the client simple. Clients can treat composite structures and individual objects uniformly. Clients normally don't know (and shouldn't care) whether they're dealing with a leaf or a composite component. This simplifies client code, because it avoids having to write tag-and-case-statement-style functions over the classes that define the composition.
· makes it easier to add new kinds of components. Newly defined Composite or Leaf subclasses work automatically with existing structures and client code. Clients don't have to be changed for new Component classes.
· can make your design overly general. The disadvantage of making it easy to add new components is that it makes it harder to restrict the components of a composite. Sometimes you want a composite to have only certain components. With Composite, you can't rely on the type system to enforce those constraints for you. You'll have to use run-time checks instead.

관련 패턴들 : 

 Often the component-parent link is used for a Chain of Responsibility.
Decorator is often used with Composite. When decorators and composites are used together, they will usually have a common parent class. So decorators will have to support the Component interface with operations like Add, Remove, and GetChild.
Flyweight lets you share components, but they can no longer refer to their parents.
Iterator can be used to traverse composites.
Visitor localizes operations and behavior that would otherwise be distributed across Composite and Leaf classes.

추가 정보 :

• Composite and Decorator have similar structure diagrams, reflecting the fact that both rely on recursive composition to organize an open-ended number of objects.
• Composite can be traversed with Iterator. Visitor can apply an operation over a Composite. Composite could use Chain of Responsibility to let components access global properties through their parent. It could also use Decorator to override these properties on parts of the composition. It could use Observer to tie one object structure to another and State to let a component change its behavior as its state changes.
• Composite can let you compose a Mediator out of smaller pieces through recursive composition.
• Decorator is designed to let you add responsibilities to objects without subclassing. Composite's focus is not on embellishment but on representation. These intents are distinct but complementary. Consequently, Composite and Decorator are often used in concert.
• Flyweight is often combined with Composite to implement shared leaf nodes.

출처 :  http://sourcemaking.com/design_patterns/composite

Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )  

http://www.journaldev.com/1535/composite-design-pattern-in-java-example-tutorial 

Creational Patterns ( 생성 패턴 )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다. 

 Structural Patterns ( 구조적 패턴 )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

구조적 패턴들은 클래스와 객체의 구성에 관여한다.

 Behavioral Patterns ( 행위적 패턴 )

These design patterns are specifically concerned with communication between objects.

이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.

오늘 살펴볼  Proxy 패턴은 Structural 패턴에 속한다.  

프 록시 패턴은 네트워킹을 공부해본 사람이라면 이해하기가 쉬울 것이다. 프록시가 뭔지를 알테니까 말이다. 여기서 말하는 프록시란 프록시 서버에서 말하는 그것과 동일한 개념이다. 일종의 중간연결자 역할을 하는 클래스를 만들어서, 요청이 들어오면 최초 요청일 경우 새로 생성하고 생성된 객체를 응답으로 보내고, 두번째 요청부터는 기존에 생성했던 것을 응답으로 보내는 것이다.

이해가 잘 안간다면 좀 더 자세히 알아보자. 

Proxy Pattern Structure

우선 이 클래스 다이어그램부터 이해를 해보도록 하자. 여기서 중요한 것은 RealSubject와 Proxy 그리고 Subject사이의 관계이다. 클라이언트는 Subject객체의 Request()를 호출하고 Subject객체를 받는다. RealSubject와  Proxy는 Subject를 상속하는 클래스들인데 Proxy클래스의 Request()는 경우에 따라 RealSubject의 Request()를 호출한다. RealSubject의 Request()에서는 클라이언트가 원하는 Subject객체를 반환한다.  

패턴의 목적 ( Intent ) :  

패턴이 나오게 된 동기 ( Motivation ) :

워 드프로그램에서 사진파일을 넣게되면 로딩이 느려지는 현상이 발생할 때가 있었다. 지금이야 워낙 컴퓨터 사양이 좋아져서 그런일을 많이 보지는 못하지만 사진파일 사이즈역시 좋은 화질인 경우 상당한 사이즈를 자랑하기 때문에 무시할 수 없다. 이런 경우 페이지를 이동할 때마다 디스크에 있는 이미지 파일을 계속 요청하는 것이 아니라 한번만 요청하여 프록시에 가지고 있다가 다시 요청이 들어오면 프록시에서 이미지를 가져와서 디스플레이 해주는 방식이 필요하게 된 것이다. 이런식으로 속도의 향상을 꿰한것이다. 아래 그림은 디스크에 있는 이미지 파일에서 데이타를 읽어와서 메모리에 상주하는 프록시에 넣고 문서에서 이에 접근하는 것을 보여주고있다.

위에서 봤던 클래스 다이어그램에 문서프로그램의 예를 적용시켜 본 것이다. ImageProxy의 우측을 보면 image가 0인지를 판별하고 0일경우 Image를 가져와서 보여준다는 것을 알려주는 간략한 소스가 보인다.

유용성 ( Applicability ) :

등장 인물 ( Participants ) :

원리 ( Collaborations ) :

패턴 사용의 장단점 ( Consequences ): 

관련 패턴들 : 

추가 정보 :   

• Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface.
• Decorator and Proxy have different purposes but similar structures. Both describe how to provide a level of indirection to another object, and the implementations keep a reference to the object to which they forward requests.

프록시 패턴을 사용한 간단한 예제입니다.

interface Image {
    public void displayImage();
}
 
//on System A 
class RealImage implements Image {
    private String filename;
    public RealImage(String filename) { 
        this.filename = filename;
        loadImageFromDisk();
    }
 
    private void loadImageFromDisk() {
        System.out.println("Loading   " + filename);
    }
 
    public void displayImage() { 
        System.out.println("Displaying " + filename); 
    }
}
 
//on System B 
class ProxyImage implements Image {
    private String filename;
    private Image image;
 
    public ProxyImage(String filename) { 
        this.filename = filename; 
    }
    public void displayImage() {
        if (image == null)
        {
           image = new RealImage(filename);
        } 
        image.displayImage();
    }
}
 
class ProxyExample {
    public static void main(String[] args) {
        Image image1 = new ProxyImage("HiRes_10MB_Photo1");
        Image image2 = new ProxyImage("HiRes_10MB_Photo2");     
 
        image1.displayImage(); // loading necessary
        image2.displayImage(); // loading necessary
        image1.displayImage(); // loading unnecessary
        image2.displayImage(); // loading unnecessary
    }
}

또 다른 목적( 리눅스에서 권한에 따라 명령어 실행을 막거나 통과시키는)으로 사용된 프록시 패턴의 예제는 아래 링크에서 보실 수 있습니다.

http://www.journaldev.com/1572/proxy-design-pattern-in-java-example-tutorial

출처 :  http://sourcemaking.com/design_patterns/proxy

Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )  

 http://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%ED%8C%A8%ED%84%B4

Creational Patterns ( 생성 패턴 )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다. 

 Structural Patterns ( 구조적 패턴 )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

구조적 패턴들은 클래스와 객체의 구성에 관여한다.

 Behavioral Patterns ( 행위적 패턴 )

These design patterns are specifically concerned with communication between objects.

이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.

오늘 살펴볼  Decorator 패턴은 Structural 패턴에 속한다.  이 패턴은 컴포지트 패턴과 비슷한 다이어그램을 가지고 있다. 

Decorator Pattern Structure

패턴의 목적 ( Intent ) : 

 Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

 동적으로 객체에 책임(꾸밈)을 추가한다. 데코레이터는 기능을 확장하기 위한 subclassing이 아닌 다른 유동적인 방법을 제공한다. 

패턴이 나오게 된 동기 ( Motivation ) :

일반적으로 간단한 프로젝트가 아닌 이상 하나의 클래스 내에서 모든 것을 해결하는 일은 거의 없다. 유지보수를 위해서라도 기능별로 클래스를 나누게 되는데 데코레이터 패턴도 이런 식의 생각에서 나오게 된 것이다. 그래서 상속을 사용하게 되기도 하는데 이는 매우 기본적인 방법이며 flexible하지 않고 정적이다. 따라서 동적으로 기능확장이 용이하도록 한 것이 바로 이 데코레이터 패턴이다. 아래 그림은 TextView에 ScrollDecorator와 BorderDecorator를 이용하여 책임(꾸밈)을 추가한 결과이다.

유용성 ( Applicability ) :

Use Decorator

데코레이터 패턴은 아래와 같은 상황에서 유용하다.

· to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects.

다른 객체에 영향을 주지 않고 동적으로 투명하게 독립적인 객체들을 추가할 때
· for responsibilities that can be withdrawn.

철회가 가능한 책임(꾸밈)을 추가하고 싶을 때
· when extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing. 

등장 인물 ( Participants ) :

· Component (VisualComponent)
o defines the interface for objects that can have responsibilities added to them dynamically.

동적으로 추가되는 책임을 가질 수 있는 객체를 위한 인터페이스를 정의한다.
· ConcreteComponent (TextView)
o defines an object to which additional responsibilities can be attached.

추가적인 책임을 가질 수 있는 객체를 정의한다.
· Decorator
o maintains a reference to a Component object and defines an interface that conforms to Component's interface.

이 패턴의 메인이다. 컴포넌트 객체의 레퍼런스를 가지고 있으며, 컴포넌트와 조화를 이루는 인터페이스를 정의한다.
· ConcreteDecorator (BorderDecorator, ScrollDecorator)
o adds responsibilities to the component.

컴포넌트에 책임을 부과한다. 

원리 ( Collaborations ) :

패턴 사용의 장단점 ( Consequences ): 

The Decorator pattern has at least two key benefits and two liabilities:

1. More flexibility than static inheritance. 정적인 상속보다 훨씬 유동적이다. The Decorator pattern provides a more flexible way to add responsibilities to objects than can be had with static (multiple) inheritance. With decorators, responsibilities can be added and removed at run-time simply by attaching and detaching them. In contrast, inheritance requires creating a new class for each additional responsibility (e.g., BorderedScrollableTextView, BorderedTextView). This gives rise to many classes and increases the complexity of a system.
Furthermore, providing different Decorator classes for a specific Component class lets you mix and match responsibilities.
Decorators also make it easy to add a property twice. For example, to give a TextView a double border, simply attach two BorderDecorators. Inheriting from a Border class twice is error-prone at best.

2. Avoids feature-laden classes high up in the hierarchy. Decorator offers a pay-as-you-go approach to adding responsibilities. Instead of trying to support all foreseeable features in a complex, customizable class, you can define a simple class and add functionality incrementally with Decorator objects. Functionality can be composed from simple pieces. As a result, an application needn't pay for features it doesn't use. It's also easy to define new kinds of Decorators independently from the classes of objects
they extend, even for unforeseen extensions. Extending a complex class tends to expose details unrelated to the responsibilities you're adding.

3. A decorator and its component aren't identical. A decorator acts as a transparent enclosure. But from an object identity point of view, a decorated component is not identical to the component itself. Hence you shouldn't rely on object identity when you use decorators.

4. Lots of little objects. A design that uses Decorator often results in systems composed of lots of little objects that all look alike. The objects differ only in the way they are interconnected, not in their class or in the value of their variables. Although these systems are easy to customize by those who understand them, they can be hard to learn and debug. 

관련 패턴들 : 

Adapter : A decorator is different from an adapter in that a decorator only changes an object's responsibilities, not its interface; an adapter will give an object a completely new interface. 

 Composite : A decorator can be viewed as a degenerate composite with only one component. However, a decorator adds additional responsibilities—it isn't intended for object aggregation.
Strategy : A decorator lets you change the skin of an object; a strategy lets you change the guts. These are two alternative ways of changing an object.

추가 정보 :  

• Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface.
• Adapter changes an object's interface, Decorator enhances an object's responsibilities. Decorator is thus more transparent to the client. As a consequence, Decorator supports recursive composition, which isn't possible with pure Adapters.
• Composite and Decorator have similar structure diagrams, reflecting the fact that both rely on recursive composition to organize an open-ended number of objects.
• A Decorator can be viewed as a degenerate Composite with only one component. However, a Decorator adds additional responsibilities - it isn't intended for object aggregation.
• Decorator is designed to let you add responsibilities to objects without subclassing. Composite's focus is not on embellishment but on representation. These intents are distinct but complementary. Consequently, Composite and Decorator are often used in concert.
• Composite could use Chain of Responsibility to let components access global properties through their parent. It could also use Decorator to override these properties on parts of the composition.
• Decorator and Proxy have different purposes but similar structures. Both describe how to provide a level of indirection to another object, and the implementations keep a reference to the object to which they forward requests.
• Decorator lets you change the skin of an object. Strategy lets you change the guts.
  

• Decorator pattern is helpful in providing runtime modification abilities and hence more flexible. Its easy to maintain and extend when the number of choices are more.
• The disadvantage of decorator pattern is that it uses a lot of similar kind of objects (decorators).
  데코레이터 패턴의 단점은 유사한 데코레이터 객체가 많아질 수 있다는 점이다.
  
• Decorator pattern is used a lot in Java IO classes, such as FileReader, BufferedReader etc.
  데코레이터 패턴은 FileReader나 BufferedReader와 같은 Java IO 클래스들에서 많이 사용되고 있다.
  

출처 :  http://sourcemaking.com/design_patterns/decorator

Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )  

http://www.journaldev.com/1540/decorator-pattern-in-java-example-tutorial

실생활을 예로 든 좋은 예제는 아래에서 확인하기 바란다.

http://warmz.tistory.com/757

 Creational Patterns ( 생성 패턴 )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다. 

 Structural Patterns ( 구조적 패턴 )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

구조적 패턴들은 클래스와 객체의 구성에 관여한다.

 Behavioral Patterns ( 행위적 패턴 )

These design patterns are specifically concerned with communication between objects.

이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.

오늘 살펴볼  Adapter 패턴은 Structural 패턴에 속한다.  

어 댑터가 뭐냐? 우리가 맨날 쓰는 그 어댑터가 바로 지금 말하고자하는 어댑터이다. 어댑터의 역할이 뭐냐? 서로 맞물리지 않는 두개의 객체를 연결시켜주는 일을 하는 것이 어댑터의 역할이다. 이 생각을 가지고 아래 내용을 훑어보기 바란다.

Adapter Pattern Structure

 A class adapter uses multiple inheritance to adapt one interface to another:

클래스 어댑터는 하나의 인터페이스를 다른 인터페이스와 연결시키기 위해서 다중상속을 이용한다.

An object adapter relies on object composition:

객체 어댑터는 객체의 구성에 의존한다. ( 뭔 말인지 모르겠다 일단 넘어가자 )

패턴의 목적 ( Intent ) : 

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

어댑터 패턴의 목적은 클라이언트가 원하는 인터페이스를 제공하기 위해서 클래스의 형태를 변형하는 것이다.(이는 서로 연결을 시켜줌으로써 아웃풋을 변형한다는 의미이지 실제로 변형한다는 의미가 아니다) 어댑터는 서로 맞물리지 않는 인터페이스들을 서로 연결시켜주는 역할을 한다.

패턴이 나오게 된 동기 ( Motivation ) :

예 를 들어 이런 경우가 있을 것이다. 고객이 원하는 기능을 구현을 했다고 하자. 이 기능은 인풋으로 A객체를 받아들이고 아웃풋으로 X객체를 던지며 고객이 만든 API와 연결이 된다. 그런데 얼마가 지나서 고객이 인풋으로 Y객체를 달라고 한다. 그런데 전에 만들어 줬던 기능의 일부분만 Y객체를 아웃풋으로 내보내야 한다는 것이다. 당신이라면 어떻게 해결할 것인가? 물론 생각해야할 인자들이 무수히 많을 것이고 그것들에 따라 해결책도 다를 것이다. 여기서는 그 중 하나의 해결책으로 어댑터 패턴을 말하고자 한다. A -> DoSomething -> X 기능을 하는 기능은 여전히 존재해야만 하며 DoSomething -> Y 기능을 추가해야한다. 하지만 이 두가지는 엄연히 동일한 기능을 한다고 가정한다. 어댑터 패턴을 이용해야하니까. 그러면 우리는 A -> DoSomething -> X -> Y 가 될 수 있게끔 X -> Y 기능을 하는 어댑터를 추가하면 된다.

유용성 ( Applicability ) :

Use the Adapter pattern when
· you want to use an existing class, and its interface does not match the one you need.

기존의 클래스를 사용하고 싶지만 내가 필요로 하는 형태가 아닐때
· you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces.

특정 호환성을 가진 클래스가 아닌 광범위한 호환성을 가진 재사용가능한 클래스를 만들고 싶을때
· (object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.

등장 인물 ( Participants ) :

· Target (Shape)o defines the domain-specific interface that Client uses.
· Client (DrawingEditor)o collaborates with objects conforming to the Target interface.
· Adaptee (TextView)o defines an existing interface that needs adapting.
· Adapter (TextShape)o adapts the interface of Adaptee to the Target interface.

원리 ( Collaborations ) : 

패턴 사용의 장단점 ( Consequences ): 

Class and object adapters have different trade-offs.  

클래스 어댑터와 객체어댑터는 서로의 장단점이 있다.  

A class adapter  

· adapts Adaptee to Target by committing to a concrete Adapter class. As a consequence, a class adapter won't work when we want to adapt a class and all its subclasses.

· lets Adapter override some of Adaptee's behavior, since Adapter is a subclass of Adaptee.
· introduces only one object, and no additional pointer indirection is needed to get to the adaptee.

An object adapter
· lets a single Adapter work with many Adaptees—that is, the Adaptee itself and all of its subclasses (if any). The Adapter can also add functionality to all Adaptees at once.
· makes it harder to override Adaptee behavior. It will require subclassing Adaptee and making Adapter refer to the subclass rather than the Adaptee itself.

관련 패턴들 : 

Bridge has a structure similar to an object adapter, but Bridge has a different intent: It is meant to separate an interface from its implementation so that they can be varied easily and  independently. An adapter is meant to change the interface of an existing object.
Decorator enhances another object without changing its interface. A decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports  recursive composition, which isn't possible with pure adapters.
Proxy defines a representative or surrogate for another object and does not change its interface.

추가 정보 :     

• Adapter makes things work after they're designed; Bridge makes them work before they are.
• Bridge is designed up-front to let the abstraction and the implementation vary independently. Adapter is retrofitted to make unrelated classes work together.
• Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface.
• Adapter is meant to change the interface of an existing object. Decorator enhances another object without changing its interface. Decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports recursive composition, which isn't possible with pure Adapters.
• Facade defines a new interface, whereas Adapter reuses an old interface. Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one.

출처 : http://sourcemaking.com/design_patterns/adapter

         Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )