익스트림 프로그래밍(XP, eXtream Programming)이라는 방법은 최근의 소프트웨어 개발 방법론 분야에 새로 등장했다. 많은 사람들이 "프로그래머들이 정말 원하는 방법" 이라고 하는 XP는 90년대말에 등장했으면 두명으로 구성된 조그만 회사에서 포드 자동차에 이르기까지 다양한 규모의 회사에서 쓰이고 있다.

XP의 가장 큰 장점은 막판에 스펙에 변경되는 일이 있어도 고객이 원하는 것을 고객이 원하는 기한에 맞춰서 제공할 수 있다는 점이다.
XP는 서로 조화롭게 쓸 수 있도록 계획된 일련의 규칙이 있다. 물론, 그 가운데 일부만을 채택하고 있는 프로그래머도 많이 있긴 하다.
규칙에는 다음과 같은 것들이 있다.

- 조금씩, 하지만 자주 발표한다.
- 사이클을 반복해서 돌리면서 개발한다.
- 스펙에 없는 것은 절대 집어넣지 않는다.
- 테스트 코드를 먼저 만든다.
- 야근은 하지 마라. 항상 정규일과 시간에만 작업한다.
- 기회가 생기는 족족 언제 어디서든 코드를 개선한다.
- 모든 테스트를 통과하기 전에는 어떤것도 발표하지 않는다.
- 조금씩 발표하는 것을 기반으로 하여 현실적인 작업 계획을 만든다.
- 모든일을 단순하게 처리한다.
- 두 명씩 팀을 편성하고 모든 사람이 대부분의 코드를 알 수 있도록 돌아가면서 작업한다.

- Head first Java 中-

구조 패턴은 복잡한 구조를 이루는 클래스들을 어떻게 하면 개발하기에도 쉽고 보기에도 좋은 형태를 만들어 줄 것인가에 대한 답을 제시해 준다. 구조 패턴을 이용해서 시스템을 구축하면 새로운 기능을 가진 복합객체를 효과적으로 작성할 수 있다.

구조패턴에는

1. Facade 패턴
2. Adapter 패턴
3. Bridge 패턴
4. Composite 패턴
5. Decorator 패턴
6. Flyweight 패턴
7. Proxy 패턴

1. Facade 패턴

일반적으로 프로젝트를 수행할 때, 하나의 목적을 위해 여러개의 오브젝트들이 유기적으로 연결되게 된다. 이때, 오브젝트들을 묶을 수 있다고 판단이되면, 별도의 오브젝트를 새롭게 만들어 사용자들에게 새롭게 만든 오브젝트의 인터페이스를 이용하여 다른 오브젝까지 모두 사용할 수 있게 만들수 있다. 이처럼 대표 인터페이스를 이용하여 다른 여러 오브젝트를 사용할 수 있게 만드는 패턴이 바로 Facade 패턴이다.

2.  Adapter 패턴

어댑터 패턴은 기존에 존재하는 클래스를 직접 변경하지 않고도 원하는 형태의 인터페이스를 가지게 만드는데, 효과적으로 사용할 수 있는 패턴이다. 외부에서 돈을 주고 구입한 클래스나 다른 부서가 개발한 클래스들이 적용하고자 하는 시스템에 적합하지 않을 경우, 시스템을 변경하지 않고도 이들 클래스를 활용할 수 있는 방법을 제공한다.

3. Bridge 패턴

브리지 패턴은 어댑터 패턴과 팩토리 패턴을 합친 것 같은 패턴으로 이들의 장점을 시스템에 적용한 패턴이다. 이를 간단히 설명하면 동일한 조상을 가진 객체들은 팩토리 패턴을 이용하여, 객체의 생성을 추상화해서 객체들을 사용하는 모듈과 이들을 분리시키지만, 동일한 조상을 가지지 않았거나 동일한 인터페이스를 소유하지 않은 객체는 팩토리 패턴을 적용하기 어렵다. 브리지 패턴은 어댑터 패턴을 이용하여 같은 조상을 가지지 않은 시스템구조에 팩토리 패턴을 적용할 수 있도록 만들어 주는 패턴이다.

4. Composite 패턴

객체집단을 다루는데 유용한 컴포짓패턴은, 시스템이 집합속에 포함될 객체와 집합을 가지고 있는 객체, 이들 모두가 자기 사진과 동일한 타입(메소드와 데이터)의 객체리스트를 가지게 한다. 그래서 객체리스트에 객체를 삽입하거나 삭제하는 방법으로, 객체집단을 기존의 집단에 신속하게 벗붙이고 삭제하는 작업을 수행할 수 있게 만든다. 그리고 객체집단의 어느 특정한 부분에 명령을 전달하면 특정 부위의 객체집단 모두가 그 명령을 수행하게 만드는 구조를 가진다.

5. Decorator 패턴

데코레이터 패턴은 장식자라는 이름에서도 알 수 있듯이, 특정 객체를 원하는 모양(기능)으로 장식시켜주는 객체를 만들어 준다. 즉, 장식 시켜주는 객체들과 장식 받을 객체들을 만든 뒤, 이들을 이용하여 장식 바은 객체가 원하는 모양이되도록 만들어 주는 것이다. 이대, 기존의 객체(장식받을 객체)를 활용하고 있던 모듈은 장식이 이루어지는 것과 무관하게 작동하도록 한다.

6. Flyweight 패턴

Flyweight 패턴은 시스템 속에 유사한 클래스나 객체의 난립을 줄여주는 역할을 한다. Flyweight 패턴은 데이터를 관리하고 있다가 시스템이 원하는 데이터가 있을때 이를 객체로 만들어 준다. 객체를 만들 때는 데이터를 객체로 변경시켜주는 팩토리에 데이터를 넘겨주고, 팩토리는 이를 필요한 형태의 객체로 만들어서 반환하게 된다.

7. Proxy 패턴

프록시 패턴은 프록시가 대리인이라는 의미를 가지고 있는 것처럼, 원하는 작업을 대신해서 처리하도록 만드는 패턴이다. 시스템이 작업을 처리하는 가운데, 시스템의 처리과정을 효율적으로 만들기 위해 처리를 분산시킬 필요가 있다. 이렇게 처리과정의 일부부능ㄹ 다른 프로세서에 대행시키고자 할 때 프록시 패턴을 적용하면, 시스템의 구조를 어렵지 않게 효율적으로 변경시킬 수 있다.

출처  : C# 객체지향언어로 배우는 디자인 패턴 (정보문화사/Devpia)

디미터 함수 법칙은 프로그램에서 모듈간 결합도를 최소화하려 시도한다.
이법칙은 한 객체가 제공하는 메서드에 접근하기 위해 또 다른 객체들을 통하는 것을
허용하지 않는다.

디미터 함수 법칙 - 모든 메서드는 다음에 해당하는 메서드만을 호출해야 한다.

class Demeter {
  private :
     A *a;
      Int func();
  public :
        //...
        void example(B&  b);
}
void Demeter :: example(B& b){
    C c;
    Int f= func();  <----------- 자신
    b.invert(); <--------------메서드로 넘어온 인자
    a= new A();
    a->setActive(); <---------자신이 생성한 객체
    c.print(); <---------------직접 포함하고 있는 객체

}

참고 디미터 프로젝트 - 적응적 프로그래밍(Adaptive programming) 을 이용해서 소프트웨어를 유지보수하기 쉽고 진화하기도 쉽게 만드는데 초점을 두는 연구

내 주변을 둘러보니 변화와 쇠퇴뿐...  
-라이트HF.Lyte, "함께하소서 Abide with me"



코드가 더 이상 잘 맞지 않아서 장애물에 부딪쳤을때. 사실은 하나로 합쳐져 있어야 할 두개를 발겨했을때, 어떤 것이든 '잘못'되었다고 생각될때, 그것을 변경하는 일을 주저하면 안된다. 언제나 바로 지금이 최적기다.

. 중복 DRY(don't repeat youself) 원칙의 위반을 발견했을시
. 직교성이 좋지 않은 설계

코드를 리택토링(refactoring) 하는 것- 기능을 이리저리 옮기고 이전에 내린 결정을 갱신하는 것-은 사실 고통관리(pain management)를 실천하는 것이다.

현실을 피하지 말자. 소스코드를 이곳저곳 변경하는 것은 굉장히 고통스러운 작업일수도 있다.
거의 작동하는 수준까지 올려놓은 코드였는데 이제 완전히 망가져 버린다.

일찍 리팩토링하고, 자주 리팩토링 하자....


- The Programatic Programer 中 -