Tag Archive for 'Programming'

Structural Patterns

Published on 2006/06/18 in Programming-OOP&OOD. 0 Comments Tags: , , .

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

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

구조패턴에는

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 패턴

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

java에서 리소스 사용의 균형

Published on 2006/05/24 in Programming. 0 Comments Tags: , .

C++과 달리 자바에서는 게으른 방식의 자동 객체 삭제를 사용한다. 참조가 없는 객체들은 가비지 콜랙션(garbage collection)의 후보가 되며, 만약 가비지 콜랙션이 그 객체들을 지우려고 하기만 한다면, 객체의 finalize 메서드가 호출될 것이다.

더이상 대부분 메모리 누수 책임을 지지 않게 되어 개발자에게는 아주 편해진 일이지만, C++방식대로 자원을 청소하도록 구현하기는 어려워졌다.

다행스럽게도 사려깊은 자바 언어의 설계자들은 이것을 보상하기 위한 기능 하나를 추가해두었다.

finally 절이 그것이다. try 블록에 finally절이 들어있다면, 그절안의 코드들은 try 블록 안의 코드가 한문장이라도 실행되면 반드시 실행되도록 되어있다. 예외가 던져지더라도 상관없다.

finally 절 안의 코드는 반드시 실행된다. 이말은 다음과 같은 코드로 리소스 사용의 균형을 잡을 수 있다는 뜻이다.

public void dosomething() throws IOException{
 
       File tmpFile = new File(tmpFileName);
       FileWriter tmp = new FileWriter(tmpFile);
 
       try{
               //실행코드
       }
       finally{
               tmpFile.delete();
       }
}

이 루틴에서 사용한 임시파일은 루틴에서 어떻게 나가든 지워야 한다.
finally 블록이 이렇게 간결하게 해결해 준다.

리팩토링은 언제해야할까?

Published on 2006/05/12 in Programming-OOP&OOD. 0 Comments Tags: , .

내 주변을 둘러보니 변화와 쇠퇴뿐…

-라이트HF.Lyte, “함께하소서 Abide with me”

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

. 중복 DRY(don’t repeat youself) 원칙의 위반을 발견했을시

. 직교성이 좋지 않은 설계

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

현실을 피하지 말자. 소스코드를 이곳저곳 변경하는 것은 굉장히 고통스러운 작업일수도 있다.

거의 작동하는 수준까지 올려놓은 코드였는데 이제 완전히 망가져 버린다.

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


- The Programatic Programer 中 -