태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

'2010/02'에 해당되는 글 2건

  1. 2010/02/16 Type Conveter의 네이밍 컨벤션은 어떻게 정해야 할까?
  2. 2010/02/03 객체지향 방법론과 프레임워크 디자인 vs. 어플리케이션 디자인 차이 (3)

Type Conveter의 네이밍 컨벤션은 어떻게 정해야 할까?

.Net/.Net Framework Design Guide Line 2010/02/16 13:44

프레임워크 또는 라이브러리 디자인에서  타입 변환 메소드 의 Built in  네이밍 컨벤션을 살펴보고, 디자인 시에 Type1 To Type2 보다는 Type2 From Type1 을 사용하는 것에 대해 생각해 보자.


.NET 타입 변환의 형태의 예시

1. 인스턴스로 부터 변환
object.ToString();
StringBuilder.ToString();

2. Convert 클래스
int number= Convert.ToInt32(Object value);


3. Type 메소드
int number= Int32.Parse(string s);


4. Type TryParse 패턴

int number;
bool result = Int32.TryParse(value, out number);



TryParse를 제외한 모든 네이밍 컨벤션이 Instance.ToTypename() 형태 입니다. 속성으로는 Primative Type 간의 변환이라는 것이 특징입니다.

이제 자세히 살펴 봅시다.

1번의 경우 표현식 자체가 내장된 값 자신이며, 그것이 바로 왼쪽의 변수에 대입 됩니다.

2. 3번 은 입력되는 타입을 반환되는 타입으로 변환 대입합니다.

4번은 TryParse 패턴으로 반환값이 두개( 메소드 성공 실패와, 변환된 값 ) 인 관계로 특수한 경우 입니다.



1,2,3번의 경우로 볼때 To 라는 네이밍이 쓰였지만 Context 로는  [변수타입] = To [반환타입] (입력값)  입니다.



대입 assign 은 왼쪽에서 오른쪽으로 읽으면서 들어가면서 자연스러운 인지를 형태 입니다.
인지의 순서는  [3: 변수 타입] = To [2: 반환타입] (1: 입력값) 오른쪽에서 왼쪽으로 한번의 일렬 인지를 요구합니다. 



결론

1. Type에  Extention 으로 추가되는 네이밍으로는  ToTypename(this Type, o value) 를 사용 합니다.

2. 내장된 값을 변환해서 반환 할때에는 instance.ToTypename() 을 사용 합니다.

3. Helper 클래스의 메소드 네이밍으로는 Helper.Type2FromType1(value) 를 사용 합니다.




혼란스러운 네이밍, 왜 Type1 To Type2 보다 Type2 From Type1 이어야 하는가?

C의 문법 규칙으로 String 을 Inteager로 변환하는 함수인 atoi(const char *string )
char *s ;
s = "1234";
int number = atoi(s);

[변수타입] = [입력타입] to [반환타입] (입력값)  의 패턴을 형성합니다. 

[4: 변수타입] = [1:  입력타입] to [3: 반환타입] ( 2: 입력값)  으로 건너뛰기 + 왼쪽에서 오른쪽 + 오른쪽에서 왼쪽 의 인지를 요구합니다.



Type2FromType1의 형태로  네이밍 된다면
atoi -> ifroma

char *s ;
s = "1234";
int number = ifroma(s);

[변수타입] = [반환타입] from [입력타입] (입력값) 을 형성하며

[4: 변수타입] = [3: 반환타입] from [2: 입력타입] (1: 입력값) 으로 오른쪽에서 왼쪽으로 한번의 인지 과정만을 요구 합니다.






저작자 표시
이올린에 북마크하기(0) 이올린에 추천하기(0)

현재글 : Type Conveter의 네이밍 컨벤션은 어떻게 정해야 할까? posted By - 반더빌트 2010/02/16 13:44
Trackback 0 : Comment 0

Trackback Address :: http://smack.kr/trackback/360 관련글 쓰기


[생각을 적어 주세요~ 댓글은 작은 인연의 씨앗입니다.]


객체지향 방법론과 프레임워크 디자인 vs. 어플리케이션 디자인 차이

.Net/.Net Framework Design Guide Line 2010/02/03 14:59
객체지향방법론은 프레임워크 디자인과 어플리케이션 디자인에서 약간의 차이를 보입니다.
객체지향 방법론은 유지관리성에 최적화 되어 있고, 어플리케이션 디자인 적용에서 더욱 가깝습니다.  이 포스트에서는 어플리케이션 디자인, 커스텀 라이브러리 디자인, 프레임워크의 디자인에 적용되는 객체지향방법론의 약간 다른 접근에 대해서 서술합니다.


Framework의 탄생
운영체제 벤더 들은 추상화된 API를 제공함으로써 개발자들이 좀더 쉽게 어플리케이션을 개발할 수 있다는 것을 인지 하였습니다.

동시에 Object-Oriented 방법론은 확장성과 재사용성 강조하는 방법론 이었고, 운영체제 와 라이브러리 벤더들은 OO방법론을 채택하였습니다. 이것이 우리가 생각하는 Framework의 개념의 탄생입니다.

더 많은 벤더들이 서로 연결함으로써 하나의 어플리케이션을 완성할 수 있는 재사용 가능한 컴포넌트들을 제공하였고, 어플리케이션 개발자들은 더이상 매번의 개발마다 맨땅에서 시작하는 일이 없을 줄 알았습니다.

하지만, 몇몇 컴포넌트들은 서로 잘 접합되지 않고, 필요 없는 요소들로 가득한 경우가 많아서 생산성에 부정적인 영향을 주게 되었죠.

결국에는 재사용 가능한 컴포넌트들에게 공통적인 룰을 적용함으로써  일관성(consistency)과 이음매 없는 통합(seamless integration)이 가능하다는 것이 명확해 졌습니다.

이로써  객체지향 방법론은 프레임워크( Framework ) 에 뼛속 깊이 스며들게 됩니다.

하지만, 프레임워크 디자인에 객체지향 방법론을 적용할 때 주의해야 할 사항이 있습니다.




어플리케이션 디자인
어플리케이션 개발자들은 프레임워크 위에 커스텀 라이브러리를 접합시키고 이를 이용하여 하나의 어플리케이션을 개발합니다. 유지관리성이 중요한 요소 입니다.





과도한 엔지니어링(OverEngineered) 문제

커스텀 라이브러리 디자인은 어플리케이션 디자인 보다는  프레임워크 디자인 개념에 가깝습니다.

개발자들이 프레임워크 디자인을 하지 않더라도 커스텀 라이브러리 디자인은 어플리케이션 디자인과는 다른 접근이 필요합니다.


객체지향디자인 방법론은 유지관리성에 최적화 되어 있습니다. 이는 지나친 추상화와 상속 구조를 강요합니다.

기반클래스(Base Class)의 수정으로 파생된 모든 클래스를 관리할 수 있으며, 코드 재사용을 지원하며 , Single Control Management를 가능하게 하기 때문이죠.

문제는 지나친 추상화와 상속은 프레임워크와 라이브러리 사용자로 하여금  간단한 시나리오의 어플리케이션을 작성할 때에도 전문가 이기를 강요하게 됩니다.





확장성에 대한 조금 다른 접근
어플리케이션 디자인에서의 클래스의 봉인(sealing)은 프레임워크 디자인에서의 것 보다 일반적 입니다. 어플리케이션과 커스텀 라이브러리는 도메인 specific 적입니다. 도메인에서의 역할 이외에 상속 되거나 확장되지 않도록 하는 것이 중요하며, 프레임워크는 어플리케이션 과 커스텀 라이브러리의 경우보다 일반적으로 사용되거나 확장되도록 허용 하는 것이 중요합니다.

어플리케이션과 커스텀 라이브러리가 sealed 가 일반적이라면 프레임워크 디자인은 unsealed 로 확장성을 중시 하는 것이 일반적이라고 볼 수 있습니다.






Interface에 대한 관점
프레임워크 디자인 가이드라인으로는 Interface 보다는 Class의 사용을 가이드 합니다. 프레임워크는 라이프사이클이 길고, shipping 된 후에 Class는 변경 가능하지만 Interface는 변경 불가능하면, Interface의 변경은 모든 구현된 객체의 변경을 요구하기 때문입니다.  Interface 보다는 Class가 좀더 유연하다는(flexibility) 관점입니다.

어플리케이션의 디자인에서는 Interface를 선택하는 것을 가이드로 할 수 있습니다.



결론
어플리케이션 디자인, 커스텀 라이브러리 디자인, 프레임워크 디자인에 모두 객체지향 디자인 방법론이 적용 되지만, 어플리케이션 디자인에는 유지관리성이, 프레임워크 디자인에서는 유연성과 확장성이 강조되고 커스텀 라이브러리 디자인은 둘 사이의 중간에 위치한다고 말 할 수 있습니다.



참조 : Framework Design Guidelines Second Edition , Addison-Wesley p.2, p32. p91.
저작자 표시
이올린에 북마크하기(0) 이올린에 추천하기(0)

현재글 : 객체지향 방법론과 프레임워크 디자인 vs. 어플리케이션 디자인 차이 posted By - 반더빌트 2010/02/03 14:59
Trackback 0 : Comments 3

Trackback Address :: http://smack.kr/trackback/358 관련글 쓰기

  1. 김종윤 2010/02/03 18:54 Modify/Delete Reply

    좋은 내용 잘 봤습니다. 다만, Interface에 대한 관점에 대해서는 경우에 따라 이견이 있지 않을까 싶네요.
    제가 .Net쪽 프레임워크보다는 Java쪽 프레임워크에 익숙하여 오해가 있을 수도 있음을 먼저 말씀드립니다.

    프레임워크 디자인시 로직의 흐름이나 객체의 행위에 대한 부분을 추상화하여 제공하는 경우에는 Interface의 사용을 가이드하고, 자료 구조나 속성에 대한 부분을 추상화하여 제공하는 경우에는 Class의 사용을 가이드하는게 좋지 않을까 싶습니다. Interface의 사용을 가이드한 부분은 사용의 편리함을 위해 기본 구현체 Class를 제공할 수도 있겠지만 기본적으로는 Interface가 프레임워크 디자인의 기초가 되겠지요.

    프레임워크에 대한 여러가지 정의가 있을 수 있겠지만, 단순화하여 프레임워크의 구성을 애플리케이션 개발시에 개발자가 직접 구현해야 하는 빌딩 블록 부분(Hot Spot)과 프레임워크가 제공하는 기능을 그대로 사용하는 부분(Frozen Spot)으로 나눈다면 빌딩 블록 부분은 Interface 위주로 그대로 사용하는 부분은 Class 위주로 디자인 하는 것이 좋지 않을까 싶습니다.

    Shipping 이후 Interface의 변경보다 Class의 변경이 더 쉬울 것이라는 부분에서도 프레임워크를 어떻게 디자인하느냐에 따라 달라지겠으나, 프레임워크 디자인을 Class로 가이드 한다라는 것이 결국, Interface의 역할을 Class가 대신하는 것이라고 보면 변경의 어려움은 어느 쪽을 쓰던지 동일할 것으로 보입니다.

    닷넷쪽 프레임워크에 관련된 꼭지라 제 생각의 방향이 다를 수도 있으나, 객체지향과 프레임워크라는 주제에서만 접근한다면 크게 다른 점이 없을 것 같아 짧은 글 남깁니다.

    • 스맥 반더빌트 2010/02/03 21:31 Modify/Delete

      네 종윤님의 통찰력 깊은 말씀 잘 읽었습니다.

      방법론에서 Java쪽 프레임워크와 .NET쪽 프레임워크가 거의 비슷하다고 보여집니다.

      프레임워크의 경우 다른 레이어에 비해 생명주기가 길다는점, Shipping 이후의 변경이 어렵다는 점이 Interface 보다 Class의 사용을 가이드 하는 것으로 보입니다. 프레임워크의 버전업 릴리즈시에 Base Class에 메소드를 추가함으로서 행위를 추가할 수 있으나 Interface의 경우에는 불가능하다는 점이 Flexiability 요소로 판단되는 것으로 보입니다.

      이 포스트를 작성하게 된 이유가 바로 종윤님 께서 언급하신 것들에 대해서 다시 한번 생각해 보기 위해서 였습니다. 어플리케이션 디자인 시와 프레임워크 디자인시의 약간 다른 관점(Slightly Different Perspective)에 대해서 말이죠.

  2. arload 2010/02/20 01:47 Modify/Delete Reply

    :) 좋은 말씀들이 오고 같네요.

    Framework의 도메인에 따라 사용성 테스트를 먼저 진행하고,
    최소한 타켓 어플리케이션 3개를 하나의 프레임워크로 구현해 보면,
    어느정도 윤곽이 나올거 같습니다.

    참 어려워요. Framework 설계라는 것은. 한번 만들면, 쉽게 못바꾸니.. 그리고 각 Feature나 시나리오 별로 변화의 전파를 하나의 Namespace안에 가두는 것도. 참으로 중요한거같구요..

    정말 쉽지 않은 작업인건 사실인거 같습니다.


[생각을 적어 주세요~ 댓글은 작은 인연의 씨앗입니다.]