미래의 SW설계자

Tue, 19 Jan 2010 23:55:03 +0900

2009/12/29 00:13:27 에 시작되었습니다.

아래와 같은 차례로 할 예정입니다.

하위페이지

미래의 SW설계자

저의 개인페이지는 http://pozz.net 입니다.

2010/01/19 23:54:55

내용들은 아래로 포스팅 합니다.

http://loger1000.tistory.com/

2010/01/19 23:54:42

티스토리가 있으니.. 이 스프링 노트는 비공개로 할까 생각중입니다.

03.A. 스크럼과 xp : 책

Mon, 11 Jan 2010 12:34:46 +0900

2010/01/11 12:24:08

	판매가	19,800원 → 17,820원 10%
	마일리지	10% 1,780원

	발행일	2009-05-06
	ISBN	8991268609 \| 9788991268609
	기타정보	번역서 \| 232쪽

	예상출고일	금일 가능 (근무일기준)
	배송비	2,000원 (20,000원이상 무료배송)

프로젝트관리

종합지수 36p 9 위

월간지수 100p 1 위

주간지수 100p 1 위

책 정보 출처 : http://kangcom.com/sub/view.asp?sku=200904240001

딱 한마디로..

위 책을 읽기 시작하면서, 끝날 때까지, 변하지 않았던 몇마디가 있다.

[ 스크럼, xp, 애자일 회고 ] 세개 짬뽕한거 같다...

깊이 있는 이야기보다는, 애자일의 관점의 큰 맥락을 짚어 볼 수 있는 책인거 같다.

다행히 scrum, xp, agile이 무엇인지 알고 있었기에, 이 책의 페이지들을 쉽게 넘겼던 것 같다.

하지만, 글이 쉽게 쓰여진 것은 아니다. 내용이 어렵다는 것 보다는, 조금 재미없게 풀어쓴 부분들이 있어서다..

( 어디까지나 내 개인적인 생각이다. )

개발자에게는, 이 책 보다는, 순수 scrum, xp, agile에 관한 책을 좀 더 권고하고싶다.

컨설턴트나 비 전공자에게는 이책이 더 어울릴수도 있을 것같다.

여기에 나왔던 내용들은 이미 원론적인 책들에서 나왔던 것들이라서,, 이 책의 내용을 적어야 할지 말아야 할지.. 난감하기도한다.

이제, 이 책의 내용을 조금 공유해 보겠다.

아래 내용은 책 내용보다는 이 책을 읽으면서, 내가 생각하고 되돌아 보게되는 점이 더 많을꺼라 생각된다.

차분히 읽다 보면, 프로젝트 진행시, 너무나도 뻔한 이야기들을 하고 있다.

그러나... 우리는 이 애자일 말고도, 뻔히 알고 있으면서도 행하지 않는 사람들은 수두룩 하다.

이 책의 내용도 마찬가지다. 너무나 뻔한 이야기이고, 너무나 쉬운 원리이다.

그러나... 이 쉬운원리를 현장에서 적용시키는 것이 어렵다.

무척 지겹게 들었을 거라 생각된다. [ 기본에 충실하라 ]

이걸 다 읽고 나면, 저 위의 [ 모토 ] 가 머릿속에 "반짝!" 하고 떠오를 사람이 꽤 있을거라 생각된다.

스크럼의 기본은 아주 간략하다.

03. Agile

Mon, 11 Jan 2010 12:23:25 +0900

2010/01/11 12:22:59

002. TDD ( Test Driven Development )

Fri, 08 Jan 2010 16:04:41 +0900

느낀점
아쉬운점
놀란 점
마무리

2010/01/08 13:00:01

테스트 주도 개발 책을 읽었다.

( 최근에 훑어읽기.. 했음 )

테스트 주도 개발 (Test-Driven Development): 8.44 | 네티즌리뷰 18건; 켄트 벡 저 | 김창준 역 | 인사이트 | 2005.01.02기본정보 더보기

책 정보 출처 : http://book.naver.com/bookdb/book_detail.nhn?bid=1486282

느낀점^#

크게 느낀점을 간략하게 적으면 아래와 같다.

Bottom-Up 개발 방법이 가능하다는 것
- 테스트를 주도 하면서 추상화와 인터페이스화를 적응하면서 설계해 나간다는것
초록 막대 테스트를 코드에 심어 놓음으로써 지속된 리펙토링을 통해 견고한 코드가 생긴 다는 것
- 초록 막대가 됨으로써 리펙토링이 성공적으로 진행된다는 안도감
- 빨간 막대를 놔둠으로써 ( 인위적인 에러 ) 코드를 짜야 할 위치를 알려주는 알람 기능
진정한 테스트 주도 개발 마스터가 되는 것은 끊임 없는 노력을 통한 연습에 결실이라는 것
- 이 책은 말이 테스트 주도 개발이지, 많은 내용이 함축되어 있었다.
- 다행히 그동안, 천천히 읽어 왔었던, 여러 방법론들과 언어, 그리고 객체지향적인 사고와 디자인 패턴 등을 접해서 그나마 남들보다 쉽게 이 책을 섭렵한것 같다.

아쉬운점^#

매우 아쉬운 점이 하나 있다.

그것은... java script나 max script 또는 flash action script등의 별 특이한 script 언어들을 다뤄 봤었지만...

python 스크립트 언어에 대해서는 배워 보고 싶었지만, 기회가 없었다.

하필... 그 python언어를 가지고 테스트 프레임워크를 써주신 켄트벡 형이 약간 밉긴했다. ㅋㅋ

덕분에 python을 한번더 배워보고 싶다는 생각이 들게 된 계기이기도 했다..

그러나.. 현 시점에서 영어가 더 배우고 싶을 뿐만 아니라, 시급하다는 것이다.. ^^

놀란 점^#

그리고, 스스로에게 놀란점이 있다.

내가 디자인패턴을 학습한 뒤, 모든 사물 및 눈으로 보이는 형상화 된 것을 객체지향적으로 설계를 시도한적이 있다.

참으로 놀라운건.. 모든게, 객체지향적으로 구성될 수 있고, 표현될 수 있고, 사용될 뿐만 아니라, 집약하여 원리를 뽑아 낼수 있다는 것이다. 그 뿐이 아니라, 수학 또는 과학에서 일컫는 [ 원리 ] 라는 이 개념도 적용이 가능하다. 물론, 가장 오래된 건축도 객체지향적으로 풀어낼수있으며, 격투기나 기타 운동관련된 것도 객체지향으로 풀어낼 수 있다. 그 내용이 TDD 책에서 나왔다는 점이다.

( 코드를 예를 드는 것이 편할 것 같다.. )

또한 모든 내용들을 객체지향적으로 풀어낼 뿐 아니라, 복잡하게 꼬여 있는 코드들도 객체지향적으로 리펙이 가능하다는 것이다. 이말을 좀더 학식적(?) 으로 풀어내자면, 일반적으로 설계를 하고 개발진행하는 것은 Top-Down방식인데, Bottom-Up 방식 적용이 가능하다는 것이다.

내가 배울 때, 소프트웨어 공학의 초기에는 안전한 소프트웨어 개발을 위해서는 Top-Down방식을 도입하여, 목표설정을 알맞게 하여, 견고한 소프트웨어를 만들자는 거였다.

그러나.. 객체지향을 제대로 이해한다면, Top-Down이 필수조건이 아니라, 선택 조건이 될수 있다.

Bottom-Up방식을 도입하여, 유연한 소프트웨어를 얼마든지 만들어 낼수 있다. 그와 관련된 내용은 TDD 책 내용의 초반부 ( 1/3 부분 )에 잘 나와있다.

개인적인 생각으로 TDD책 중 가장 어려운 부분이 책 내용의 초반부가 아닐까 하는 생각을 한다.

내 입장에서는 중간 부분 ( 2/3 부분 ) 이 가장 어려웠는데, 이유는.. python의 문법을 몰라서 어려웠지만, 대략 무슨말 하는지는 알 수 잇었다. 다음에 python 문법을 학습하고 TDD 책을 한 번 더 읽어봐야겠다는 생각을 했다.

정리해 보자면, 내 스스로에게 놀라고, 이 책을 보면서 동시에 놀란점은..

이 책을 보기전에, 내 스스로가 테스트 주도 개발을 향하고 있었다는 점이고,

이 책을 보면서 놀란 것은, 객체지향적 사고를 가진다면 누구나 자연스럽게, TDD 찾게 될 것이라는 켄트 벡 형님의 말이었다.

마무리 ^#

내가 생각하지 못했던 부분들과 정리되지 않았던 생각들을 정리해주는 내용들이 많이 있어서, 이 책을 읽는 시간이 상당히 의미 있는 시간이었다.

020.A.마. Design Pattern의 사소한 차이점(C++ / Java)

Wed, 30 Dec 2009 00:23:07 +0900

author : LogerC

date : 2009-11-13 15:48

Design Pattern to Use in Cpp

Java ( c# ) 과 C++ 에 적용 되는 디자인 패턴의 사소한 차이점

C++에 적용되는 디자인 패턴, 그리고 java나 c#에 적용되는 디자인 패턴.. 학습하고 나면, 별 다른거 없어 보이지만,

C++에 적용 되는 디자인패턴은, 처음 접하는 사람에게 무척 복잡해 보인다. 그 이유는 같은 문법을 가지고 다양한 효과를 내기 때문이다.

반면에 Java나 c#의 경우는 처음 접하는 사람에게 C++보다 좀 더 쉽게 접근할 수 있다. 그 이유는 C++과는 다르게 java(c#)은 클래스 상속 및 추상화 그리고 인터페이스에 대한 문법을 각각 나누어 사용하기 때문에 접근이 쉽다는 것이다. 그렇다면 C++에서는 클래스 상속 및 추상화 의 사용 그리고 인터페이스를 하나의 방식으로 사용 한다. 그 차이점을 서두에 작성하고자 한다.

처음 코드를 볼 때 뭐가 다른가.. 잘 모를것이다. 그러나 끝까지 읽어 보면.. C++로 디자인 패턴을 학습하는데 있어 무척 헷갈릴수있다는 걸 느낄 수 있을 것이다.

java나 c# : 그냥 java라고 줄여 말하겠다.

java에서 interface를 정의 하고 interface끼리도 상속등을 통해 확장이 가능하다.

c++에서 interface를 정의하고 interface끼리도 상속등을 통해 확장이 가능하다.

* 아래 코드는 컴파일 해보지 않았으므로 컴파일 에러가 뜰 수 있습니다. ( 그냥 바로 타이핑 한 것임을 미리 알립니다. )

단순 인터페이스를 상속 받아서 구상 클래스에서 구현

java code

interface IA
{
public void foo();
}
class ConcreteB implements IA
{
public void foo()
{
}
public int a;
}

c++ code

class IA
{
public :
virtual void foo() = 0;
}
class ConcreteB : public IA
{
public :
ConcreteB();
~ConcreteB();
public :
virtual void foo();
public :
int a;
}
void ConcreteB::foo()
{
}

단순 추상 클래스로부터 상속 받아서 구상 클래스에서 구현

java code

abstract AbsA
{
public void foo()
{
}
public int a;
}
class ConcreteB implements AbsA
{
public void foo()
{
}
}

c++ code

class AbsA
{
public:
Abs() {}
~Abs() {}
public:
virtual void foo();
public:
int a;
}
void AbsA::foo()
{
}
class ConcreteB : public AbsA
{
public:
ConcreteB();
~ConcreteB();
public:
virtual void foo();
public:
// int a;
}
void ConcreteB::foo()
{
}

어떤가..

C++은 그냥 다 Class 연산자로 처리하죠. 분명히..!! 의미하는 개념은 다르다.

interface와 abstract에 대한 개념은 생략한다. 이해가 필요한 경우 검색을 통해 이해 하기 바란다.

Singletone 기본중에 기본이죠 ㅡ.ㅡㅎ

2009/11/11 19:34:35

쓰레드에는 안전하지 않음. 각 플랫폼마다 동기화 지원해주는게 조금씩 다르니.. ㅡ.,ㅡv

Head File : SClass.h

class SClass
{
private:
static SClass* uniqeInstance ;
private:
SClass() { }
~SClass() ;
public:
static SClass* GetInsance();
public:
void Show();
}

Cpp File

#include "SClass.h"
SClass* SClass::uniqeInstance = NULL;
SClass* GetSClass()
{
return SClass::GetInsance();
}
SClass* SClass::GetInsance()
{
    if(uniqeInstance == NULL)
    {
        uniqeInstance = new SClass();
    }
return uniqeInstance;
}
void SClass::Show()
{
//show
}

Example

#include "SClass.h"
....
...function(....)
{
...
SClass::GetInstance()->Show();
...
}

020.A.라. 다중상속 : virtual based class

Wed, 30 Dec 2009 00:18:10 +0900

cpp의 가상 기반 클래스

cpp의 상속에는 public protected private가 있다.

그리고 중급에 가면 virual 상속이 있다. 이것은 다중 상속을 할 때 강력한 기능을 한다.

그 중 가장 큰 장점은 ( 얼핏보면 단점으로 보인다 ) 각각 다중 상속시 4바이트의 (포인터영역) 공간을 허비 하지만,

4바이트 보다 훨씬 큰 내용들을 상속받을 때는 큰 비용을 얻는다.

자세한 내용은 위의 관련 페이지를 읽기를 권장한다. 아래의 코드는 위 코드를 이해 하기 위해 작성해본 간단한 코드이다.

virtual 상속이 대체 무엇인지 궁굼해 할수 있다. 현재 여기에서 사용하는 다중 상속은 여러가지로 활용될 수 있다.

이해를 돕기 위해 하나의 국한된 예를 들자면, Java나 c#의 interface 선언으로 생각하면 이해 하기 쉽다.

결과

33, 2, 1

코드

#include <iostream>

using namespace std;

class virtualA
{
public:
virtualA(int a)
{
  _a = a;
}
public:
int _a;
};

class deriveA : virtual virtualA
{
public:
deriveA(int a, int da) : virtualA(a)
{
  _da = da;
}
public:
int _da;
};

class deriveB : public virtual virtualA, public virtual deriveA
{
public:
deriveB(int a, int b, int da):virtualA(a), deriveA(33333, da)
{
  _b = b;
}
public:
int _b;
};

int main(void)
{
deriveB * testClass = new deriveB(1,2,3);
cout << testClass->_a << ", " << testClass->_b << ", " << testClass->_da << ", ";

return true;
}

020.A.다. 상속 ( 생성자, 함수 ) : Virtual과 일반

Wed, 30 Dec 2009 00:15:06 +0900

source.cpp
result

author : LogerC

Data : 2009/11/27 09:34:13

Test Tool : MS visual studio 2005

C++에서 테스트 해 본 것은 상속에서 쓰일 때 호출되는 관계를 보고자 한것이다.

생성자와 파괴자를 상속 했을 때 호출관계 :
1. 생성자 ( inline 문법만 만 제공 ) :
  최상위 ( 상속해준 [ 부모 ] ) 클래스부터 현재( 상속 받은 [ 자식 ] ) 클래스 까지 함수가 타고 내려온다.
2. 파괴자 ( virtual 문법 제공 (안해도 자동으로 Virtual 기능 ) ) :
  Virtual 을 하던 안하던 최 하위 클래스부터 최상위(상속해준[부모]) 클래스로 함수가 타고 올라간다.
가상 함수와 일반 오버라이딩 함수 호출은 포인터 ( * ) 로 인스턴스를 사용 할 때와 일반 지역 인스턴스로 사용할 때, 달라지는 모습을 보였다.
코드는 [ Base::foo(); printf("Derive foo\n"); ] 이와 같이 호출 하여 테스트 했다. 즉 인위적으로 상위 클래스 함수를 호출한다.
아래와 같은 특이한 부분이 발생했다.
1. 일반 지역 변수
  1. 가상 함수 : 위 클래스 가상함수에 접근 가능하다.
  2. 일반 함수 : 위 클래스 일반 ( 오버라이딩 ) 함수에 접근 가능하다.
2. 포인터 인스턴스
  1. 가상 함수 : 위 클래스 가상함수에 접근 가능하다.
  2. 일반 함수 : 위 클래스 일반 ( 오버라이딩 ) 함수에 접근 불가능 하다.
3. 내가 알고 있던 것은 포인터 인스턴스와 같이 나와야 맞는 것인데, 일반 지역수 일 때도, 상위 일반(오버라이딩)함수에 접근가능한 것이 신기했다.

source.cpp^#

#include <stdio.h>
#include <iostream>
class Base
{
public:
Base() { printf("Base Create\n"); }
~Base() { printf("Base Destroy\n"); }
void foo() { printf("Base foo\n"); }
};
class Derive : public Base
{
public:
Derive() { printf("Derive Create\n"); }
~Derive() { printf("Derive Destroy\n"); }
void foo() { Base::foo(); printf("Derive foo\n"); }
};
class BaseVirtual
{
public:
BaseVirtual() { printf("BaseVirtual Create\n"); }
virtual ~BaseVirtual() { printf("BaseVirtual Destroy\n"); }
void virtual foo() { printf("BaseVirtual foo\n"); }
};
class DeriveVirtual : public BaseVirtual
{
public:
DeriveVirtual() { printf("DeriveVirtual Create\n"); }
virtual ~DeriveVirtual() { printf("DeriveVirtual Destroy\n"); }
void virtual foo() { BaseVirtual::foo(); printf("DeriveVirtual foo\n"); }
};
int main(void)
{
BaseVirtual* DV = new DeriveVirtual();
printf("------------------------------------------------\n");
Base* D = new Derive();
printf("------------------------------------------------\n\n");
DV->foo();
printf("------------------------------------------------\n");
D->foo();
printf("------------------------------------------------\n");
delete DV;
delete D;
printf("==============================================\n\n");
BaseVirtual DV2;
printf("==============================================\n");
Base D2;
printf("==============================================\n\n");
DV2.foo();
printf("==============================================\n");
D2.foo();
printf("==============================================\n");
return 0;
}

result^#

BaseVirtual Create
DeriveVirtual Create
------------------------------------------------
Base Create
Derive Create
------------------------------------------------

BaseVirtual foo
DeriveVirtual foo
------------------------------------------------
Base foo
------------------------------------------------
DeriveVirtual Destroy
BaseVirtual Destroy
Base Destroy
==============================================

BaseVirtual Create
==============================================
Base Create
==============================================

BaseVirtual foo
==============================================
Base foo
==============================================
Base Destroy
BaseVirtual Destroy
계속하려면 아무 키나 누르십시오 . . .

020.A.나. 예외처리 사용시 유의점 - More effective c++

Wed, 30 Dec 2009 00:12:53 +0900

author : LogerC

date : 2009/12/22 11:20:57

More Effective c++ p. 97 - 124

1. 예외처리에서 catch에서 받아줄 때, 항상 복사 개체를 받는다. ( 값전달, 주소전달, 포인터전달 모두 다 복사 함 )

이를 극복하는 건 new exception(); 으로 받아서 받아주는 catch()에서 delete 해준다.

그러나 new를 할 때에 주의해야 할 부분이 new할 때에도 exception이 날수도 있으며,

항상 exception할때만 new를 하는게 아닐수도 있다.

2. 예외를 받아줄 때

catch(exception e) 와

catch(exception& e) 는 다형성(상속관계)에서 큰 차이를 보여준다.

< 아래의 코드는 컴파일 확인이 안된 코드이다. - 이해를 돕기 위한 코드임 >

class a
{
virtual void function() { cout << "a"; }
};
class derive : public a
{
virtual void function() { cout << "derive"; }
};
void someFunctionVal()
{
try { throw new derive(); }
catch ( a e ) { e.function(); }
}
void someFunctionRef()
{
try { throw new derive(); }
catch ( a& e ) { e.fucntion(); }
}

someFunctionVal의 예외의 결과는

"a"

someFunctionRef의 예외의 결과는

"derive"

001.G. 소프트웨어를 잘 만드는 법

Wed, 30 Dec 2009 00:10:30 +0900

소프트웨어를 만든 다는 것
변화
소통
1. 신뢰
2. 존중

author : logerC

2009/12/25 12:50:36

소프트웨어를 만든 다는 것^#

필요한 것^#

소프트웨어를 잘 만든다는 것이 C나 C++ 또는 자바나 델파이 등 언어를 잘 다룬다는 것은 아니다.

위와 같은 기본 언어를 잘 한다고 해서 소프트웨어를 잘 만들지는 못한다.

그러나, 소프트웨어를 잘 만드는 사람은 기본 언어를 잘한다 ^^

그렇다면, 소프트웨어를 잘 만드는 사람과 소프트웨어를 잘 만들지 못하는 사람의 차이가 무엇일까?

이 주제를 풀어 내기 위한 여러 관련 서적이 등장해 있다.

내가 학습했던 책들은 아래와 같다.

표준 UML, OOP, OOP & Anal, XP, RUP, Agile, Design Pattern, ...

그리고, 전공서적만이 아니라, 대화법, 설득법, 사회생활에서 살아남는 법 등의 서적들을 학습했다.

전공을 잘해야 소프트웨어를 잘 만든다?^#

우리가 흔히 소프트웨어를 만든다고 하면, 전공을 잘해야 잘 만든다고 생각한다.

그러나 정말, 상당히 큰 오해다.

프로젝트의 시작부터 끝을 기본 골격에서 간략히 살펴보자.

프로젝트를 만나면, 프로젝트의 결과는 고객에 의해, 결정된다.
즉, 고객 요구사항이다.
프로젝트 리더는 요구사항에 따라 필요기술과 기존 기술 또는 제품 동향에 대해 살핀다.
그 후, 역할 분담을 하고, 프로젝트를 시작한다.
요구사항이 바뀌면, 수정해 가면서 계속 진행하면 된다.
완성 후, 고객이 만족하느냐, 안하느냐에 따라, 프로젝트의 존속여부가 결정된다.
우리나라, 거의 대부분의 프로젝트가 만족 스러울리 없다.

모두가 공감하는 기본 프로세스이다. 그러나, 단조롭게 보면 정말 쉬운 프로젝트 진행인데, 대체 무엇이 문제일까.

저 사이에는 팀과 사람 사이의 교묘한 일들이 일어난다.

잠시 소프트웨어 프로젝트를 떠나, 다른 이야기를 예를 들어보겠다.

도미노 쌓기 : 도입^#

4명이서 평방 100미터의 도미노를 쌓는다고 해보자.

각각의 사람들이 아래와 같이 방법들을 제기했다.

첫째는 각 1명씩 평방 50미터씩 네개로 나누어 도미노를 쌓으면 된다.

둘째는 네명이서 같이 나란히 한 라인 씩 채워 가는 것이다.

셋째는 네명이 같이 하는데, 한명은 길이를 재주는 사람, 한명은 쌓는 사람, 한병은 도미노 조각을 배달하는 사람, 한명은 전체적인 흐름을 잡아주는 사람 등으로 할수있다.

넷째는 가위바위보 해서, 몰아주는 것이다.

어떤 걸 하던 상관은 없다. 어떻게든 평방 100미터의 도미노를 쌓으면 되니까..

도미노 쌓기 : 문제 제기^#

왜 갑자기 도미노 이야기가 나왔을까?

소프트웨어가 버그 투성이거나, 진행이 잘 되지 않거나, 잦은 변경사항 등 여러가지

이유에 의해 망가지는 것이 S/W 세계에서만 문제가 되는 것이 아니다.

그리고 도미노에서만 국한되어 문제가 되는게 아니다.

여러 곳에서 협업이 이루어지는 곳에서 문제가 제기된다.

건축을 할때나, 토론을 할 때나, 친구들과 모임을 가지때조차도.. 우리는 같은 문제에 빠지고 허우적댄다.

그럼 이제 도미노를 가지고 하나씩 풀어보자.

도미노 쌓기 : 문제 해결^#

위의 도미노 쌓기 네가지 방법 모두, 탁월한 선택이다. 그러나, 조금 다른 시야로 바라본다면, 좋은 장점만 추려내서 잘 계획하면 더 좋은 방안이 나타난다.

여기에서 우리는 소통의 중요성을 가져올수있다.

아래와 같이 절충안을 가져올 수 있다. [ 정답은 아니다. 답은 여러가지다. ]

먼저, 가위바위보를 해서 각 각 어떤 역할을 맡을 건지 정한다. ( 길이 제기, 도미노 배달, 전체 흐름, 도미노 쌓기 )

전체 흐름을 잡는 사람은 도미노가 쓰러진다고 해서, 다른 부분까지 다 쓰러지지 않도록, 겹치는 부분을 최소화 시킨다.

이 부분에서 변화에 강력한 대응을 할 수 있다.

위의 도미노의 모습이.. 마치 S/W 아키텍쳐 모습이 되려고 하는 것 처럼 보인다.

대체 변화에 강하나는게 무슨말일까?

아래와 같이 번호를 봐보자.

1번 부분이 맘에 안들어서 통째로 바꾸어도, 1번과 4번을 이어주는 선을 잠시 떼어놓고, 1번을 작업해도 다른 부분에 전혀 영향을 주지 않는다.

마찬가지로 5번이 마음에 안들어서, 5번을 고칠 때, 양 쪽으로 뻗는 연결 부위만 잠시 떼어놓으면, 다른 부분에는 전혀 영향을 미치지 않는다.

혹시라도.. 도미노를 쌓다가 흐트러 뜨리기라도 하면.. 중간을 이어주는 이음 선 부분을 슬쩍 떼어주면 된다.

아니면... 애초부터 이음선 부분을 떼어 놓고 시작해도 된다.

네명에서 협동에서 시작을 하다가, 어느정도 가닥이 잡히면, 각각의 영역을 잡아서

각자 일을 진행하면 된다.

어떤가.. 정말 그럴 싸한 도미노가 되지 않을까?

정리 : 해결 내용^#

해결 내용을 간략히 정리 해 보자.

네명이서 초반 역할 분담을 한다. ( S/W 따지면, 시작논의, 짝 프로그래밍 정도가 되겠다. )
대략적인 결과물에 대한 형태가 잡히면, 각 영역을 느슨하게 이어줄 이음세를 찾는다. ( S/W 따지면, OOP&A나 패턴 적용에 해당한다. )
윤곽이 잡히면 정확한 역할분담을 나눈다. ( S/W 따지면, 모듈 작업이 들어간다. )

사실, S/W 개발은 도미노 쌓기보다 더 많은 시간과 지식과 지혜를 필요로 한다.

그 지식과 지혜라는 건,

어렵지 않다. 변화에 능동적이고, 주위와 소통하려는 마음가짐이다.

어려운 것은, 이를 실천하려는 의지의 연속과 실천력이다.

그러나, 위의 간단한 도미노 쌓기 해결 방안 조차 모르는 사람이 많다는게 현실이다.

변화^#

소통^#

신뢰^#

존중^#

020.A.가 오버라이딩, 오버로딩 그리고 가상함수

Wed, 30 Dec 2009 00:08:55 +0900

오버라이딩
1. 소스
2. 출력
오버로딩
1. 소스
2. 출력
가상함수
1. 소스
2. 출력

author : LogerC

Date : 2009/12/28 22:35:59

왜...!!? 이 세가지를 구지 구분해야 할까요?

그냥 사용할줄 알면되지.. 구지 구분해서 알아둘 필요가 있을까요?

네.. 제가 드리고 싶은 말은!

구분해서 정확하게 알아두어야 합니다.

저도 3년 전만 해두... 왜 차이점에 대해서 물어보고, 트집잡는것인가 했었죠.

그러나... 이 차이점은 너무나 중요할뿐만 아니라, 이 세가지를 제대로 구분하지 않는다면

프로그래머로서의 한계가 오실꺼라 생각합니다. 코더에서 머무르시겠습니까?

더 높이 올라가시겠습니까?

오버라이딩 / 오버로딩 / 가상함수

정말 비슷해 보입니다. 차이점을 나열해 보라고 하면

참참참 난감하지요.

이 세가지를 제대로 분리해 낸다면 당신은 충분한 실력가 입니다.

중급의 입장에서 나누어 본 차이점 입니다.

고급으로 가실려면... 이 세가지의 차이점을 확실히 알고,

이 세가지 중에서 가상함수의 위대함을 이해 하고,

가상함수를 통한 OOP 설계가 가능 해집니다.

가상함수를 통한 OOP 설계가 가능해 질 쯔음,

오버라이딩과 오버로딩의 재미있는 것들도 함께 겸비 하시면.. 재미가 쏠쏠합니다. :)

일단... 초급을 떼기 위한 중급수준의 차이점을 나열해 보도록 하죠..

( 간혹 가다가.. 정말 짖궂게 이 세가지의 차이점을 묻는 윗분들이 계시지요..

근데.. 대부분 두가지의 차이점만 많이 물어봅니다. 오버라이딩/오버로딩... )

[ 설마.. 두가지만 물어본다는건.. 그 분은 가상함수를 모른다는거겠죠?

그분도 OOP를 절반밖에 모르는 군요.. 이런이런..아쉽군용..

당신이 거기에서 가상함수까지 쫘르르르 나열해 설명 해 준다면,

윗분께서~ 감탄사가 절로 나겠죠? ^^ ]

여기에는 차이점을 나열한 것이다. 각각의 정보에 대해 세밀한 정보를 원한다면.

Winapi사이트 같은 사이트를 둘러보기를 권한다.

또는 여러 지식인 검색 사이트를 사용하는 것도 현명한 방법이다.

오버라이딩^#

덮어 씌운다.

함수 오버라이딩

[ 오버라이딩은 컴파일 시점에서 정해집니다. ]

상속관계에서 부모의 함수나 변수를 덮고, 새롭게 작성되어 쓰여진다.

over + ride 란 뜻은 위로 올라탄다는 의미입니다.

아래와 같이 간단한 예를 보자.

소스^#

( compile 안한 코드임.. 이해를돕기 위한 코드)

class parent {
void foo() { printf("p"); }
}
class child : parent {
void foo() { printf("c"); }
}
main ()
{
child c;
parent p;
c->foo();
p->foo();
}

출력^#

오버로딩^#

겹쳐 놓고 사용한다. ( 덮는게 아니라 겹친다. 다양한 사용이 가능하다 )

함수오버로딩
연산자오버로딩

[ 오버로딩은 컴파일 시점에서 정해집니다. ]

over + load 란 더 많이 쌓는다는 거죠.

저 두가지의 공통점이 무엇인가? 잘모르겠지요...?

반환형 또는 매개변수로 오는 것이 달라집니다.

반환형(return), 매개변수( func(var) ) 에 따라 달라진다는 겁니다.

이제 조금 감이 올려나? ^^ ( 긴가민가 하실겁니다... 둘다 그랬었나? 이런생각하고계시나요? ㅎ )

함수 오버로딩이란

int foo(int, int);

double foo(double, int)

와 같이 같은 함수명에 매개변수 또는 반환형에 따라 재정의 되어 달라지는거죠

연산자 오버로딩이란

int operator+(int);

double operato+(const double);

과 같이 이미 정의된 연산자를 반환형이나 매개변수에 따라 재정의 되는 것이죠.

왜 오버로딩이라고 하는지 이해 하셨나요?

간단한 소스 적어보죠.

소스^#

( compile 안한 코드임.. 이해를돕기 위한 코드)

class Riding {
private :
double num;
public:
Riding() : num(0.0) { }
double sum(const int a, const int b) { return (double)a+b; }
double sum(const double a, const double b) { return a+b; }
double operator+(const int rhs) { return this.num += (double)rhs; }
double operator+(const double rhs) { retrn this.num += rhs; }
double operator=() { return num; }
}
int main(void) {
Riding r;
cout << "int, int->" << r.foo(1,2) << " double, double->" << r.foo(1.0 + 3.0) << endl;
cout << "int->" << r+1 << " double->" << r+2.0 << endl;

출력^#

int, int-> 3.0 double,double->4.0
int->1.0 double-> 3.0;

가상함수^#

함수가 재정의 되어 사용합니다.

겉에서 볼 때의 특성은 오버라이딩과 매우 흡사합니다.
즉, 덮어 씌어진것처럼 보입니다.
실제로는 오버로딩 되어, 겹쳐진 상태입니다.
- 그러나 변환형, 매개변수가 달라지면 가상함수가 아닙니다.

[ 가상함수는 실행시간에 정해집니다. ]

너무 복잡하죠? 한마디로 한번 더 정리해 드리겠습니다.

작성법은 오버라이딩과 같은 모양새로 작성되지만, 실행결과는 오버로딩처럼 보여집니다.

처음 접하신 분이라면, 이 내용을 이해 하기에는 큰 어려움이 있을꺼라 생각됩니다.

이상하게 생각하지 마십시오. 이걸 한번 보고 이해했다면, 당신은 프랑켄슈타인입니다.

가상함수는 상속관계에서 쓰여지며, 객체지향특성의 핵심중 핵심이라 할수 있습니다.

( 그래서 매우 어려운 것이죠 ... ) .. C에서는 포인터가 핵심이죠? C++이상의 객체지향에서는 가상함수가 핵심이라 해도 과언이 아닙니다.

이해를 돕기 위해 C 이야기 잠깐해보죠.

사용하셨었던 포인터 함수를 기억하시나요?

포인터 함수를 이용해서 가상함수를 흉내낼수도 있답니다.

리눅스같은 씨 구조로 된 OS에서 인터페이스로 포인터 함수를 가지고, 간결화시키죠.

객체지향에서는 가상함수를 가지고 인터페이스화 ( 간결하게 ) 시켜서, 거대한 프로젝트를 단순화 시켜줍니다.

( 가상함수 말고도, 다형성(추상화)을 이용해서 단순화를 시키기도 합니다. 이 내용은 주제에 벗어나므로 생략합니다. )

이제 다시 주제로 넘어오도록 하죠 ^^..

이 부분은 좀 어려우므로 소스를 보면서 이해 하도록하죠.

물론.. 이 소스도 컴파일 시도하지 않은, 이해를 돕기 위한 코드입니다.

소스^#

( compile 안한 코드임.. 이해를돕기 위한 코드)

class IMove {
int go() = 0;
}
class Walk : IMove
int go() { cout << " 저벅 저벅 " << endl; }
}
class Run : IMove
int go() { cout << " 후다닥 후다닥 " << endl; }
}
int main(void)
{
int oops = 0;
IMove* what_Do_I = NULL;
cout << " 걸을거면 1. 뛸꺼면 2. 고르세요! " << endl;
cin >> oops;
switch(oops)
{
default:
cout << "똑바로 안 누를래? .. 형이 지금 기분이 쫌 그런다.."
break;
case 1:
what_Do_I = new Walk();
break;
case 2:
what_Do_I = new Run();
break;
}
if( NULL != what_Do_I )
{
what_Do_I.go();
delete what_Do_I;
}
return 0;
}

출력^#

( 둘중 하나가 나온다. )

이게 바로.... 실행시간에 결정된다는 것이다.

저벅 저벅
or
후다닥 후다닥

가상함수가 먼지 이제 이해 하셧나요?

가상함수는 정말 위대한 것입니다.

현재 당신이 이해 한 내용보다 훨씬 많은 내용을 담고 있습니다.

이제야 수학공부중.. 산수에 속하는.. 1,2,3,4,5,6,7,8,9를 떼셨습니다.

차 후에 좀 더 포스팅 하도록 하죠.

산수에 빗대어서 [ 0 ] 이라는 숫자를 발견했을 때는 어마어마한 발견이었죠.

가상함수를 통해서.. 그 어마어마한 발견을 하실 준비가 되신겁니다.

020.A. C++

Wed, 30 Dec 2009 00:05:10 +0900

미래의 SW설계자

미래의 SW설계자

하위페이지

03.A. 스크럼과 xp : 책

딱 한마디로..

03. Agile

002. TDD ( Test Driven Development )

느낀점#

아쉬운점#

놀란 점#

마무리 #

020.A.마. Design Pattern의 사소한 차이점(C++ / Java)

Java ( c# ) 과 C++ 에 적용 되는 디자인 패턴의 사소한 차이점

단순 인터페이스를 상속 받아서 구상 클래스에서 구현

단순 추상 클래스로부터 상속 받아서 구상 클래스에서 구현

Singletone 기본중에 기본이죠 ㅡ.ㅡㅎ

020.A.라. 다중상속 : virtual based class

결과

코드

020.A.다. 상속 ( 생성자, 함수 ) : Virtual과 일반

source.cpp#

result#

020.A.나. 예외처리 사용시 유의점 - More effective c++

001.G. 소프트웨어를 잘 만드는 법

소프트웨어를 만든 다는 것#

필요한 것#

전공을 잘해야 소프트웨어를 잘 만든다?#

도미노 쌓기 : 도입#

도미노 쌓기 : 문제 제기#

도미노 쌓기 : 문제 해결#

정리 : 해결 내용#

변화#

소통#

신뢰#

존중#

020.A.가 오버라이딩, 오버로딩 그리고 가상함수

오버라이딩#

소스#

출력#

오버로딩#

소스#

출력#

가상함수#

소스#

출력#

020.A. C++

느낀점^#

아쉬운점^#

놀란 점^#

마무리 ^#

source.cpp^#

result^#

소프트웨어를 만든 다는 것^#

필요한 것^#

전공을 잘해야 소프트웨어를 잘 만든다?^#

도미노 쌓기 : 도입^#

도미노 쌓기 : 문제 제기^#

도미노 쌓기 : 문제 해결^#

정리 : 해결 내용^#

변화^#

소통^#

신뢰^#

존중^#

오버라이딩^#

소스^#

출력^#

오버로딩^#

소스^#

출력^#

가상함수^#

소스^#

출력^#