스팅의 불(火)로그

출처 : http://blog.tobegin.net/38  / Writer by 정은성

출처 : http://blog.tobegin.net/31  / Writer by 정은성

03| Dynamic 유형 객체 #1 : DLR


구독자 여러분 안녕하세요 생각보다 포스팅이 많이 늦어졌죠?
최근에 처리할일이 생각보다 많아서 포스팅을 쓸 여력이 되지 않았습니다.
앞으로 열심히 쓰고자 하니깐 용서해주세요 ~ 흑흑...

오늘은 지난 시간에 이어서 C#의 새로운 기능에 대해 소개를 할텐데요.
그 첫번째 시간으로 동적 타입에 대해 소개를 하고자 합니다.

지난 Microsoft는 MIX07과 PDC2008 등을 통해 .NET에서 새로운 수준의 지원을 발표를 하였습니다.
바로 .NET 프레임워크에서 서로 다른 프로그래밍 언어를 광범위한 지원을 하도록 설계가 되어졌는데요.

그배경에 공용언어 런타임(Common Language Runtime)의 Sandbox 보안 모델이 발전되면서 GC(Garbage Collection), JIT(just-in-time)를 더불어 공유 서비스를 제공하면서 각 다른 언어의 라이브러리를 손쉽게 가져다 쓸수 있었기에 정적인 언어와 동적인 언어를 구별하여 사용할수 있었지 않았나 생각이 듭니다.

* Sandbox(샌드 박스)

보호된 영역내에서 프로그램을 동작시키는 것으로 외부 요인에 의해 악영향이 미치는 것을 방지하는 보안 모델, ' 아이를 모래밭(샌드 박스)의 밖에서 놀지 않는다 ' 라고 하는 말이 어원이라고 알려져 있다. 이모델에서는 외부로부터 받은 프로그램을 보호된 영역, 즉, '상자'안에 가두고 나서 동작시킨다. '상자'는 다른 파일이나 프로세스로부터 격리되어 내부에서 외부를 조작하는 것은 금지 되어 있다.

어느듯 .NET Framework 4 버전의 런칭이 되면서 공용 언어 런타임(Common Language Runtime)이 2.0에서 4.0으로 업그레이드가 되었는데요. 그동안 Silverlight 1.1에서 지원을 했던 DLR(Dynamic Language Runtime)이 다시 주목을 받으면서 C# 4.0은 완전한 프로그래밍으로 초점을 맞추어 나가고 있습니다.

먼저 간단히 DLR(Dynamic Language Runtime)에 대해서 살펴 보아야 할것 같습니다.
Dynamic Language Runtime은 CLR 상단부에 위치하고 있으며 주요 구성은 다음과 같습니다.

출처 : http://blog.tobegin.net/31  / Writer by 정은성

출처 : http://blog.tobegin.net/29  / Writer by 정은성

02| C# 4.0 개요

이번 포스팅은 .NET Framework 4의 " C# 새로운 기능 소개와 출현배경" 에 대해 아티클로 다뤄보도록 하겠습니다.

그동안 2.0 버전에서 머물렀던 CLR(Common Language Runtime)이 .NET Framework 함께 4.0 버전으로 업그레이드가 되었습니다. CLR의 가장 큰 변화로는 DLR(Dynamic Language Runtime)을 통해 언어의 유연성이 느슨하게 되면서 DOM, IronRuby, IronPython 등  동적인 언어를 사용 할수 있도록 설계 되어졌습니다.

지금까지 Visaul C#언어는 정적 언어 였습니다. 정적 언어라고 하면 명확하게 타입 선언과 사용이 매칭이 되어야합니다. 만약 숫자를 사용하고 싶다면 int형 타입으로 선언을 해야하며 그리고 문자열 사용하고 싶다면 string형 타입으로 선언과 타입을 넘겨줘야합니다. 그런데 왜 이제서야 동적 언어를 지원을 하게 되었을까요? C# 디자인팀에서 4.0을 설계 할때 2가지 컨셉중심으로 준비 하였다고 합니다.

[그림1] C# 4.0 컨셉

첫번째 컨셉은 Dynamic Programming 인데요
Dynamic Programming은 4.0에서 등장 했던 것은 아닙니다. invokeMember와 같이 Reflection을 이용하여 동적으로 사용이 가능했습니다. 하지만 메모리 소모량도 크고 불안정하기 까지 하였습니다. 그래서 C# 4.0에서는 DLR(COM Interop 포함)에 대한 높은 호환성과 Iron 시리즈의 스크립팅 언어를 비롯해 늦은 바인딩 언어를 지원하고자 dynamic 키워드를 도입하게 되었고 유연성을 허용 하게 되었습니다.

두번째 컨셉으로는 co-evolution with VB 입니다.

지난 10년간 .NET Framework가 발전을 하면서 VB, C#, C++, IronRuby, IronPython, JScript , J# 등 많은 언어들을 지원하며 Managed 하게 진화해 왔습니다. 그중 마치 형제인듯 공존하며 성장을 해왔던 언어가 있는데요.

바로 VB와 C#언어 입니다. 마침 MS OFFICE 프로그램의 오토메이션 사례등 유사한점을 확인 할 수 있었습니다. 예를들어 어떠한 데이터를 셀에 삽입한다고 가정할 때 C#에서는 Value2라는 속성을 사용하였고 반면 VB에서는 Value라는 속성을 사용하였습니다.  이들의 특징은 동일한 내용의 타입 이였고 동일한 시나리오의 수행이였습니다. 그럼 구현의 퍼포먼스에서는 어땠을까요? VB에서는 사용이 쉬운 반면 C#에서는 전혀 알지도 못한 타입 함께 사용하게 되었습니다. 자연스럽게 코드가 복잡해지고 어려울수 밖에 없었죠. 이러한 기존 VB의 특징을 바탕으로 어떻게 하면 효율적으로 사용할것인지 또한 어떻게 COM객체와 상호연동을 할것인지? 등 함께 성장하자라는 취지로 C# 4.0이 탄생하게 되었습니다.

다음은 두 컨셉의 기반으로 탄생한 C# 4.0의 새롭게 추가된 구성원이 무엇인지 간단히 살펴보도록 하겠습니다.

[그림2] C# 4.0의 새로운 기능들

* C# 4.0의 새로운 기능들

명칭만으로도 궁금증을 돋아 주는데요. 아쉽게도 이번 포스팅에서는 헤드라인 만 살펴봐야할것 같습니다.
다음 포스팅부터 새롭게 추가된 기능에 대해 순차적으로 만나뵐 예정이구요.

궁금하셔도 조금만 기다려주세요 : )
그래도 궁금하시다면 아래 참고 문헌을 참조하시면 됩니다.

여러분 다음 포스팅에 만나요 =ㅁ=//

참고 문헌

1. New Features in C# 4.0 - Mads Torgersen, C# Language PM(April 2010)
    : http://msdn.microsoft.com/en-us/vcsharp/ff628440(en-us).aspx
2. What's New in Visual C# 2010
    : http://msdn.microsoft.com/kr-ko/library/bb383815.aspx
3. PDC2008 : The Future of C# - Anders Hejlsberg
    : http://channel9.msdn.com/pdc2008/TL16/


포스팅을 마치며...

어떤 느낌을 받으셨나요? 아직 무엇인지는 알 수 없지만 의미적으로 많은 지원을 제공하고자 Microsoft에서 야심차게 준비하는 모습을 볼 수 있었습니다. 다음 포스팅 에서는 새로운 기능의 특징들을 순차적으로 살펴 보도록 하겠습니다.
앞으로도 관심 부탁드리며 무더위 준비 잘하시길 바라면서 글 이만 줄이도록 하겠습니다.
감사합니다.

정은성 드림

출처 : http://blog.tobegin.net/29  / Writer by 정은성

출처 : http://blog.tobegin.net/39  / Writer by 정은성

3. String과 StringBuilder 비교

  string은 프로그램을 짜면서 가장 빈번하게 사용되는 자료형의 하나이다. string을 쓰는데 있어서 흔히들 string 연산이 많을 경우 string 타입 대신에 StringBuilder 객체를 쓰라는 얘기를 들어 보았을 것이다. 여기에서는 string과 StringBuilder의 차이에 대해 다루며 각각을 어떻게 이용하는 것이 효율적인지에 대해 다루어보도록 하겠다.

  먼저 아래의 간단한 프로그램을 보도록 하자.

  위의 예제 소스는 간단히 프로그램의 메모리 사용량을 비교해보기 위해 만들어본 소스이다. 단순히 증가되는 프로그램 영역의 메모리를 카운트하는 용도로 GetTotalMemory 라는 메서드를 이용해서 비교해 보았다. 이제 결과를 보기로 하자.

그림. 실행결과

  string

  실행결과 그림에서 보이는 바와 같이 string 으로 선언된 str1 변수의 경우 17번 반복하는 동안 연속적인 메모리 증가를 보인다. 실제 string의 내부적인 구현은 char 타입의 연속적인 열의 형태로 구성되는데, 선언시 초기화되는 데이터의 값으로 string 타입 변수의 크기가 결정된다고 보면 된다. 위의 소스와 같이 “+”와 같은 결합 연산자를 이용하여 경우 데이터의 크기가 증가하므로 할당되는 메모리 역시 증가되어야 한다.

  이제 코드를 상세히 보도록 하자. 위의 소스에서 다룬 스트링 연산에서,

  부분을 디스어셈블러를 통해 추적해 보면 Concat(string, string)를 호출하는 것을 볼수 있다.

  실제 Concat 라는 메서드를 한번 보기로 하자.

  소스에서 눈여겨 봐야 할 부분은 FastAllocateString이라는 메서드 이다. 여기에서 보이는 것과 같이 새로 메모리를 할당하는 것을 볼 수 있다. 실제 Concat 메서드를 통해 볼 수 있듯이 새로운 문자열과 결합해서 문자열을 생성해내야 하는 문자열 연산은, 연산이 이루어질때마다 새로운 string 개체를 생성하고 스택 내 메모리를 재할당하는 과정을 반복하게 된다. 문자열에 대해 증가에 대해서 “A"라는 문자를 증가시킬 때 인덱스가 2씩 증가할 때 마다 메모리가 증가되는 이유는 char 형이 실제 2바이트를 이용하지만 할당되는 메모리 단위기 4바이트씩 증가되기 때문에 실행결과 그림과 같이 보인다.

  string 타입의 제약은 메모리 재할당 문제로 인해 발생한다. 메모리의 안전한 보호와 동적인 수정이 가능한 구조로 가기 위해 실제 string 타입이 선택한 방법은 수정요구시 마다, 새로운 string 타입을 생성하고 적절한 사이즈로 메모리를 할당하고 문자열을 배정하는 것이라고 보면 된다.

  StringBuilder

  처음 나온 예제소스에서 보면 17번 반복해서 문자열을 한자씩 더해가고 있다. 그 이유는 StringBuilder 개체를 생성할 때, 초기에 그 크기를 선언하지 않으면 16으로 크기가 자동으로 결정된는 것을 보여주기 위해서 문자열의 크기를 맞추어 보았다. 출력 결과를 보면 “A"라는 문자가 16개가 된 후 StringBuilder 개체 역시 메모리 재 할당 과정을 수행하게 된다. 따라서 테스트용으로 작성된 소스의 17번째 반복 시점에서 메모리 사용이 증가하는 것을 발견할 수 있게 된다.

  메모리 재할당이 이루어지는 단계에서는 새로운 StringBuilder 개체 생성과 기존 크기의 2배 크기로 메모리 할당, 기존 데이터의 복사가 이루어진다.

  자 이제, StringBuilder 개체 생성시 적절한 사이즈를 설정한 후 작업을 하게 되면 재할당 과정에 드는 리소스의 사용을 최소화 할 수 있다는 것을 알 수 있을 것이다.

  StringBuilder에 대한 좀더 상세한 내용은 다음에 더 다루어 보도록 하겠다.

  결론

  string과 StringBuilder는 비슷한 용도로 활용되면서, 많은 차이점을 가지고 있다. 일반적으로 얼마되지 않는 스트링 연산과 데이터를 이용하는데 있어서 string이 성능상 더 나을 수도 있다. 그럼 StringBuilder을 왜 사용하는 것일까?

  아래의 간단한 성능 테스트 코드를 보자.

  위의 소스는 시간 측정을 하기 위해 System.Diagonstics 의 Stopwatch 클래스를 이용하는 코드와 결과를 명확히 하기 위해 반복 횟수를 100000으로 조절하여 테스트 한 소스이다. 변수 할당같은 경우 소요시간이 엄청 짧기 때문에 반복횟수를 크게 했다. 결과는 아래와 같다.

그림. 실행결과

  동일한 100000번의 반복에서 경과시간을 비교해볼 수 있을 것이다. 이렇듯 많은 연산이 요구되는 경우 string은 성능상에 많은 문제를 일으킬 수 있다는 것을 보여주고 싶었다.

  많은 연산이 수행되는 경우 효과적인 성능을 보장할 수 있기에 StringBuilder 클래스를 이용해서 작업을 수행하는 것이다. 적절한 크기를 명시하고, 적절한 장소에서 이용된다면 편리하고 시스템에 덜 부담을 주는 코드를 만들어 낼 수 있게 된다.

  적당한 것 예를 들어, 데이터베이스 컨넥션 스트링이나 기타 문자열 결합 형식 등을 통한 일반적인 몇 자 안되는 문자열 생성 등에는 string 타입 변수 선언을 해서 이용하는 것이 이득이고, 대규모의 문자열에서 잦은 수정과 반복을 통한 추가 등이 이루어져야 한다면 StringBuilder을 쓰는게 좋을 수 있다.

인터페이스의 구현에는 두 가지가 있습니다. 이른바 암시적 구현과 명시적 구현이라고 하는데요, 일반적인 경우에는 주로 암시적 구현을 사용하지만 경우에 따라서는 명시적 구현을 사용해야 하는 경우도 있습니다.

먼저 암시적 구현 부터 살펴볼까요? 두 개의 인터페이스가 있다고 합시다.

01 public interface IGunner

02 {

03     void Shoot();<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

04 }

05

06 public interface ISoccerPlayer

07 {

08     void Shoot();

09 }

코드 1

IGunner는 총을 쏘는(shoot)을 메소드를 정의하고 있고, ISoccerPlayer는 공을 차는(shoot) 메서드를 정의하고 있습니다. 공교롭게 메서드의 이름이 같긴 하지만, 이 두 인터페이스는 서로 전혀 연관이 없습니다. 또한 3번과 8번 라인에서 아무런 접근 지정자가 붙어있지 않은 점도 유심히 보시기 바랍니다. 클래스의 경우 멤버의 접근 지정자가 붙어있지 않다면 private이 생략된 것으로 간주하지만, 인터페이스의 경우에는 public이 생략된 것으로 간주합니다. 아니 간주하는 것이 아니라, 인터페이스의 멤버는 그 성격상public외의 접근 지정자를 가질 수가 없습니다. 따라서 항상 public이기 때문에 인터페이스의 멤버에는 아무런 접근 지정자를 붙일 필요가 없습니다. 오히려 접근 지정자를 붙이면 문법 오류입니다.

이번에는 이들 인터페이스를 각각 구현하는 총잡이와 축구 선수 클래스를 생각해봅시다.

01 internal class Gunner : IGunner

02 {

03     public void Shoot()

04     {

05         Console.WriteLine("빵빵");

06     }

07 }

08

09 internal class SoccerPlayer : ISoccerPlayer

10 {

11     public void Shoot()

12     {

13         Console.WriteLine("슛");

14     }

15 }

코드 2

인터페이스에 정의된 메서드의 이름이 같기 때문에 이를 구현하는 두 클래스에서의 메서드 이름도 같을 수 밖에 없지만, 그 동작은 전혀 다릅니다. 총잡이는 총을 쏘고, 축구 선수는 공을 차지요. 그리고 3번 라인과 11번 라인에서는 public 접근 지정자가 붙어 있습니다. 인터페이스를 정의할 때는 붙이지 않았던 접근 지정자를 인터페이스를 구현하는 클래스에서는 이렇게 지정하여야 합니다. 인터페이스에서의 접근 지정자가 (생략된) public 이었기 때문에, 클래스에서도 public 이외의 다른 값을 가질 수는 없습니다. (곧 살펴 볼 명시적 인터페이스에는 적용되지 않는 이야기입니다..)

총잡이와 축구 선수의 인스턴스를 만들고 각각 Shoot 메서드를 호출해보도록 합시다.

1 private static void Main(string[] args)

2 {

3     Gunner gunner = new Gunner();

4     gunner.Shoot();

5

6     SoccerPlayer soccerPlayer = new SoccerPlayer();

7     soccerPlayer.Shoot();

8 }

코드 3

빵빵

슛

계속하려면 아무 키나 누르십시오 . . .

당연히 의도한 대로의 결과가 나왔습니다.

여기까지가 인터페이스의 암시적 구현에 관한 이야기였습니다. 지금부터는 인터페이스의 명시적 구현에 관한 내용입니다.

명시적 구현을 설명하기 위해 새로운 클래스를 하나 등장 시켜야겠습니다. 군인 클래스인데요. 군인이니까 당연히 총을 쏩니다(shoot). 그리고 군인이니까 당연히(?) 공도 잘 찹니다(shoot). 그래서 병사 클래스는 IGunner와 ISoccerPlayer를 모두 상속 구현하도록 결정을 하겠습니다.

01 internal class Soldier : IGunner, ISoccerPlayer

02 {

03     public void Shoot()

04     {

05         Console.WriteLine("빵빵");

06     }

07

08     public void Shoot()

09     {

10         Console.WriteLine("슛");

11     }

12 }

코드 4

한 눈에 봐도 에러입니다. Shoot 메서드가 중복이 되었지요. 위와 아래의 메서드는 각각 Gunner와 SoccerPlayer의 Shoot인데, 이를 구별하지를 못합니다. 즉 시그니처(메서드의 형을 구별하는 기준, 쉽게 말하면 메서드의 이름과 매개 변수의 개수와 각 매개 변수의 형)가 동일한 메서드를 가진 두 인터페이스를 동시에 구현 상속하지 못하는 상황을 해결하기 위해 C#의 설계자는 별도의 문법을 고안하였습니다. 그것이 바로 인터페이스의 명시적 구현입니다.

인터페이스를 명시적으로 구현하는 문법은 간단합니다. 구현하는 메서드 이름 앞에 누구의 메서드인지만 표시해주면 됩니다. 다음 코드는 코드 4를 명시적 구현으로 바꾼 코드 입니다.

01 internal class Soldier : IGunner, ISoccerPlayer

02 {

03     void IGunner.Shoot()

04     {

05         Console.WriteLine("빵빵");

06     }

07

08     void ISoccerPlayer.Shoot()

09     {

10         Console.WriteLine("슛");

11     }

12 }

코드 5

3번 라인과 8번 라인을 보면 Shoot 메서드 앞에 각각 인터페이스의 이름을 붙이고 있습니다. 또한 접근 지정자가 사라졌습니다. 접근 지정자가 없기 때문에 Shoot은 private 멤버입니다. 이 부분에 대해서는 잠시 후 다시 말씀 드리겠습니다.

이제 군인이 총을 쏘고 공을 차는 코드를 보겠습니다.

1 private static void Main(string[] args)

2 {

3     Soldier soldier = new Soldier();

4     soldier.Shoot(); // 총 쏘기

5     soldier.Shoot(); // 공 차기

6 }

코드 6

코드를 작성하긴 했는데 영 기분이 이상합니다. 아니나 다를까 문법 에러라서 컴파일도 되지 않습니다. 코드 5의 Shoot 메서드는 Soldier의 private 메서드라서 접근할 수 없다고 합니다. 혹 접근이 된다고 하더라도, 4번 라인에서는 총을 쏘고 5번 라인에서는 공을 차야 하는데, 뭐가 무엇을 하라는 말인지 구별이 안 갑니다. 결론적으로 인터페이스가 명시적으로 구현이 되면 Soldier 변수를 통해서는 접근할 수가 없다는 사실을 알았습니다. 그렇다면 이 군인이 총을 쏘고 공을 차게 하는 방법은 무엇일까요?

답은 Soldier가 아닌 IGunner 혹은 ISoccerPlayer를 통해서 접근을 한다는 것입니다. 즉 총을 쏠 때는 Soldier 객체를 IGunner로 형변환 하고, 공을 찰 때는 ISoccerPlayer로 형변환 한다는  것입니다.

1 private static void Main(string[] args)

2 {

3     Soldier soldier = new Soldier();

4

5     ((IGunner)soldier).Shoot(); // 총 쏘기

6     ((ISoccerPlayer)soldier).Shoot(); // 공 차기

7 }

코드 7

형변환을 하지 않는다면 Soldier 객체를 만들어 IGunner 혹은 ISoccerPlayer 변수가 그를 참조하도록 하는 방법도 있습니다.

1 private static void Main(string[] args)

2 {

3     IGunner gunner = new Soldier();

4     gunner.Shoot(); // 총 쏘기

5

6     ISoccerPlayer soccerPlayer = new Soldier();

7     soccerPlayer.Shoot(); // 공 차기

8 }

코드 8

이 경우에는 예컨데 3번 라인과 같이 생성된 Soldier 객체를 IGunner 변수에 참조시키면 IGunner 변수를 통해서는 총만 쏘지 공을 찰 수는 없습니다.

이제 코드 5를 다시 보며 두 Shoot 메서드의 접근 지정자에 대해서 생각을 해 봅시다. 코드 6에서 확인하듯이 Soldier 클래스의 입장에서 두 Shoot 메서더는 private 입니다. 하지만 코드 7에서 보듯이 IGunner와 ISoccerPlayer의 입장에서는 각각의 Shoot 메서드는 public 입니다. 결국 명시적으로 구현된 인터페이스 메서드의 접근 지정자는 상황에 따라서 서로 다른 두 개의 접근 지정자를 가지게 되는 것입니다.

이제 인터페이스의 암시적, 명시적 구현을 모두 다루었으니, 응용으로 이 둘을 섞어 놓은 형태를 보도록 합시다. 다음 코드를 보시기 바랍니다.

01 internal class Soldier : IGunner, ISoccerPlayer

02 {

03     public void Shoot()

04     {

05         Console.WriteLine("빵빵");

06     }

07

08     void ISoccerPlayer.Shoot()

09     {

10         Console.WriteLine("슛");

11     }

12 }

코드 9

3번 라인은 암시적으로, 8번 라인은 명시적으로 인터페이스 멤버를 구현하고 있습니다. 8번 라인이야 ISoccerPlayer의 Shoot을 구현한다고 명확히 알 수 있겠는데, 3번 라인의 경우에는 명확히 알 수가 없습니다. 이 경우 컴파일러는 Soldier가 구현하여야 한는 Shoot는 두 개가 있는데 그 중 하나는 ISoccerPlayer의 Shoot이기 때문에(8번 라인) 나머지 하나는 IGunner의 Shoot로 인식을 합니다.(3번 라인)

이를 사용하는 코드는 다음과 같습니다.

01 private static void Main(string[] args)

02 {

03     Soldier soldier = new Soldier();

04    

05     ((IGunner)soldier).Shoot(); // 공 차기

06     ((ISoccerPlayer)soldier).Shoot(); // 공 차기

07

08     soldier.Shoot(); // 총 쏘기

09 }

코드 10

코드 7과 달라진 점은 8번 라인과 같이 Soldier 변수를 통해서도 Shoot을 호출할 수 있다는 것입니다. 이 때 Soldier의 Shoot는 IGunner의 Shoot를 구현하고 있기 때문에 결국 8번 라인은 5번 라인과 동일한 결과가 나타납니다.

빵빵

슛

빵빵

계속하려면 아무 키나 누르십시오 . . .

인터페이스의 명시적 구현을 마무리 짓기 전에 한 가지 중요한 사실이 있습니다. 실컷 명시적 구현을 연습해 놓고 이런 말 하려니 좀 허탈하긴 한데, 바로 인터페이스의 명시적 구현은 ‘꼭 필요한 곳이 아니면 가급적 사용하지 말라’는 것입니다. 그 이유는 여태껏 이야기한 내용에 들어 있습니다. 예를 들어 Soldier 클래스를 사용하는 개발자는 Soldier 클래스만 봐서는 Shoot 메서드의 존재를 알기 어렵습니다. 또한 만일 Soldier가 클래스가 아닌 구조체라면, Shoot메서드를 호출하기 위해 ((IGunner)soldier).Shoot과 같이 형변환을 할 때 마다 추가적인 박싱이 일어나기도 합니다.




출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1470&page=7

…    일반 문자열 자체를 의미한다.

예:    abc - 'abc', 'aabc' (O)

.    개행 문자 (즉 “\n")를 제외한 임의의 문자 한 개와 매치한다.

예:    a.c - 'abc' (O), 'ac' (X)

*    바로 앞에 있는 패턴이 0번 혹은 그 이상 반복되는 것을 의미한다.

예:    ab*c - a + b가 0개 이상 + c

[]    대괄호 안에 있는 임의의 문자와 매치하는 문자 클래스이다. 그러나 첫 번째 문자가 캐럿(“^”)이면 대괄호 안에 있는 문자를 제외한 어떠한 문자와도 매치한다는 의미가 된다. 대시(“-”)가 대괄호 안에 존재하면 대시 앞뒤 문자 사이의 범위를 가리킨다. 예를 들어, “[0-9]”는 “[0123456789]”와 동일한 의미이다. 문자 클래스에 대시나 대괄호(“]”)를 포함할 수 있도록 하기 위해서, “[” 바로 다음에 나타난 문자가 “-” 혹은 “]”이면 각각의 특별한 의미 없이 문자 그대로 해석한다. POSIX는 비 영어권 문자를 다룰 때 유용한 특수 대괄호를 도입하였다. 대괄호 안에서는 “\” 문자로 시작하는 C 언어의 이스케이프 시퀀스를 제외한 나머지 모든 메타 문자들이 특별한 의미를 상실한다.

예:    a[bcd]c - a + b, c, d 중 한 문자 + c

예:    a[^bcd]c - a + b, c, d가 아닌 한 문자 + c

예:    a[a-z]c - a + a ~ z 중 한 문자 + c

^    행의 시작에서 정규 표현식의 첫 번째 문자가 매치한다. 한편 대괄호 안에서는 부정의 의미로 사용된다.

예:    ^123 - 123, 1230 (O) | 0123 (X)

$    행의 끝에서 정규 표현식의 마지막 문자가 매치한다.

예:    123$ - 123, 0123 (O) | 1230 (X)

{}    괄호 안에 하나 또는 두 개의 숫자를 담고 있을 경우 괄호 앞에 있는 패턴이 몇 번 매치해야 하는지를 가리킨다. 예를 들면 A{1, 3}의 경우 문자 A가 최소 한 번에서 연속 세 번까지 나타나야 함을 뜻한다. 중괄호 안에 특정 이름을 담고 있다면, 그 이름으로 대체한다는 것을 의미한다.

{n}    {n} 바로 앞의 문자가 n개다.

예:    ab{2}c - a + b가 두 개 + c

{n,}    {n,} 바로 앞의 문자가 n개 이상이다.

예:    ab{2,}c - a + b가 두 개 이상 + c

{n, m}    {n, m} 바로 앞의 문자가 n개 이상 m개 이하이다.

예:    ab{2,4}c - a + b가 두 개 이상 4개 이하 + c

\    메타 문자들의 의미를 파기하고 C 언어 이스케이프 시퀀스를 표현하는 데 사용한다. 예를 들어, “\n"은 개행 문자이지만 ”\*“은 별표 그 자체를 나타낸다.

예:    \*, \+, \^

+    앞에 있는 정규 표현식이 한 번이나 그 이상 반복하여 매치할 수 있음을 의미한다. 예를 들면 [0-9]+ 와 같이 쓰일 수 있다. 이 패턴은 “1”, “111” 혹은 “123456”에 매치하지만, 빈 문자열에는 매치하지 않는다. 만약 플러스 기호 대신 별표를 이용하면 빈 문자열도 매치된다.

예:    ab+c - a + b가 1개 이상 + c

?    앞에 있는 정규 표현식이 0번이나 한 번 나타날 수 있음을 의미한다. 예를 들어 -?[0-9]+ 와 같은 패턴은 숫자 앞에 마이너스 기호를 붙이거나 붙이지 않을지를 결정할 수 있다.

예:    ab?c - a + b가 없거나 1개 + c

|    앞에 있는 정규 표현식 혹은 뒤에 있는 정규 표현식에 매치한다.

예:    cow|pig|apple - cow 또는 pig 또는 apple

“...”    따옴표 안에 있는 문자들은 C 언어의 이스케이프 시퀀스를 제외한 모든 메타 문자의 의미를 파기하고 문자 그대로 해석한다.

/    ‘/’ 뒤에 있는 정규 표현식이 매치하는 경우에 한해 ‘/’ 앞의 정규 표현식에 매치한다. 예를 들면 0/1의 경우 “01”과 같은 문자열 안에 있는 “0”에 매치하지만, “0” 또는 “02”아 같은 문자열에는 매치하지 않는다. 슬래시 뒤에 있는 패턴과 매치하는 부분은 “사용되지” 않으며, 다음 토큰 검색 과정에서 사용된다. 패턴 한 개 당 슬래시 하나만 허용된다.

()    정규 표현식 여러 개를 새로운 정규 표현식 한 개로 묶는다. 예를 들어 (01)의 경우 문자 시퀀스 01을 의미한다. 괄호는 *, +, 그리고 |와 함께 사용하여 복잡한 패턴을 구성할 때 매우 유용하게 쓰인다.

(?<GroupName>...)    그룹 매칭을 할 때 <GroupName> 부분이 나중에 프로그래밍 방식으로 결과를 탐색할 때 기준으로 사용된다. 뒤이어오는 ... 부분에 식을 쓴다.

예:    (?<First>[0-9]{6})\-(?<Last>[0-9]{7})

앞서 나열한 연산자 중에서 몇몇은 ([] 처럼) 문자 하나에 대해서만 작동하는 반면 다른 연산자는 정규 표현식 전체를 상대로 작동한다는 사실에 주목하기 바란다. 보통 복잡한 정규 표현식은 간단한 정규 표현식 여러 개를 모아서 만든다.



출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1547&page=4

웹써핑중에 라면 만들기 강좌를 활용한 좋은 예가 있어 소개해드릴까 합니다.

원래 라면 만들기 강좌 다음 버전은 어렵지 않으면서도 활용하기 좋은 다른 패턴을 쉽게 풀어보려고 했는데

한 놈만 제대로 이해한다면 다른 패턴들을 공부할때 쉽게 수긍 할 수 있는 부분이 많다고 봤습니다.

어째든.. 그냥 긁어다 붙이면 너무 성의가 없으니 기사를 적절히 끊어서 설명하겠습니다.

Continuing with this idea of showing alternatives using the same example, I thought it might be interesting to show the Decorator Pattern which can be used when the Policy Injection Application Block and PostSharp may be overkill for your application.

In the two examples mentioned above I created a Stopwatch Attribute that timed the ILogger.Write Method used in our console application:

혹시 일본식 라면집에 가보셨나요? 저는 여자친구와 갔다가 곰탕같은 라면을 시켜먹었는데(으웩...) 그게 8년전 애기입니다.

개인적으로 라면은 우리나라, 삼양라면을 좋아합니다. 가끔 너구리도 먹어주시면 흐뭇해지고요. 그리고 일요일엔 짜파게티죠~

오늘 이 자리를 빌어 저와같이 라면을 좋아하시는(돈이 없어 라면을 드시던간에-_-) 우리나라 프로그래머님들을 위해

저만의 비법을 알려드리겠습니다. 물론 어떤 댓가를 바라진 않습니다. 다만 응용한 결과를 저에게도 알려주시면 고마울뿐이죠.

아래는 제가 만든 첫번째 라면입니다.

소스를 보니 텅~ 빈 생성자 하나에 설명이라는 속성 그리고 가격이라는 메소드가 있군요.

설명이 무안 할 정도로 단순하지만.. 얼마나 복잡하게 될 수 있는지 보기로 하죠.

이제 이런 형태로 된장라면, 간장라면, 곰탕라면, 짜장라면, 김치라면, 카레라면, 조개라면, 사노라면, 짬뽕라면,

된장조개라면, 고추조개라면, 짜장된장라면, 고추짜장라면, 고추된장카레조개짬뽕라면.. 등등등..

지면상-_- 나머지 라면들을 나열하는것은 생략하고 이 정도만 만들어 보죠.

대충 복사해서 이름하고 가격만 바꿔주면 될듯 보입니다.

자.. 이제 평소에 잘하시는 ctrl+c, ctrl+v 신공을 발휘할때가 왔네요.

그런데 가만 들여다보면 단순하진 않습니다. 그렇게 쉽게 해결 될 문제가 아닌거죠.

그 이유로 고추조개라면의 경우로 예를 들면 가격()을 구현해야 하는데

아래 소스에서 보다시피 참조되는 라면들의 가격을 반영해야 합니다.

만약 고추/된장/카레/조개/간장/양파/해삼/멍게/오징어/짬뽕라면 이라면... 그외

카레/조개/간장/양파/해삼/멍게라면,  해삼/멍게/오징어/짬뽕라면 등등 다양한 조합들이 있으므로

가격이란 메소드 작성이 쉽지 않습니다.

더구나 이 글을 보신 분들의 요청에 의해 라면의 종류는 더 늘고 복잡해질지 모릅니다.

... 왜 문제가 되는지 생략 ...

여기에 이 문제를 해결 할 비법이 있습니다.

우선 라면에대해 다시 생각해 볼 필요가 있습니다.

다 알다시피 라면은 어떤 재료가 들어가냐에 따라서 종류가 달라지고 어떤 라면이 될지가 결정됩니다.

그리고 재료는 하나이상 복합적으로 들어갈 수 있고(안들어갈수도 있군요) 이에따라 라면의 가격도 달라집니다.

이 둘의 관계는 달리말하면 라면은 재료에 함수적 종속성을 가지게 됩니다. 재료가 라면을 결정짓게 되는것이죠.

따라서 우리는 라면과 재료의 관계를 재정립하고 이를 코드로 분리해서 관리 할 필요성이 있습니다.

라면은 재료에의해 설명도 가격도 달라지므로 둘을 합치거나 또는 서로가 포함관계에 있으면 코드의 중복과

복잡도가 증가하고 재료비나 또는 가격을 계산하는 로직이 변경될 경우 수정에 많은 힘이 드는 상황이 발생합니다.

해결책은 아래와 같이 라면과 재료라는 추상화된 객체를 만드는것으로부터 시작합니다.

여기서 핵심은 재료로 라면에 어떠한 행위를 한 뒤에라도 라면으로써 사용이 가능해야 합니다. (현실도 그렇죠)

기본라면에 어떤 재료를 넣어 만들어진 라면도 라면이고, 그렇게 만들어진 라면에 다시 재료를 추가해도 라면이라는 말이죠.

따라서 재료 클래스는 추상화된 라면 클래스를 구현또는 상속받아야 합니다. 재료 as 라면이 성립되어야 하니까요.

또 재료만의 속성과 메소드를 가질수 있으니 이것을 객체로 만드는데는 이의가 없습니다.

(인터페이스로 구현해도 됩니다. 하지만 여기선 추상클래스로..)

이걸 바탕으로 아래와 같이 고추라는 재료를 만들수 있습니다.

재료의 생성자에 가공(요리) 할 대상인 라면의 레퍼런스를 넘겨주는것에 주목 할 필요가 있습니다.

설명 속성은 넘겨받은 라면에 재료명을 더해주는것만으로 깔끔하게 완성된 코드입니다.

마찬가지로 가격 메소드 또한 가공(요리) 할 라면가격에 재료(고추)의 가격을 더해주면 됩니다.

이렇게 기본라면에 고추를 넣은 후에도 라면으로봐야죠. 가공(요리)된 라면에 다시 고추를 넣어도 라면입니다.

그럼 고추고추라면이 되겠군요. -_- 

끝에가면 예제가 있으나 우선 사용예를 보겠습니다.

라면 고추라면 = new 고추( new 라면인스턴스() );

라면 고추고추라면 = new 고추( new 고추( new 라면인스턴스() ) );

고추고추라면.가격() 메서드를 호출하면 ( 고추재료가격 + ( 고추재료가격 + 라면가격) ) 과 같은 계산이 이뤄지게 됩니다.

그럼 고추와 같은 방법으로 조개라는 재료도 만들어보죠.

자.. 이제 재료도 대충 만들었으니 재료들을 넣을 라면을 만들어 볼 차례입니다.

아직 실체화된 라면이 없었습니다. 여기선 그냥 삼양라면을 만들어 보겠습니다.

이제서야 라면을 요리 할 시간이 되었군요.

재료도 구비되었으니 이제 라면을 재료로 새롭게 재탄생시킬수 있습니다.

라면을 고추로 감싸서 고추라면을,

라면을 조개로 감싸고 다시 고추로 감싸니까

고추조개삼양라면이 만들어집니다.

고추조개삼양라면을 양파라는 재료 클래스로 감싸주면?

양파고추조개삼양라면이 되겠죠.

실행 결과화면

어떤가요?

라면 클래스(여기서는 추상화된 라면 클래스를 구현한 삼양라면을 말합니다) 자체는 손대지 않았습니다.

단지 재료로 감싸준것 뿐이죠. 또 단가의 계산도 간결하게 해결 되었습니다.

그런데 결과화면을 보니 고추/조개/삼양라면 순이 아니라 읽고 부르기엔 웬지 이상합니다.

이 문제를 수정하기 위해 기존 클래스들을 수정해야 할까요?

우리는 방금 원본 클래스에 손도 대지않고 원하는 기능을 구현하는 방법을 배웠습니다.

따라서 이번에도 그런 방식으로 해보는게 좋겠군요.

아래와 같이 DescriptionDeco라는 클래스를 만들어봤습니다.

역시 여기서의 핵심도 라면이라는 추상화 클래스를 상속받고 생성자에선 가공해야 할 라면 클래스를 넘겨받는것이죠.

이렇게 하면 기존 코드의 변경이 일어나지 않습니다.

(단지 설명을 출력하는 기능에대한 확장이므로 가격은 변동이 없습니다. 공짜란 말이죠.)

적용 예입니다.

결과화면

* 실행가능한 전체소스를 첨부하였으니 참고하세요.

마무리

별로 쓴 내용도 없는데 이걸 작성하는데 2시간이나 걸렸네요. 원래는 대충 설명하고 비주얼한 예제를 쓸려고 했는데

이 속도로는 어렵겠군요. -_-  이외에도 좀 더 많은 할 애기가 있지만 여기서 끊는게 좋겠습니다.

아시는 분들은 이미 아셨을수도 있는데 위 내용은 Head First Design Patterns 책을 약간 패러디한것으로

데코레이션 패턴에 해당하는 내용입니다. 미숙한 글이나마 도움이 되었으면 합니다.

용어정리

추상화 클래스인 라면을 Component,

이 클래스를 상속받아 구현된 삼양라면을 ConcreateComponent라고 합니다.

Decorator는 추상화된 재료 클래스 입니다.

일반적으로 Component는 어떤 행위를 정의한 인터페이스와 같이 추상화된 객체일 수 있습니다.

이걸 상속받아 구현된 ConcreateComponent는 Decorator가 감싸게 될 클래스이고요.

Decorator Pattern의 경우 객체의 변형없이 상속또는 구현을 통해 객체의 기능을

유연하게 확장 할 수 있는 방법으로 자주 사용됩니다.

실무에서 부담없이 적용해 볼 만한 몇개 안되는 패턴중에 하나입니다.


출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1627&page=1

개 요

이번에는 닷넷의 특징이라고 할 수 있는 Boxing, Unboxing에 대해 배워보도록 하겠습니다.

내부적으로 일어나는 일이기때문에 처음에는 몰라도 상관없지만 퍼포먼스에 좀 더 신경쓰기 시작하면 반드시 이해해야할 개념이라 할 수 있습니다.

MSIL 코드를 직접 보면서 Boxing, Unboxing 을 이해해 봅니다.

Boxing

Value 타입의 변수는 Stack에 생성되고 Reference 타입의 변수는 Heap에 생성됩니다.

Heap에 무엇인가가 생성될 때 변수는 이 heap에 생성된 객체를 가르키는 4byte "포인터(주소값)"를 할당받게 됩니다.

그래서 이 변수를 다른 함수의 매개 변수로 넘길 때는 항상 객체 자체가 아니라 이 포인터만 넘기게 됩니다.

value 타입의 변수 경우는 어떤 함수의 매개 변수가 될 경우 이 값의 copy를 만들고 copy를 통째로 넘겨주게 됩니다.

여기까지는 c++ 기반 개발자라면 이미 누구나 알고 있는 사항일 것입니다.

그러나 닷넷에선 Value 타입의 변수를 Reference 타입의 변수인것처럼 사용하는 경우가 있습니다.

그리고 바로 이 때 "Boxing"이 이루어집니다.

자 다음과 같은 예를 들어보도록 하겠습니다.

public void Method()

{
         ArrayList ar = new ArrayList();

         ar.Add(5);

}

ArrayList.Add() 함수의 매개변수로 요구하는 것은 분명 Reference 형인 Object입니다.

그런데 value 타입인 integer 값을 함수의 매개 변수로 사용하고 있군요.

바로 위와 같은 상황처럼 Value 타입의 변수를 Reference 타입인양 사용할 경우에 Boxing이 일어납니다.

IL코드를 확인해 볼까요?

.method public hidebysig instance void Method() cil managed

{

     // Code Size: 20 byte(s)

     .maxstack 2

     .locals (

     [mscorlib]System.Collections.ArrayList list1)

     L_0000: newobj instance void [mscorlib]System.Collections.ArrayList::.ctor()

     L_0005: stloc.0

     L_0006: ldloc.0

     L_0007: ldc.i4.5

     L_0008: box int32

     L_000d: callvirt instance int32 [mscorlib]System.Collections.ArrayList::Add(object)

     L_0012: pop

     L_0013: ret

}

AL_0007에서 4바이트 정수 5를 스택으로 로드하고 있습니다.

그리고 다음줄에서 우리가 기다리던 boxing을 하는군요.

ArrayList에 실제로 저장되는 값은 뭘까요?

앞에서 말씀드린 바와 같이 Add()함수의 매개 변수는 Object이기 때문에 5라는 값이 아니라 4바이트의 주소 포인터를 저장해야 한다는 것을 우리는 이미 알고 있습니다.

integer가 object로 변환되는 과정이 필요하겠군요.

integer가 가지고 있던 5라는 '값'은 힙에 생성한 새로운 주소 공간으로 copy되고 그 값이 저장된 주소를 리턴받습니다.

value 타입의 integer(int32)가 reference 타입의 object가 변환되었습니다.

이렇게 닷넷에서 우리가 모르는 사이에 value 타입의 변수를 reference처럼 사용할 수 있도록 해주는 것을 boxing이라고 합니다.

Unboxing

자 그럼 이제 Unboxing 에 대해 알아보도록 하겠습니다.

Unboxing은 간단히 boxing의 반대 과정이라고 보시면 됩니다.

public void Method()       

{           

ArrayList ar = new ArrayList();

ar.Add(5);

int b;

b = (int)ar[0];

}

Unboxing이란 object에 저장된 주소값으로부터 '값'을 얻어다 스택에 생성해둔 변수 b에 copy하는 과정입니다.

마찬가지로 IL 코드에 unbox라고 나오는걸 보실수 있습니다.

.method public hidebysig instance void Method() cil managed

{

     // Code Size: 34 byte(s)

     .maxstack 3

     .locals (

     [mscorlib]System.Collections.ArrayList list1, int32 num1)

     L_0000: newobj instance void [mscorlib]System.Collections.ArrayList::.ctor()

     L_0005: stloc.0

     L_0006: ldloc.0

     L_0007: ldc.i4.5

     L_0008: box int32

     L_000d: callvirt instance int32 [mscorlib]System.Collections.ArrayList::Add(object)

     L_0012: pop

     L_0013: ldloc.0

     L_0014: ldc.i4.0

     L_0015: callvirt instance object [mscorlib]System.Collections.ArrayList::get_Item(int32)

     L_001a: unbox int32

     L_001f: ldind.i4

     L_0020: stloc.1

     L_0021: ret

}

쉽게 이해가 가시리라고 봅니다. :)

정리

boxing과 unboxing을 가능하면 피하는게 좋다는 말을 한번쯤 들어보셨을 겁니다.

위에서 보신것처럼 boxing, unboxing이란 닷넷의 배려는 우리가 편하게 프로그램을 짤 수 있도록 했는지는 모르지만

IL 코드에서 확인할 수 있는 것처럼 더 많은 과정을 거치고, 메모리를 사용하고, 속도가 느려지게끔하는 효과를 가져올 수 있습니다.

boxing하는 과정에서 값을 copy하기 위해 힙에 주소 공간을 확보해야 한다는 것을 기억하실 겁니다.

잦은 boxing은 사용되지 않는 리소스를 정리하기 위해 비용이 큰 Garbage Collector가 동작하는 주기를 더 짧아지게 할 수 있습니다.

그렇다면 불필요한 boxing을 막으려면? boxing이란 결국 value type의 변수를 reference type인 object로 암시적으로 변환하는 것입니다.

만약 객체가 boxing될 것이 자명하다면 처음부터 object를 사용하면 되겠죠.

만약 사용하는 value type의 변수가 32비트 이상이고(크기가 크면 클수록 복사될 때 더 큰 비용을 사용합니다)

boxing, unboxing이 자주 일어나는 구조라면 struct(value type)가 아니라 class(reference type) 를 사용하는 것이 유리합니다.

때문에 객체의 타입을 정할 때는 객체의 크기와 얼마나 자주 copy되는지를 고려해야 할 것입니다.

출처 : http://tit99hds.egloos.com/540695