mediator 와 observer 의 차이는

observer 는 중심이 되는것이 밖에 있는 것들 즉 중계자가 중심이 되는 것이 아니고

중계자가 아닌 밖의 옵저버들이 대한 변경 사항을 subject(중계자) 에게 알리면 변경사항을 나머지 옵저버들에게 알려주는 것이

Observer pattern

A 의 오브젝트 변경사항을 나머지에도 적용 시키는 패턴

중간에 Subject 가 이를 반영한다

원래 처음 주어진 환경이 이런 환경

A(observer object) 에서 변경된 부분을  Subject  에게 전달해주고

Subject 는 A 가 업데이트 됐다면 Subject 가 A 에서 읽어와 나머지 오브젝트들(observer objects)에게 변경사항을 알려주는 것

switch 를 피하기 위해 동일한 인터페이스 사용

subject 클래스는 내부적으로 observer objects 를 리스트로 관리할뿐 구체적으로 어떤 observer object 들인지는 관여하지 않는다

=> 즉 동일한 인터페이스를 갖는다

서로 업데이트 하려고 하는 경우 같은 정보로 변경할 경우 subject 에서 정볼르 받아 쌓아놨다가 이전에 바꿨던것과 동일한가를 비교

이렇게 알려주려면 알려주기 위한 클래스를 생성 해야 한다

subject 가다른 observer objects 와 동일한 데이터 일경우 싱글톤으로 만들 수도 있다

subject 가 여러개가 있고 observer 가 여러개 있을 수 있다

업데이트시 this  를 넘겨줌

subject 가 소멸되는 경우 각 observer objects 들은 소멸 하거나 어떤 처리를 해야 함

setstate() 함수 호출의 순서를 조절할 수 있는 것이 themplate method 패턴을 참고

=> subject 에서 값변환 먼저 실행후 notify 실행, 각 옵저버 객체에서도 동일하게 추가 되야 함

-특정 값이 바뀌었을때는 subject 에 클래스를 미리 등록 시켜 놓고 관심 있는 옵저버 클래스에게만 알려 효율 올림

-

오브젝트 N 개 서브젝트 M 개 일때

중간에 change manager 를 두고 이 사이를 관리할 수도 있음

change manager 를 상속 받는 manager 의 종류를 또 분류하여, 변경사항을 다 통보해주는 매니저로 갈지

변경사항이 연관있는 옵저버오브젝트들에게만 알릴지를 정할 수도 있다( 전자의 경우 mediator 와 유사)

한 노드가  subject 와 observer 역할을 둘다 할 수도 있다

옵저버가 다른 옵저버와 연결 되는 경우

1. 다중상속

2. 다중상속이 힘든 환경이면 subject ,observer 클래스를 따로 구현 하지 않고 하나로 두어 구현

스트크래프트 미니 맵에서 적은 안보이고 우리만 보이는 상황

전체 오브젝트에 대해서 서브젝트가 가지고 있는데

Subject 에서 A편, B 편, 관람자들의 리스트를 따로 가지고 있어서

연관된 사람들에게만 오브젝트 위치를 보여준다

상태정보 저장이 목적

undo, redo 같은 기능을 실행 하기 위해선 변경된 정보 , 심할 경우 변경된 상태의 전체 정보를

따로 저장 관리하는 클래스를 두는 것을 memento 패턴이라 한다

일반적으로 필요한 정보만 따로 모아 관리 하는 것을 말한다

행동:

저장할 필요 정보를 memento 에 저장했다가 다시 돌리고 싶을때 memento 에서 다시 불러온다

또한 해당 객체 상태를 직접 접근하는 것이 어려운 경우 상태 정보를 memento 로 빼놓아

클라이언트가 객체의 은닉성을 깨트리지 않고 상태 정보를 알기 위해 memento 로 저근하는 상황에서도 사용 될 수 있다

이처럼 직접 접근하지 못하게 경계 역할도 할 수 있다

하지만 원래 memento 에 상태를 저장하는 객체는 memento 객체를 마음대로 다루길 원함으로

friend 로 선언해 주는 것도 좋다

하지만 다른 것이 접근할때는 private 로 선언하는게 좋다

모든 값을 다 저장해서 가지고 있으면 비효율적이므로 변경된 부분만 관리 한다( 이부분 설계가 관건)

지나치게 memento 에 다른 클라이언트가 접근해 모두 막 상태를 바꾸는 구조는 좋지 않다

redo/undo 같은 경우  메모리가 많이 커질 수 있음으로 횟수의 제한을 두는 것이 좋다

command 패턴과 memento 패턴을 같이 사용하여 명령을 memento 에 저장해 놓으면 효과적이다

memento 할(저장할) 단위 설정이 중요

단위가너무 작으면 저장된는 것이 많아 질 수 있다

 

 

예를들어 list 의 경우

list 내부에 포인터를 두면 멀티플(멀티 쓰레드)로 list 에 접근할때 오류가 생길 수 있는데

이것을 객체로 두면 멀티플로 접근이 가능해진다

즉 접근 포인터를 객체로 둔것이 iterator 패턴이다

굳이 필요한 상황 아니면 type<T>::iterator it; 쓰는게 났다

리스트자체에서 리스트에 대한 이터레이터를 만들때의 구현

( iterator 가 없어질때 List 를 동적 또는 정적 할당 하지 않았음으로 삭제 과정은 필요 없고 new 한 Listiterator 만 삭제 하면 된다

pListiter 으로 함수 안에서 생성된 list 를 다룰 수 있다

ListIterator* pListiter = list.createiterator();

했을때..

       iterater* createiterator(){

            return new ListIterator(this);   // this 는 리스트의 주소

       }

class ListIterator: public Iterator {
  public :
    ListIterator(LinkedList* pList){  this->pList = pList;  }

  private :
    LinkedList* pList_;
};

 

 

문법에 대한 패턴, 간단한 연산 등 간단한 스크립트 같은거나 간단한 정규식 그리고 비교적 작은 형태일때

속도가 안중요할때 쓰임

처리 영역을 나누지 않고 한번에 처리할때

복잡한 경우에는 다루기 힘들다

interpreter 패턴은 파싱을 하지 않고 바로 객구조를 만들어 사용

interpreter 패턴에 멤버  함수를 정의하는 것이 번거로운 경우 vistor 패턴을 각 연산마다 적용하여

추상노드를 순회하도록함으로써 interpreter 패턴의 수행역할을 동일하게 할 수 있다

장점 : 문법에서 클래스 구조를 만들어 내고 만들어진 클래스 구조를 보고 다시 문법을 봐 성립하면 이것이 맞는 구조라 할 수 있음

 XML DTD 문법이 맞는지 체크하라

즉 간단한 문법이 있는데 이것을 프로그램으로 읽어 들였을때 맞는 것인지 확인

<!Element purchaseOrder (shipTo,BilTo,Item) >

<!Element shipTo (Name,Street,city,state,country,zip) >

<!Element BilTo (Name,Street,city,state,country,zip) >

<!Element Item (ProductNo,quentity, price, ItemName,orderDate) >

<!Element Name (#PCdate) >

위는 아래와 같다

purchaseOrder := shipTo & BilTo & Item +

shipTo := Name & Street .. 이런식

+ 는 한번이상 나타난다

* 는 0번 이상 나타난다

purchaseOrder,shipTo  왼쪽에 나타나는개 클래스 

XML 이 문법을 만드는 것인데 이 문법이 맞는것인지 아닌지를 확인 할때 interpreter 패턴을 사용 할 수 있다

클래스 구조적 포인트는

연산자이든, 문자열이든 동일한 부모 추상클래스를 두어서 실행시키는 함수를 virtual 로 정의해놓고 이 함수를

수행하는 것

즉 연산자와, 문자를 파싱할때 동일한 부모이니 연산자이든 문자이든 동일한 타입의 부모로 캐스팅 됨을 이용하여

보다 간결한 구조로 조사와 순회 할 수 있다는 것

 

 

command 패턴이란?

요청과 이 요청을 처리할 객체를 중계하기 위한 클래스 상속구조를 말한다

여라가지의 처리할 명령을 'A' 에서 요청할 경우 'A'쪽의 명령들을

Abstract Base class 기반으로 구성하여 각 명령에 대해 처리할 관련있는 클래스들끼리 참조 또는 할당하여 하나의 객체로 구성하여

map 등으로 명령과 클래스를 같이 갖고 있는 형태로 만들어 놓은후

B 쪽에서 이것을 처리할때

A 에서 만든 상속구조처럼 묶어 처리하는 패턴

오고 가는 것은 map 의 value 가 오고 가지만 이 value 에 대한 명령 처리를

B쪽에서는 해당 처리해야 할 서브 클래스에 대한 해당 명렬을 처리할 클래스를 추출해 낼 수 있음으로

이 둘의 연결 구조를 보다 각각의 지역적으로 분할된 형태로 처리 할 수 있다

2. callback 버튼 실행 명령 함수에 이를 대입할 수 있다

  C 함수는 괜찮은데 , 멤버 함수를 callback 으로 부를 경우 문제가 될 수 있는데 이때 사용 할 수 있다

3. redo, undo 에 적용 하기 쉽다

  각 명령에 대해서 동일한 인터페이스로 처리 가능

  즉 동일한 데이터 타입으로 명령을 처리 할 수 있고 필요 한 클래스들만 있으면 된다

  => 동일한 데이터만 핸들링 하면 된다

 undo/redo 의 순서는 memento 패턴으로 해결 하면 된다

또한 undo/redo 의 객체 상태 저장은 prototype패턴 or 바뀐부분을 저장하는 방법 memento 패턴을 활용(상태 값을 저장해 놓는 형태)

*undo/redo 는 연산을 했던걸 다시 역으로 하는 것보단, 상태값으로 그때의 상태를 제연하는 것이 좋다

4. protocal 과 같은 명령에 대한 처리에도 유용하다

5. makefunctor( (functor1*), ai, show );   <= 표기 정확하지 않음 대략적으로 표기

같은 것 또한 전역 함수나, 멤버함수를 동일한 형태로써 두개를 수행 할 수 있는 것과 같은 것도 command 패턴의 유형과 개념상 비슷하다고 볼 수 있다

명령종류의 자체가 많아 지면 command 들의 상위인 command 클래스가 필요한데 이렇게 명령의 종류가 많아지면

composite 패턴과 연동하여 한번에 처리 할 수 있게 한다

동일한 레벨을 묶고 있는게 composite 이니깐 동일하게 묶고 있는것에 대해 전체를  돌면서 다 실행하는 virtual 함수 실행

명령의 종류에 대해 나뉘어지는 형태이므로

다른 유사 명령과 교체하여 실행을 다르게 설정 할 수 도 있다

또한 복합적인 명령을 수행해야 하는 경우

서브 command 클래스를 만들 필요 없이

중간에 macrocommand 클래스를 만들어 두어 이 클래스에서 명령을 조합해 실행하는 클래스를 두는 것이 효과적이다

macrocommand 클래스를 활용할 경우 스크립트의 작업형태도 처리 가능하다

execute( ) 의 수행함수에서 인자를 줄려면 다 주던지 안주려면 다 안주던지 해야 한다

함수에 인자가 들어가면 인자타입이 다 틀려지고 부르는 쪽도 맞춰 틀려져야 하기 때문에 처리가 복잡해 진다

각 명령에 대해 한 클래스들이 명령을 처리할 클래스들을 생성자의 초기 값으로 넘겨주게 된다

이때의 생성자 초기 값은 상관 없음으로 명령을 수행할 execute() 함수만 불러주면 되기 때문

 여러 오브젝트가 있을때 현재 자신이 처리할 수 있으면 처리를 하고 끝내지만 현재 자신이 처리하지 못하면

다음 오브젝트로 일을 보내 처리하도록 한다

흐름적 이점 : switch  구문을 제거 할 수 있다

한 프로젝트의 도움말에 대한 사항을 분기문이 아닌 chain of responsibility  패턴으로 처리할 사항을 다음 클래스로 넘기며 처리 할 수 있는데

A, B ,C ,D, E, .... N 의 클래스가 있을때

 A 에서 처리할 수 있는 도움말이면 A 에서 처리 하지만 A 에서 처리 할 수 다음 포인터 주소를 통해 다음 클래스로

처리를 넘긴다

A                  

success() --------------->B

                                         success()--------------->C

                                                                                 success()---------------->

DNS 처리 또한 유사하게 처리 될 수 있다

단 처리 됐는지 처리 되지 않았는지 처리를 넘긴 다음에는 알지 못한다

즉 정확히 어떤 객체가 처리하는지 모른다

도움말, 프린트, 응용프로그램 등등에 대한 각 가지 다양한 종류에 대한 처리 사항을 클라이언트가 요청 할 수 있는데

그때는 요청의 종류 req->GetRequestofKind() 와 같은 종류를 구분 할 수도 있지만 좀 더 나은 방법은

Dynamic_cast 로 현재 넘어온 클래스가 어느 부류에 속하는 클래스인지 다운캐스팅 테스트를 해보아

Dynamic_cast  가 0 을 리턴하면 현재 상속구조의 클래스가 아님으로 다음 분기문에서 다시 다른 종류에 대한 클래스의 다운 캐스팅을

시도해보아 맞을때까지 분기문을 놓는 식으로 처리 한다

패턴을 오히려 너무 많이 남발하면 좋지 않다

적시 적소에 쓸 수 있어야 한다 chain of responsibility 패턴 과 쓰일 수 있는데

다음 노드로 넘어가야 하느냐 말아야 하느냐가 각 노드마다 공통인 부분이기 때문에 이 부분에 대해서 Template Method 패턴이 쓰일 수 있다

다음 으로 넘어가지 않는다고 하면 Template Method 를 지나쳐 다음을 수행 하면 되기 때문..

Template method 패턴이

 

 

기본 변하지 않는 클래스의 계층 구조에서 변하는 부분의 클래스의 추가, 정의 등이 필요할때

기존 구조를 거의 무너트리지 않고 변하는 부분을 만들 수 있는데 그것을 스트레티지 패턴이라 한다

point 는 포함 관계로 변화되는 클래스를 변하지 안흔 클래스의 부모에 포함 시켜서

클래슬르 만들때 원하는 행동의 클래스를 업케스팅해주면 된다

또한 기존에 돌아 가고 있던 행동을 쉽게 교체 하기 위해서도 많이 쓰인다

http://tongins.blog.me/80096279721

[패턴] Strategy Pattern   http://tongins.blog.me/80096279721

3DMP engines

 가상 소멸자가 없을때 컴파일 오류 : error C2683: 'dynamic_cast' : 'A'은(는) 다형 형식이 아닙니다.

class A{
public :
 A(){}
 virtual ~A(){}
};

class C : public A{
public :
 C(){}
 ~C(){}
};

class B : public A{
public :
 int num;
 B(int dd) : num(dd) { }
 B() {}
 ~B(){}

};

int _tmain(int argc, _TCHAR* argv[])
{

 A* ci=new A;
 B* bi= dynamic_cast<B*>( ci );
 cout<<dynamic_cast<B*>( ci )<<endl;      // 000000000

 return 0;
}

[직렬상속구조]

A <- B <- C  상속 구조에서 자식이 어느 자식인지 확인하는 방법

#include <iostream>
#include <list>
#include <iterator>
#include <map>
using namespace std;

class Graphic {
public :
 Graphic(){}
 virtual void Draw(){
  cout<<"Graphic\n";
 }
};

class ComposedGraphic : public Graphic {
public :
 ComposedGraphic(){}

 void Add(Graphic *pObj) {
  cout << "ComposedGraphic" << endl;
 }
};

class SpecificComposedGraphic : public ComposedGraphic {
public :
 SpecificComposedGraphic(){}
 void Draw() {
  cout<<"SpecificComposedGraphic\n";
 }

 void Add(Graphic *pObj) {
  cout << "Specific-ComposedGraphic" << endl;
 }
};

void main()
{
 Graphic *pObj = new ComposedGraphic;
 
 cout<<dynamic_cast<ComposedGraphic*>(pObj)<<endl;                   // 주소값 존재
 cout<<dynamic_cast<SpecificComposedGraphic*>(pObj)<<endl;       // 000000000

                 // if 문으로 확인할 경우 제일 하단의 클래스부터 dynamic_cast 을 거처서 어느 자식의 클래스인지 확인해야함

 delete pObj;

 pObj = new SpecificComposedGraphic;

 cout<<dynamic_cast<ComposedGraphic*>(pObj)<<endl;                   //주소값 존재
 cout<<dynamic_cast<SpecificComposedGraphic*>(pObj)<<endl;       //주소값 존재

 delete pObj;
}

[병렬상속구조]
 
Graphic<---- 클래스A
Graphic<-----클래스B
인 병렬 상속구조일때 해당 클래스가 어느쪽 자식 클래스인지 확인하는 방법
 
 
#include <iostream>
#include <list>
#include <iterator>
#include <map>
using namespace std;
class Graphic {
public :
 Graphic(){}
 virtual void Draw(){
  cout<<"Graphic\n";
 }
};

class A : public Graphic {
public :
 A(){}
 virtual void Draw(){
  cout<<"A\n";
 }
};

class ComposedGraphic : public Graphic {
public :
 ComposedGraphic(){}

 void Add(Graphic *pObj) {
  cout << "ComposedGraphic" << endl;
 }
};
class SpecificComposedGraphic : public ComposedGraphic {
public :
 SpecificComposedGraphic(){}
 void Draw() {
  cout<<"SpecificComposedGraphic\n";
 }
 void Add(Graphic *pObj) {
  cout << "Specific-ComposedGraphic" << endl;
 }
};
void main()
{
 Graphic *pObj = new A;
 
 cout<<dynamic_cast<ComposedGraphic*>(pObj)<<endl;                    // 00000000
 cout<<dynamic_cast<SpecificComposedGraphic*>(pObj)<<endl;         // 00000000
 cout<<dynamic_cast<A*>(pObj)<<endl;                                            // 주소값
 delete pObj;
}
 
 
 
 
 
 
 
 
 
 
 
 
 

3DMP engines

[설계 과정]

1. 문제의 목적?

2. 어떤 패턴?

3. 세부적인 해결 방법

아키텍쳐 설계   : 큰 레벨에서 분류 하는 것

ex) 클라이언트 서버가 어떻게 돌아가느냐, 디비가 어떻게 있느냐

문제를 나누는 것

전체 문제를 쪼개는것 => 목적을 쪼개 나가는 것

이를 전체적으로 쪼개면 프로세스정도로 구분이 되고 이 프로세스를 설계할때

클래스 설계에서부터 패턴으로 올라가면서 설계한다

ex)

웹브라우저 -----> 웹서버 --------> WAS(웹 어플리케이션) [ 디비핸드링, 비즈니스 로직 ]

웹브라우저 ,웹서버 , WAS 까지 나누는 레벨이 아키텍쳐설계

웹브라우저를 짜겠다, 웹서버를 짜겠다  WAS 를 짜겠다는 것은(디비핸들링, 디브니스 로직 으로 들어가면)

클래스 디자인으로 들어감

클래스 정의는? : 클래스 정의는 알아서 한다( 클래스는 알아서 끌어낸다) 분석단계 등에서..

분석단계에서 데이터 모델링한다

(데이터 모델링 : 현실세계에 있는 것을 개체로 이끌어 내면서 구체화해 가는 과정 )

클래스는 명사를 찾아라

이런걸 이용해서 클래스를 끌어내야 한다, 클래스를 정의 해야 한다

이제 여기에서 클래스들을 어떻게 최적화 시킬것인가에 대한 패턴을 대보는것 => 디자인 패턴

그래서 디자인패턴은 상세설계에서 사용하게 된다

* 패턴도 패턴안에서 섞일 수도 있다 즉 => 목적두개가 겹친다

 디자인패턴은 클래스 구조( 화살표) 를 먼저 보는 것이 아닌 목적을 먼저본다음 클래스 구조를 봐야 한다

-product family 를 만들기 위한 패턴 = Abstract Factory

-부분 부분을 생성해서 전체를 생성하는것 = builder

-객체 생성을 대행해주는 함수 = Factory Method

-복제해서 객체를 생성하고 싶으면 = ProtoType

-Maximum  N 개까지만 객체를 생성하고 싶으면 = SingleTon

-기존 객체를 사용하고 싶은데 인터페이스가 틀리다 = adapter 

[구조] adapter 패턴 (잘 구현된 클래스에 구현할 기능이 있는 경우 클래스를 private 으로 상속 하는 패턴)

-처음 클래스를 설계하면서 interface 와 information 을 나누어서 설계하고 싶다 = bridge

[구조] bridge 패턴 (구현부와 인터페이스를 나누어버리는 패턴 ,여러 환경에서 조사된 가장 적합한 기능에 대해 연결해주는 패턴 대신 실행하는 패턴)

ex) 1.가장 적절한 클래스를 생성해 리턴(unix,window , etc... 등등...)

      2.여러 클래스가 해당 플렛폼에 대해 동일한 클래스(정보) 를 자동으로 플렛폼에 맞게 얻고자 할때

-tree 형태로 객체부수를 관리하고 싶다 = composite

-동적으로 객체의 기능을 확장시켜 나가고 싶다 = decorator

[구조] decorator 패턴 ( on,off 없이 윈도우에 추가되는 스크롤 같은것 연달아 추가 )

(객체 추가되면서 추가된것 다 실행됨 : 객체가 다음실행할 객체를 (중간)Decorator 클래스 포인터로 가지고 있음)

-서브시스템을 대표하는 인터페이스를 갖고 싶다 = Facade

-객체를 공유하고 싶다 = Flyweight

-중간 매개 개체를 이용해 원객체에 대해 접근제어라든지 추가적인 작업을 하고 싶다 proxy

-동적으로 수행할 역할을 이행 시키기, 위임시키기 위해 연결해 놓은 것을 처리 하고 싶다 = chain of responsibility

[행동] chain of responsibility (동적으로 처리할 역할을 연결해 놓은 것, 책임(조건)에 따라 처리 사항을 다음으로 넘기는 것, 처리를 분담)

// 현재 클래스에서 처리하지 못하면 부모클래스에서는 다음 객체포인터를 가지고 있어서 그 객체 포인터로 책임전가

  (객체 추가는 없고 고정된 상태)

-수행할 작업을 일반화 시켜서 핸들링 하고 싶을때 = command

  (하나의 함수 명령으로 수행)

-어떤 문법에 따라서 파싱하고 원하는 작업까지 동시에 하고 싶다 = interpreter

-어그리게이트의 구성요소를 차례로 접근하고 싶다 = iterator

-M:N 관계를 1:N 관계로 바꾸고 싶다 = mediator

 (중계자)

-객체의 상태정보를 별도의 객체에 저장하고 싶다 = memento

 (저장만 하는 것만!!)

-객체 상태정보를 저장하기도 하고 상태에 따라서 행위까지 핸들링 하고 싶으면  = state

 [행동] state 패턴 ( 각 상태에 대해 객체로 만들어 분리 처리하는 것 , 게임능력레벨에 해당하는 행동을 클래스로 분류해서 처리  )

 ex) 각 레벨에 따른 행동 또는 상태 정보가 각 레벨 클래스마다 있고 이 클래스들은 공통적인 것이므로 singleton 처럼 객체가 공유된다

-1:N  의 관계를 유지하면서 객체간의 행위를 분산하고 싶을때 = observer

subject 에게 observer 가 변경상태를 통지하면 subject 가 나머지 observer 들에게 변경 내용을 알려주어 변경 내용(상태)에 따라

나머지 observer 들이 그 내용에 맞게 수행하는 패턴

-동일 목적의 여러 알고리즘 들을 동적으로 변경시키고 싶다 = strategy

  [행동]Strategy 패턴 같은 목적을 수행하는 알고리즘을 동적으로 바꾸고 싶을때

-알고리즘의 기본 골격을 만들어 놓고 난다음 세부 알고리즘은 하위 클래스에서 알아서 바뀌도록 하고 싶다 = Template method

 [행동] Template Method 패턴 (공통된 알고리즘 부분이 고정적일때 사용, 기본 알고리즘 골격을 상위 클래스에서 갖도록 한다 ) 

 하위 클래스에서 구체적으로 처리하기 

  : instance 는 자식으로 생성해놓고 부모에만 정의된 함수를 호출하여 이 함수 안에 virtual 로 선언된 공통함수를 호출하여

    instance 를 만든 자식의 virtual 함수가 불리도록 하는 흐름

-작업 대상과 작업 종류 작업 항목을 분류해서 작업종류를 임의로 추가하는 것을 유연하게 하고 싶다 = visitor

 [행동] visitor 패턴 (고정부분과 동적인 부분을 클래스에서 분리)

 : 데이터 구조와 처리를 분리 하는 패턴.
   > 필요할 때 : 처리를 데이터 구조에서 분리해야 할 때. => 결합도를 낮춘다

  'strategy 패턴과 응용해서 사용

디자인패턴을 실제 어떻게 적용할 것인가?

한번만에 최적이 나오긴 힘들다, 한번 이터레이션 해보고 Localizatio of change(변경을 국지화) 를 할 수 있는가?

를 따져보고 된다면 판단하고 적용

변경 안되는 부분, 변경되는 부분을 고려햐여 고려

일단 패턴을 알면 보통이상의 퀄리티를 보장해 줄 수 있다

중요한 점은 어떤 목적으로 접근할 것인가 하는 것이다

많은 고민에 의해서 적용해야지 대강 생각해서 적용해버리면 일정 수준이상에서 퀄리티가 올라가지 않을 수 있다

생각을 많이 해보자

무엇을 할것인가? => 뭘 할껀데?   => 목적이 무엇인가

어떻게 할것인가 => 최적화적인것을 판단

이하 자료는 퍼온 자료들..

디자인패턴들의 상관관계

[관계도 설명]

-builder 패턴은 composite 객체를 생성하기 위해 사용 될 수 있다

-iterator 패턴은 Composite 객체를 구성하는 하위 객체들을 순회하기 위해 사용 될 수 있다

-Command 패턴은 MacroComand 클래스 등의 정의시 Composite 패턴을 활용 가능하다

-chain of responsibility 패턴은 객체들간의 연결 사슬을 composite 패턴을 이용하여 정의 할 수 있다

-composite 객체를 구성하는 각 하위 객체들에게 새로운 연산을 추가하 위해 visitor 패턴이 사용 될 수 있다

(트리 구조에서 각 노드마다 새로운 연산을 위해 함수들을 visitor 로 만들 수 있다)

-interpreter 패턴은 문법을 정의하는 과정에서  Abstract Syntax Tree 를 Composite 패턴으로 표현할 수 있다

  (트리가 composite로 표현)

-Composite 객체를 구성하는 하위 객체들은 Decorator 패턴을 이용하여 추가적인 역할을 수행하도록 설계 될 수 있다

- Flyweight 패턴은 Strategy, State, interpreter 패턴에서 알고리즘이나 상태정보, Terminal Symbol 들을 각각 공유하기 우해 사용 될 수 있다

- Decorator 패턴은 이미 존재하는 객체에 새로운 기능을 덧입히는 역할을 하는데 반해

Strategy 패턴은 객체 내부의 구체적인 동작이나 알고리즘을 외부 객체에게 위임시키는 형태이다

그래서, Decorator 패턴은 객체의 겉을 변경시켜주는 역할이고, Strategy 패턴은 객체의 속을 변경시켜주는

역할을 한다고 할 수 있다

- Memento 패턴은 Iterator 패턴이 반복 상태를 저장하기 위해 이용 할 수 있으며

  Command 패턴이 명령 수행 이전 상태로 되돌아가기 위해 사용 할 수 있다

- Observer 패턴은 객체들 간의 의존 관계를 분산 시켜 관리하는 데 반해 Mediator 패턴은

중앙 집중적으로 관리하기 때문에 복잡한 의존 관계를 한 곳에서 관리하고자 할 경우에는

Mediator 패턴이 효과적이다

- Template Method 패턴은 내부의 알고리즘 단계를 정의할 때(변하지 않는 부분) Strategy 패턴을 사용 할 수 있으며

, 대개 Factory Method 패턴을 사용하여 필요한 객체를 생성한다

- Abstract Factory 패턴은 종종 Factory Method 패턴이나 Prototype 패턴을 이용하여 구현되며,

  Singleton 패턴을 이용하여 하나의 공유되는 객체를 관리할 수 있다

- Singleton 패턴은 Facade 패턴에서도 하나의 객체를 공유하기 위한 목적으로 사용 될 수 있다

아래 있는건 다른곳에서 퍼온 것 

http://mrnoname.blog.me/130112026691

JAVA 언어로 배우는 디자인 패턴 입문 작가 유키 히로시 출판 영진닷컴 발매 2008.05.01 리뷰보기

http://xper.org/LineReaderTdd/

LineReader TDD 동영상

-- 김창준, 강규영 (2003년 7월)

• LineReaderTdd1.wmv 
  
• LineReaderTdd2.wmv 
  
• LineReaderTdd3.wmv 
  
• LineReaderTdd4.wmv 
  
• LineReaderTdd5.wmv 
  
• LineReaderTdd6.wmv 
  

http://www.javajigi.net/display/OSS/TDD

• Tools

TDD

• Page restrictions apply
• Attachments:47

Added by 오혜진, last edited by 오혜진 on 2월 24, 2006  (view change)

Toggle Space Navigation Tree

Space Map     1차 실무 프로젝트   1차 오픈 소스 스터디   2기 두번째 스터디   2차 스터디   2차 오픈 소스 스터디   AJAX 기본   AJAX 서버측 기술   AJAX 클라이언트측 기술   AOP Concept 과 Spring AOP   Eclipse subproject 분석   Eclipse기본   Eclipse를 활용한 효율적인 팀 개발 및 배포 전략   EclispeDTP   Hibernate in action_김형준   HibernateQuickStart   Hibernate-Sample test with Hibernate 3.1   Hibernate-번역-Sessions and transactions   IBM RAD로 Spring 샘플 만들기   Object-Relational Mapping Strategies   Spring_MVC_2   Spring ORM   Spring 프레임워크 관련한 토론주제   Spring 프레임워크 소개와 IoC 및 Spring IoC의 개념   TDD   TPTP   WEB 2.0에 대한 분석과 향후 발전 방향   강윤기   강현수   고덕성   공식적인 스터디 종료 후 평가   김기훈   김은영   김종국   김중곤   김형준   남연숙   민예원   오혜진   유성희   윤현준   이명섭   이승환   최진영   허광남   3차 오픈 소스 스터디   4차 오픈 소스 스터디   2007study   AtoZ   Object-C스터디(아이폰어플)   Spring framework jpetstore 샘플 분석기   TDD 스터디   Version Control with Subversion   개인별도서목록   경력관리 세미나   서브 스터디   오픈 소스 스터디원 소개

TDD와 JUnit을 이용한 테스팅 방법을 알아보고 효율적인 테스팅 방법에 대해 토의해봅시다. 오픈 소스 스터디 Table of Contents Introduction TDD TDD 따라해보기 TDD의 특징 TDD와 관련된 의문 JUnit JUnit 기본 클래스 JUnit4.0에서의 변경사항 단위 테스트 지침 요약 일반 원칙 자문해 봐야 할 사항 좋은 테스트란? 무엇을 테스트 할 것인가? 프로젝트에서 테스트하기 설계와 관련된 문제들 참고문헌 Introduction 개발자의 테스트 활동이 중요한 이유 초기 단계에서 발견된 결함은 수정이 용이하다. 개발 후기 단계에서 발견된 결함들을 수정하기에는 비용과 시간이 많이 소비되고, 프로젝트가 실패될 확률이 높아진다. 개발 단계에서의 효율적인 테스팅은 전체 프로젝트 시간을 감소시킨다. 테스트의 종류 단위테스트 : JUnit 단위테스트는 단위 코드에서 문제 발생 소지가 있는 모든 부분을 테스트 하는 작업이다.  보통 클래스의 public method 를 테스트 한다.  좋은 단위 테스트란 모든 메서드를 테스트 하는 것이 아니라,  상식 수준의 확인을 통해 단위 코드가 의도한 대로 동작하는지 여부를 판단하는 단계이다.  이상적으로는 코딩전에 테스트 케이스를 작성하여 구현시 보조자료로 활용하는 것이 좋다. ( TDD의 기법 )  단위테스트 후에 개발팀은 테스트를 프로젝트 테스트 스위트에 추가하여 매일 여러번 수행하고 모든 테스트를 항상 통과하게 해야 한다.  기회가 된다면 Code Coverage 를 하는 것이 좋은데 오픈소스로는 JCoverage 등이 있다. 통합/컨테이너 내부 테스트 : Cactus 좋은 단위 테스트는 시스템내의 복잡한 부분에 관계없이 클래스 내의 함수들을 검사하는 것이다.  단위 테스트는 가능한 의존성 없이 독립적으로 처리되어야 한다.  Mock Object 로 테스트를 하는 경우도 있지만,  Cactus 는 J2EE 컨테이너에 접근하는 방법을 제공한다.  컨테이너 안에서 코드 테스트가 가능하도록 하기 위해서 Cactus 는 상세하거나 또는 까다로운  실제와 같은 모형을(mock-ups) 개발자에게 제공한다.  이 방법은 실행되는 코드가 제품이 출시되는 환경에서 실행되기 때문에 또 다른 피드백 기준을 제공한다.  컨테이너 서비스와 상호 작용하는 단일 오브젝트 경우에 컨테이너 내부 테스트를 사용하여 간편한 단위 테스트를 할 수 있다. 수락/기능 테스트 : HttpUnit 기능 테스트는 전체 시스템이 의도한 바대로 동작하는 지를 검사하는 과정이다.  이 방법은 완성된 시스템을 고객으로부터 검사받는 방법이므로 수락 테스트라고도 한다.  기능 테스트는 구조적 기능에 대하여 어떤 프로그램의 기능에 대한 시험이며 진척 상태를 확인하고  이전의 테스트나 누락된 결점을 잡아내거나 미완성 또는 불완전한 부분에서 발생된 문제를 찾아내는 것이 중요하다.  수락 테스트는 고객에 의해 작성된다.  기능 테스트는 항상 100% 구현될 필요는 없으나 제품 출시 전에는 100% 수행 되어야 할것이다.  기능 테스는 종종 매우 구체적인 내용들을 테스트 하기도 한다.  아직은 통괄적인 수락 테스팅 툴은 나오지 않았고 Junit은 어떤 자바클래스에서도 수행될 수 있으나  수락 테스팅 도구는 특정 애플리케이션 요구에 따라 작성되어야 한다.  HttpUnit을 이용하면 테스팅 API를 이용하여 웹 리소스에 대한 호출과 응답 값 조회를 프로그래밍 할 수 있도록 한다. TDD 자동화된 테스트로 개발을 이끌어 가는 개발 방식을 테스트 주도 개발이라 부른다.  TDD는 분석 기술이며, 설계 기술이며, 개발의 모든 활동을 구조화하는 기술이다.  작동하는 깔끔한 코드(clean code that works).  이 핵심을 찌르는 한마디가 바로 테스트 주도 개발의 궁극적인 목표다. 테스트 주도 개발에서는 두 가지 단순한 규칙만을 따른다. 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다. 중복을 제거한다. 또한 위의 두 가지 규칙에 의해 프로그래밍 순서가 다음과 같이 결정 된다. 빨강- 실패하는 작은 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다. 초록- 빨리 테스트가 통과하게끔 만든다. 이를 위해 어떤 죄악을 저질러도 좋다. (죄악이란 기존 코드 복사해서 붙이기-copy and paste, 테스트만 간신히 통과할 수 있게끔  함수가 무조건 특정상수를 반환하도록 구현하기 등을 의미한다.) 리팩토링- 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복들을 제거한다 TDD 따라해보기 MyProject 라는 프로젝트를 만들었다. 메뉴> New> Project TestCase를 생성한다. 이클립스에서는 TestCase와 TestSuite의 기본 템플릿을 제공하고 있다. 메뉴> New> Other을 누르면 다음과 같은 창이 뜬다. 생성할 TestCase 파일 이름 및 테스트 대상 클래스를 입력한다. (①) 만약 setup() 메소드나 teardown() 메소드를 사용할 때는 해당 체크박스를 선택한다. (②) 다음이 생성되었다. 할일 목록을 작성해보자. 작업을 끝낸 항목에는 표시를 하고, 또 다른 테스트가 생각나면 할일 목록에 새로운 항목을 추가할 것이다. 자, 그럼 구현을 하기 위해 어떤 객체가 있어야 할까? 방금 이건 속임수다. 객체를 만들면서 시작하는 게 아니라 테스트를 먼저 만들어야 한다.  앞에서 언급한 TDD의 주기중 현재 단계는 빨강이다. 그렇다면 어떤 테스트가 필요할까? 할일 목록을 보니 첫번째 테스트는 좀 복잡해보인다. 작은 것부터 시작하든지, 아니면 손을 대지 않는 게 좋겠다. 이번엔 다음 항목인 곱하기를 보자.  대단히 어렵진 않겠지? 이걸 먼저 하는게 좋겠다. testMultiplication이라는 테스트를 추가해보자. 다음 코드를 돌리면 당연히 에러가 난다. 메뉴> Run As> JUnit Test 할일 목록에 3가지를 추가한다. 빨간 막대기를 가능하면 빨리 초록 막대기로 바꾸고 싶다. 실행은 안 되더라도 컴파일만은 되게 만들고 싶은데, 가장 쉬운 방법이 뭘까?  이번 단계는 TDD주기에서 빨강에서 초록으로 넘어가는 과정이다. 현재 네 개의 컴파일 에러가 있다. Dollar 클래스가 없음 생성자가 없음 times(int) 메서드가 없음 amount 필드가 없음 네개의 컴파일 에러를 없앨 수 있는 가장 빠른 방법은 다음을 테스트 코드 아래 추가하는 것이다. 당장의 목표는 완벽한 해법을 구하는 것이 아니라 테스트를 통과하는 것일 뿐이므로 최소한의 작업을 수행한다. 테스트를 다시 실행해보자. 드디어 초록색 막대가 나타났다. 하지만 아직 주기가 완성되지 않았으니까 서둘지 않는게 좋겠다. 우리는 TDD의 주기중 빨강/초록을 넘었다. 다음 단계는 리팩토링이다.코드를 다음과 같이 바꿔준다. 테스트는 통과하고 테스트 막대 역시 초록색이다. 우리는 여전히 행복하다. 이 단계가 너무 작게 느껴지는가? 하지만 기억하기 바란다. TDD의 핵심은 이런 작은 단계를 밟아야 한다는 것이 아니라, 이런 작은 단계를 밟을 수 있는 능력을 갖추어야 한다는 것이다. 5를 어디서 얻을 수 있을까? 이건 생성자에서 넘어오는 값이니 이걸 다음과 같이 amount 변수에 저장하면, 그걸 time()에서 사용할 수 있다. 인자 multiplier의 값이 2이므로, 상수를 이 인자로 대체할 수 있다. 마지막으로 우리가 자바 문법을 완벽하게 알고 있다는 것을 보여주기 위해 *=연산자를 써주자.( 물론 중복을 제거하기 위해서다. ) 이제 첫 번째 테스트에 완료표시를 할 수 있게 되었다. 마무리 - 우리는 다음과 같은 작업들을 해냈다. 우리가 알고 있는 작업해야 할 테스트 목록을 만들었다. 오퍼레이션이 외부에서 어떻게 보이길 원하는지 말해주는 이야기를 코드로 표현했다. JUnit에 대한 상세 사항들은 잠시 무시하기로 했다. 스텁 구현을 통해 테스트를 컴파일했다. 끔찍한 죄악을 범하여 테스트를 통과시켰다. 돌아가는 코드에서 상수를 변수로 변경하여 점진적으로 일반화했다. 새로운 할 일들을 한번에 처리하는 대신 할일 목록에 추가하고 넘어갔다. TDD의 특징 격리된 테스트 테스트 목록 테스트 우선 단언 우선 명백한 데이터 TDD와 관련된 의문 단계가 얼마나 커야 하나? 테스트 할 필요가 없는 것은 무엇인가? 좋은 테스트를 갖췄는지의 여부를 어떻게 알 수 있는가? TDD로 프레임워크를 만들려면 어떻게 해야하나? 피드백이 얼마나 필요한가? 테스트를 지워야 할 때는 언제인가? 프로그래밍 언어나 환경이 TDD에 어떤 영향을 주는가? 거대한 시스템을 개발할 때도 TDD를 할 수 있는가? 애플리케이션 수준의 테스트로도 개발을 주도할 수 있는가? 프로젝트 중반에 TDD를 도입하려면 어떻게 해야 할까? TDD는 누구를 위한 것인가? TDD는 초기 조건에 민감한가? TDD와 패턴의 관계는? 어째서 TDD가 잘 동작하는가? TDD와 익스트림 프로그래밍의 실천법 사이에는 어떤 관련이 있는가? JUnit ▪ 다운로드 : http://www.junit.org/ JUnit 기본 클래스 1. TestCase 클래스 : 가장 간단하게 Junit을 사용하는 방법은 TestCase 클래스를 상속받은 클래스를 작성하는 것이다. 이 클래스에는 test로 시작하는 메소드만 나열하면 된다. 2. TestSuite 클래스 : testCase 클래스를 상속받은 클래스만을 사용하다 보면, 일부의 test 메소드는 간혹 실행하지 않고 싶거나 특정한 test 메소드만 실행하고 싶을 때가 생긴다. (①) 또는 Test 클래스를 한데 묶어서 한꺼번에 실행하고 싶은 경우(②)도 발생한다. 이때 사용하는 것이 바로 TestSuite이다. 3. Assersions 4. Fixture : 초기 값 설정 및 해제 - setUp(), teardown() JUnit4.0에서의 변경사항 Test Annotation 이전 버전에서 사용했던 TestCase를 대신에 org.junit.Test를 임포트하여 다음과 같은 형식으로 사용한다. @Test public void functionName() { } Expected Exception @Test Annotation은 "expected" 라는 파라메터를 option 으로 가지고 있는데 이것은 Throwable의 서브 클래스들을 값으로 취한다. @Test(expected= IndexOutOfBoundsException.class) public void empty() { new ArrayList<Object>().get(0);  } Timeout @Test Annotation은 long형 파라메터를 통해 timeout을 설정할 수 있다. @Test(timeout=100) public void infinity() Unknown macro: { for ( ; ; ); } Fixture setup - Before Annotation import org.junit.Before; @Before public void functionName() tearDown - After Annotation import org.junit.After @After public void functionName() Ignore Annotation 때때로 일시적으로 테스트를 작동시키지 않을 때가 있는데 Ignore이라는 Annotation을 사용할 수 있다.  Ignore하는 이유를 옵션 파라메터를 통해 기록할 수 있다. @Ignore("not ready yet") @Test public void something() 단위 테스트 지침 요약 일반 원칙 망가질 가능성이 있는 모든 것을 테스트한다. 망가지는 모든 것을 테스트한다. 새 코드는 무죄가 증명되기 전까지는 유죄. 적어도 제품 코드만큼 테스트 코드를 작성한다. 컴파일 할 때마다 지역 테스트를 실행한다. 저장소에 체크인하기 전에 모든 테스트를 실행해 본다. 자문해 봐야 할 사항 이 코드가 옳게 동작한다면 어떻게 그것을 알 수 있는가? 이것을 어떻게 테스트할 것인가? ''''' 어떤 것이 잘못될 수가 있는가? 이와 똑같은 종류의 문제가 다른 곳에서도 일어날 수 있을까? 좋은 테스트란? 좋은 테스트는 'A- TRIP' 해야 한다. 자동적('A'utomatic) 테스트가 혼자 실행되고 자신을 검증할 수 있어야 한다. 철저함('T'horough) 반복 가능('R'epeatable) 모든 테스트가 어떤 순서로든 여러 번 실행될 수 있어야 하고, 그때마다 늘 같은 결과를 내야 한다. 독립적('I'ndependent) 확실히 한 대상에 집중한 상태여야 한다. 환경과 다른 개발자들에게서 독립적인 상태를 유지해야 한다. 어느 테스트도 다른 테스트에 의존하지 않는다. 전문적('P'rofessional) 좋은 설계를 위한 모든 일반적인 규칙, 캡슐화 유지, DRY 원칙 지키기, 결합도 낮추기 등은 제품 코드에서 그랬듯이 테스트 코드에서도 반드시 지켜져야 한다, 무엇을 테스트 할 것인가? : Right-BICEP (오른쪽 이두박근이라는 뜻) Right - 결과가 옳은가? 예)  B - 모든 경계('B'oundary) 조건이 correct 한가? <경계 조건에서 확인해봐야 할 사항들 - 'CORRECT'> 형식 일치('C'onformance) - 값이 기대한 형식과 일치 하는가? 예) 최상위 도메인 이름이 없는 이메일 주소 fred@foobar 이 넘어온다면?) 순서('O'rdering) - 적절히 순서대로 되어 있거나 그렇지 않은 값인가? 예) 범위('R'ange) - 적당한 최소값과 최대값 사이에 있는 값인가? 예)  참조('R'eference) - 코드가 자기가 직접 제어하지 않는 외부 코드를 참조하는가? 예)  존재성('E'xistance) - 값이 존재 하는가? 예) null이 아님, 0이 아님, 집합 안에 존재함) 개체 수('C'ardinality) - 확실히 충분한 값이 존재하는가? 개수를 정확히 필요한 만큼 갖고 있다던가, 정확히 필요한 만큼 만들었다는 것을 확인해야 한다. 예) 울타리 기둥 에러, 하나 차이에 의한 오류 시간 ('T'ime) (절대적으로 그리고 상대적으로) - 모든 것이 순서대로 일어나는가? 제시간에? 때 맞추어? 예) 로그인하기 전에 문서를 출력하려고 시도하는 것 I - 역('I'nverse) 관계를 확인할 수 있는가? 예)  C - 다른 수단을 사용해서 결과를 교차 확인('c'ross-check) 할 수 있는가? 예)  E - 에러조건('e'rror condition)을 강제로 만들어 낼 수 있는가? 현실 세계에서는 에러가 발생한다. 여러분은 강제로 에러를 일으켜 코드가 현실 세계의 문제를 제대로 처리한다는 것을 테스트 할 수 있어야 한다.  네트워크 에러 등을 시뮬레이션 하는 경우 모의객체(mock object)를 사용할 수 있다. P - 성능('P'erformance) 특성이 한계 내에 있는가? 예)  프로젝트에서 테스트하기 1. 테스트 코드를 어디에 둘 것인가? 같은 디렉터리 장점: TestAccont가 Account의 보호된 멤버 변수와 메서드에 접근할 수 있다. 단점: 테스트 코드가 제품 코드 디렉터리의 공간을 잡아먹으면서 어질러져 있다. 하위 디렉터리 장점: 태스트 코드를 적어도 제품 코드와 똑 같은 디렉토리에 있지 않게 떨어뜨려 놓을 수 있다. 단점: 테스트 코드가 다른 패키지에 있으므로 필요한 멤버들을 노출시키는 제품 코드의 하위 클래스를 사용하지 않는다면 테스트 코드는 보호된 멤버에 접근할 수 없다. 병렬 트리 장점: 테스트 코드와 제품 코드가 정말로 분리되었다. 테스트 코드가 같은 패키지에 있기 때문에 선택적으로 접근할 수 있다. 단점: 편하게 쓰기에는 너무 멀리 떨어져버린 건지도 모른다. 2. 테스트 예절 혼자하는 테스트와 다른 사람과 함께하는 테스트의 가장 큰 차이점은? 테스트 코드의 동기화 팀 환경에서 코드를 체크인 할 때는, 그 코드가 단위 테스트를 완료하였고,모든 단위 테스트가 통과했다는 것을 확인해야한다. 사실상, 전체 시스템의 코든 테스트가 새로운 코드에 대해 계속 통과해야 한다. 잠재적 위반사항 목록을 만들자 불완전한 코드(예: 클래스 파일 하나만 체크인 하고 그것이 의존할 수 있는 다른 파일은 체크인 하는 것을 잊어버린 경우) 컴파일 되지 않는 코드 컴파일 되기는 하지만, 다른 코드를 망가뜨려서 컴파일 되지 않게 만드는 코드 대응하는 단위 테스트가 없는 경우 단위테스트가 실패하는 코드 자신의 테스트는 통과하지만, 시스템의 다른 테스트를 실패하게 만드는 코드 3. 테스트 빈도 새 메서드를 작성할 때마다 지역 단위 테스트들을 컴파일하고 실행한다. 버그를 고칠 때마다 버그를 드러내는 테스트를 시행한다. 성공적으로 컴파일 할 때마다 지역 단위 테스트들을 실행한다. 버전 관리 시스템에 체크인할 때마다 모든 모듈 또는 시스템의 단위 테스트들을 실행한다. 따로 배정된 특정 컴퓨터가 자동으로 하루 종일(주기적으로, 또는 버전 관리 시스템에 체크인 할 때마다), 처음부터 전체 빌드와 테스트를 수행하고 있어야 한다. 4. 테스트와 레거시 코드 이미 있던 코드의 경우 : 가장 망가진 부분을 위한 테스트를 가장 먼저 추가하는 편이 좋다. 이런 환경에서 실시하는 단위 테스트는 뒷걸음 질을 막는다.  즉, 유지 보수하기 위해 수정하고 개선하다가 이미 있는 부분들에 버그를 만들어 내는 죽음의 나선을 피할 수 있다. 연속적 빌드-테스트 프로그램을 사용하여 코드가 저장소에 전송될 때마다 자동으로 단위테스트가 실행되게 만든다면 불량코드가 전체 회사에 돌아다니는 일을 방지할 수 있다. 빌드-테스트 프로그램의 오픈소스제품 CruiseControl http://cruisecontrol.sourceforge.net AntHill http://www.cs.unibo.it/projects/anthill/ Tinderbox http://www.mozilla.org/tinderbox.html 5. 테스트와 검토 코드 검토를 수행할 때, 그 검토과정의 필수 구성요소로 테스트 코드를 끼워넣어라 코딩과 검토를 다음 순서로 하면 좋다 테스트 케이스나 테스트 코드, 둘 다를 작성한다. 테스트 케이스나 테스트 코드, 또는 둘 다를 검토한다. 테스트 테이스나 테스트 코드, 또는 둘 다를 검토할 때마다 수정한다. 테스트를 통과하는 제품 코드를 작성한다. 제품코드와 테스트 코드를 검토한다. 검토할 때마다 테스트 코드와 제품코드를 수정한다. 모든 팀원을 이 과정에 참여시킴으로써 팀의 의사소통을 증진시킬 수 있다. 다른 이들이 어떻게 테스트 하는지, 팀의 규칙이 무엇인지 알게된다. 설계와 관련된 문제들 1. 테스트의 용이성을 높이는 설계 2. 테스트를 위한 리팩토링 3. 클래스의 불변성(invariant)을 테스트 하기 구조적 주문 정보 입력 시스템은 다음과 같은 불변성을 가질 수 있다. 모든 개별 항목은 어떤 주문에 속해야 한다. 모든 주문은 개별 항목 하나 이상을 가져야 한다. 데이터 배열을 다룰 때 인덱스 노릇을 하는 멤버 변수는 다음과 같은 불변성을 가질 수 있다. 인덱스는 >=0이어야 한다. 인덱스는 < 배열 길이여야 한다. 수학적 은행 계좌의 입금 부분과 출금 부분을 계산하면 잔고와 맞아 떨어져야 한다. 다른 단위로 측정된 양은 변환 후에 맞아떨어져야 한다. 데이터의 정합성(consistency) 쇼핑 카트에 들은 항목 목록, 전체 판매액, 그 쇼핑 카트에 들은 전체 항목 개수는 밀접한 관련이 있다. 항목 목록의 구체적인 내용을 알면, 다른 두 수치를 이끌어 낼 수 있다. 이 수치들이 조화를 이루어 맞아  떨어진다는 사실은 불변성이 되어야 한다. 참고문헌 이클립스 기반 프로젝트 필수 유틸리티 CVS,Ant,JUnit (민진우 & 이인선 공저, 한빛미디어) 테스트 주도 개발 (켄트 벡 저, 김창준 & 강규영 역,인사이트) 실용주의 프로그래머를 위한 단위 테스트 with JUnit (데이비스 토머스 & 앤드류헌트 공저, 이용원 & 김정민 역, 인싸이트) 참고 싸이트 - TDD를 공부하고 싶다면? http://wiki.tdd.or.kr/wiki.py http://c2.com/cgi/wiki?TestDrivenDevelopment http://xper.org/wiki/xp/ 문서에 대하여 최초작성자 : 오혜진 최초작성일 : 2006년 2월 19일 버전 : 1.0 ? ㅎㅎ  문서이력 : 2005년 2월 19일 오혜진 문서 최초 생성 2005년 2월 20일 JUnit4.0에서의 변경사항 추가 2005년 2월 21일 오픈소스스터디 1기 장회수님 자료 참고하여 보완, 테스트의 종류 추가 2005년 2월 24일 프로젝트에서 테스트하기 항목 추가 및 문서 구조 수정

http://cafe.naver.com/vslinlin/50

먼저 [3탄] TortoiseSVN을 이용한 업데이트 글에 다시 빌드하라는 내용은 빠졌는데
혹시나 하고 모르실 수도 있기에 언급해드립니다.
업데이트 하신 후 소스 수정하시고 빌드하지 않으면 업데이트 하나마나입니다.^^
까먹지 마시길...



이번에 다뤄질 내용은 TortoiseSVN 응용입니다.

검색을 활용하면 얼마든지 사용법은 나옵니다.
그래서 여기서는 소스구축 후 패치파일 제작과 적용만 소개하고자합니다.

업데이트 할 때마다 매번 config 폴더의 파일을 수정해야합니다.
물론 처음 시작할 땐 일부로라도 그렇게 진행하시는 게 좋습니다.
구축 후 설정법을 익히는 데 도움이 될 수도 있습니다.

이제 매번 똑같은 설정 바꾸기 귀찮아지게 되면 한번쯤 "쉽게 하는 방법 없을까"라는
고민은 대부분 구축해본 분들이라면 해보셨을꺼라 생각합니다.
물론, 여러가지 방법이 있지만 여기서는 TortoiseSVN으로 패치파일을 만들고
다시 적용하는 법을 소개하겠습니다.

1. 주요 변경파일 패치파일 제작

우선 아래의 폴더로 이동해서 각각의 파일들을 본인 서버 구성에 맞게 수정합니다.
수정할 때는 EditPlus 등의 프로그램을 이용하시면 편리합니다.

수정을 다 마치고 저장하면 아래 그림처럼 아이콘에 느낌표 표시가 생깁니다.
이 느낌표의 의미는 내용이 원본 소스와 다르게 수정이 되었다는 의미지
파일에 문제가 있다는 표시가 절대 아닙니다.


해당 아이콘의 설명은 TortoiseSVN 설정에 보면 나와있으니 참고하세요.


아래와 같은 방법으로 패치파일을 만들겠습니다.
소스 최상위 폴더 오른쪽 마우스 클릭 -> -> TortoiseSVN -> 패치 생성


수정된 내역이 뜨고 체크가 된 파일들에 대한 패치 파일을 만들겠다는 내용입니다.


"저장 위치"를 선택하고 "파일 이름"을 쓴 다음 "저장" 버튼을 눌러주세요.


아래 그림처럼 패치파일의 내용을 보여 주면서 지정한 위치에 파일이 저장됩니다.


이로써 다음에 업데이트 후 한방에 변경하기 위한 패치파일 제작은 끝났습니다.


2. 리비전 업데이트하기 전 되돌리기

일단, 소스에 인위적인 수정이 들어갔으므로
업데이트 하기 전에 원본 소스로 되돌리는 작업을 진행합니다.
이유는 업데이트시 충돌이 발생할 수도 있기 때문입니다.
방법은 매우 간단합니다.
노보팩 기준으로 \SVN AIONEmu Source\aion-emu 오른쪽 마우스 클릭해서
아래 그림처럼 되돌리기를 실행해줍니다.
여기서 되돌리기란 원본 리비전으로 복원한다는 의미입니다.


모두 선택하고 확인을 누릅니다.


모두 진행된 후 확인을 눌러주면 원본 리비전으로 복원됩니다.



3. 리비전 업데이트

리비전 업데이트 합니다. 방법은  [3탄] TortoiseSVN을 이용한 업데이트 글에 나와있습니다.


4. 패치하기

빌드를 진행하기 전에 먼저 만들었던 패치파일을 이용해서 패치를 진행합니다.
패치파일에서 오른쪽 마우스 클릭해서 하는 방법과
소스폴더에서 오른쪽 마우스 클릭해서 하는 방법이 있습니다.

여기서는 패치파일에서 패치적용을 진행해보도록 하겠습니다.
아래와 같이 만들어진 패치파일을 오른쪽 마우스클릭 -> TortoiseSVN -> 패치 적용 클릭합니다.


위에서 패치 새성할때 소스의 최상위 폴더를 선택했듯이 패치 적용시에도 동일하게 선택합니다.


아래와 같은 창이 뜨면서 패치될 파일들을 보여주게 되는데그 창에서
오른쪽 마우스 클릭 -> Patch all을 실행합니다.
각각의 파일을 더블클릭하면 어떻게 수정이 되는지 TortoiseMerge를 통해서 확인할 수도 있습니다.


아래 그림처럼 패치가 완료되면 파일리스트 색상이 회색으로 바뀌면서
마지막 파일의 패치전과 패치후가 TortoiseMerge에 보여지게됩니다.


이로써 매번 수정해야하는 주요 설정 파일을
미리 만들어둔 패치파일을 통해 간단히 변경할 수 있습니다.

간혹 패치될 원본소스가 이전과 다르게 업데이트 되어 수정되는 경우도 있습니다.
그럴땐 패치될 파일을 보여줄때 빨간색으로 간혹 나오기도합니다.
TortoiseMerge라는 프로그램이 충돌한 파일을 해결하는 역할도 하긴 하는데
되도록이면 이럴 경우엔 강제로 진행하기보다는
일단은 빨간색으로 나온 파일을 더블클릭해서


정상적으로 바뀌는 지 확인 한 후 패치를 진행하도록 합니다.
아래 내용의 뜻은
- 라고 표시되는 줄을 삭제하고
+ 라고 표시되는 줄을 넣겠다는 의미입니다.


다른 사람이 올린 패치파일을 적용하다보면 위와 같은 상황이 많이 생깁니다.
제가 마지막으로 올린 패치파일(유닉2021_kit_end.patch)도 현재 최신리비전에 적용시 충돌이 발생하며
정상적으로 병합도 되지 않는 문제가 발생합니다.
이를 개인적으로 충돌이 나지 않게 해결하는 방법은 분명히 있습니다.
원본과 패치되는 부분을 자세히 비교해서 수동으로 수정해 주는 것이 가장 현명하다고 판단됩니다.

이제 빌드하고 서버 구동하면 됩니다.
수고하셨습니다.

Global ignore Pattern : 부분에

아래와 같이 쓴다

*.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store *.Debug Debug *.Release Release ipch *.sdf *.ipch *.exe *.ncb *.opt *.plg *.vsp *.lib LIBD LIB dump *.dmp errorReport log

http://www.phpk.org/archives/181

프로그램을 개발하면서 SVN 서버가 필요한 경우가 있습니다. VisualSVN Server는 Windows 기반에서 간편하게 SVN 서버를 구성해 줍니다.

웹 사이트에서 VisualSVN Server를 내려 받으신 후 msi 파일을 실행하면 설치를 시작합니다.

화면 1 VisualSVN Server 설치 시작 화면

VisualSVN Server는 Apache 웹 서버와 Subversion을 포함하고 있습니다. 이미 설치하려는 시스템이 Apache가 설치되어 있어도 Apache가 사용하는 포트가 중복되지만 않는다면 문제 없이 사용할 수 있습니다.

화면 2 서버 설정 화면

VusialSVN Server를 설치할 위치와 소스 코드를 저장할 저장소(Repositories) 위치를 지정할 수 있습니다. 기본 서버 포트는 8443이며 SSL을 통해 접속하게 되어 있습니다. SSL을 사용할 필요 없으시다면 Use secure connection에 V 표시를 없애면 됩니다.

인증 (Authencation)에서는 VisualSVN Server에서 사용자 그룹과 사용자를 관리할 것인지 Windows 에 이미 지정된 사용자 그룹과 사용자 정보를 사용할 것인지를 선택합니다.

Subversion authentication과 Windows authentication 차이

인증 방법의 차이는 아래 화면처럼 Subversion authentication을 선택하면 VisualSVN Server에서 사용자 그룹을 생성하고 사용자를 관리할 수 있습니다. 반면 Windows authentication 을 선택하면 Windows 에 등록된 사용자 이름과 비밀번호로 접근할 수 있습니다.(제어판 -> 사용자 계정)

여러 사람과 같이 사용해야 하는 경우라면 Subversion authentication을 사용하는 것이 보다 안전할 것으로 생각됩니다.

화면 3 Subversion authentication 사용 화면

설치 후 가장 먼저 사용자를 추가합니다. 원하는 사용자 이름과 비밀번호를 입력하여 사용자를 추가합니다.

화면 4 사용자 추가 화면

그리고 사용자 그룹을 만듭니다. 원하는 사용자 그룹 이름을 입력합니다. 사용자 그룹 추가 화면 아래 Add 버튼을 클릭해서 사용자 그룹에 포함할 사용자를 선택합니다.

화면 5 사용자 그룹 추가 화면

화면 6 사용자 그룹에 사용자를 추가하는 화면

이제 왼쪽 트리 화면에서 VisualSVN Server를 선택하여 시작 화면으로 돌아오면 오른쪽 화면의 Status 항목에 SVN Server URL을 클릭하여 저장소에 접근할 수 있습니다.

Internet Explorer로 URL에 접속하면 보안 인증서에 문제가 있다는 경고 화면을 보게 됩니다. 이 경고는 SSL 인증서가 사설 인증서라는 것을 알려주는 것인데 VisualSVN Server에서 https 사용으로 선택했기에 나타나는 화면이므로 “이 웹 사이트를 계속 탐색합니다(권장하지 않음).”을 선택하면 됩니다.

화면 7 보안 인증서 문제 안내 화면

사용자 이름과 비밀번호를 입력하면 VisualSVN Server의 SVN 저장소를 볼 수 있습니다.

화면 8 VisualSVN Server의 SVN 저장소 화면

저장소 생성

SVN 저장소는 시작 화면에서 “Create new repository…” 를 선택하거나 마우스 오른쪽 버튼을 눌러 문맥 메뉴를 통해 생성할 수 있습니다.

화면 9 저장소 생성 문맥 메뉴

저장소 생성 창이 뜨면 저장소 이름을 입력합니다. 개발팀에서 사용할 저장소라면 화면과 같이 DevTeam 이라고 짓는 것도 좋은 예입니다.

화면 10 저장소를 생성하는 화면

저장소가 생성되면 화면 왼쪽에 DevTeam 이 추가됩니다. 이제 화면 오른쪽 상단에 있는 URL을 SVN 클라이언트를 이용해 접속하면 소스 코드를 관리할 수 있습니다.

화면 11 저장소가 생성된 화면

VisualSVN 웹사이트 : http://www.visualsvn.com/

지난번 svn 설치방법에 대해 포스팅 한 후 드디어 svn 연동을 해 보았다!!!!

이번 소프트웨어실습3 프로젝트를 위해서 서버를 임대를 하여 svn을 설치하고 기타 등등을 설치해서 활용을 하려 했으나 금전적 이유로 인해 고민중에 병희형에게 구글code에 대해 듣게 되었다.

구글 code에서 새로운 프로젝트를 생성하며 원하는 소스 관리 툴을 선택하게끔 되어 있으며 난 svn을 선택하였다.

자! 이제 연동을 해보자!

지금부터 진행 될 내용은 일단 svn이 뭐하는 것인지 알고 있으며, 해당 url과 계정을 가지고 있으며, visual studio에 이전에 포스팅한 svn 설치 방법대로 설치했다는 가정 하에 진행하겠다!

Step1. 해당 Subversion 메뉴 접근

Step2. 해당 Subversion Url 입력

위 그림의 작은 박스 안의 아이콘을 클릭하면 Url을 입력할 수 있는 화면이 활성화 된다. 우리가 알고 있는 Svn 레파지터리 Url을 입력 후 Ok 버튼 클릭

Step3. 해당 Svn 레파지터리 내에서 프로젝트 선택

해당 Svn Url이 유효하다면 위와 같이 하위 폴더들이 노출 된다.

우리가 원하는 프로잭트 파일을 선택하여 Open 버튼을 클릭 해준다. 

필자는 이미 Svn 계정 정보를 입력하였으며 저장하기를 하였기 때문에 노출이 안되었다.

계정이 없을 경우 Svn 관리자에게 생성 요청을 하자!

Step4. 해당 프로잭트를 Check out 받을 위치 선택

본인이 원하는 Local Directory를 선택 하고 OK 버튼 클릭

Step5. 해당 프로잭트를 Check out 중!!!!!! 두둥!

Step6. 간단한 Svn 연동한 프로젝트 파일 구성

 빨강 박스로 된 파일(Program.cs)과 파란채크표시가 된 프로젝트 등이 보일것이다.

빨강 박스로 된 파일, 폴더, 프로잭트는 Commit할 대상

파란 채크 표시가 된 파일, 폴더, 프로잭트는 최종적으로 자신이 checkout이나 update받은 대상

간단한 SVN용어 설명

Commit - 우리 로컬에 있는 파일 등을 Svn에 반영하는 작업

Update - 우리 로컬에 있는 파일에 Svn의 최신버전으로 변경하는 작업 ( 만약 수정중파일(빨강박스)의 경우 충돌이 발생할수 있음, 이건 적절한 경험을 해봄으로 습득 가능)

Checkout - 우리 로컬에 최초로 Svn 레파지터리에 있는 것을 다운 받는 작업

Step7. 간단한 바로가기 메뉴 설명

필요한 메뉴 항목에 대해서만 설명

Commit - svn서버로 반영

Show Changes - 현재 파일과 svn서버에 있는 파일과 비교

View History - 해당 파일이나 선택한 폴더 등의 이력을 노출

Revert - 현재 파일의 버전으로 원복(최신이 아닌 것을 유념)

 View History

 

 Show Changes

 

Revert

 

 

Commit - Log Message를 남겨주는 것은 필수!

자 이상으로 SVN 연동 및 테스트는 끝이 났다!

AnkhSvn-2.3.10838.vol1.egg 

AnkhSvn-2.3.10838.vol2.egg 

AnkhSvn-2.3.10838.vol3.egg

SVN을 사용해 왔기에

Visual studio 2010에서도 svn을 사용하기 위하여 설정 해 보았다.

http://ankhsvn.open.collab.net/downloads

무슨 정보등을 입력해야 한다... ㅎㅎ

파일첨부를 하였으니 다운받아 압축 풀고 긍정적인 방향으로 설치 하길 바라다.

visual studio가 켜져 있었다면 프로그램 재시작~

1. 도구 > 옵션 으로 들어간다.

2. 아래와 같은 화면의 메뉴에서 플러그인 변경

3. 변경 후 아래와 같이 svn 사용이 가능해진다. 

4. 연동은 추후 해본 후 블러깅 하겠당~

 AnkhSVN

http://ankhsvn.open.collab.net/

출처 : http://yonomi.net/?p=87

Visual Studio 2010에서도 Subversion을 이용해서 형상관리를 할 수 있게 되었나보다.

   

-연속메모리 컨테이너 : vector, string( or rope), deque = 배열로 이루어졌으며 재하당 이 일어날 수 있다

-노드기반 컨테이너 :  set, multiset,map,multimap, 요소 삽입을 임의의 위치에서 삽입 불가능( 순서가 있으므로 )

                               (balanced tree 로 구성됨)

-해쉬컨테이너와 slist(단일연결리스트) 의 경우 양방향 반복자로 접근될 수 없다

-배열 구조와 호환되어야 한다면 vector밖에 쓸 수 있는게 없다

-탐색속도가 관심사라면 => 1.해쉬컨테이너, 2.정렬된 vector, 3. 표준 연관(set,map, 외..) 컨테이너 중 하나 의 순으로 접근한다

- 참조카운팅이 고려할때는 string 을 쓰지 말 것(string 내부에서 참조카운팅을 사용 할 수 있다=> 동일한 문자열에 대한 참조카운팅 )

   rope 또한 마찬가지 => 참조 카운팅 기반으로 구현되어 있다

   : 대신할 수 있는 것 vector<char>

-트렌젝션이 가능하거나 포인터,반복자, 참조가의 무효화가 최소화 되어야 하는가? => 노드기반 컨테이너( list, set, map )

삽입 

set,map 의 경우 push_back, push_front 를 지원하지 않는다 => insert 로 써야 함, 순서유지

list 의 경우에는 지원

예약

vector 에서는 reserve,capacity 가 있지만 list, deque 에서는이 멤버함수가 없다(내부 구조 때문)

이펙티브 STL 카페

http://cafe.naver.com/ArticleList.nhn?search.clubid=10513818&search.menuid=59&search.boardtype=Q

이펙티브 STL 게시글

http://cafe.naver.com/cppstl.cafe?iframe_url=/ArticleList.nhn%3Fsearch.clubid=10513818%26search.menuid=59%26search.boardtype=Q

http://cafe.naver.com/cppstl