반환타입이 다르게 가상함수 재정의할 수 있는가?

코딩중 궁금하여 Test 해본 코드이다. 순수가상함수가 있다고 할때 이를 속상받는 클래스에서 순수가상함수를 재정의할때 반환타입을 다르게 할 수 있는가라는 스스로의 질문에 대한 정리이다.

기본적으로 Base가 되는 클래스 둘이 있는데 아래와 같다.

class ReturnType {
protected:
	int x;
public:
	ReturnType(int x) {
		this->x = x;
	}

	virtual int GetValue() {
		return x;
	}
};

class Base {
public:
	virtual ReturnType* Get(int a, int b) = 0;
};

클래스 Base는 Get이라는 순수가상함수를 가지고 있고 반환값으로 ReturnType을 갖는다. 여기서 따져보고 싶은 것은 Base의 Get이라는 순수가상함수의 반환 Type을 다르게 하여 선언할 수 있냐는 것이다. 대답은 “않된다”이지만 반환 Type도 OO의 다형성을 활용해서 다르게 선언할 수 있다는 것이다. 아래를 보자.

class ReturnType2 : public ReturnType {
public:
	ReturnType2(int x) : ReturnType(x) {
	}

	virtual int GetValue() {
		return x*x;
	}
};

class Derive1 : public Base {
public:
	virtual ReturnType2* Get(int a, int b) {
		ReturnType2* pRT = new ReturnType2(a+b);
		return pRT;
	}
};

class Derive2 : public Base {
public:
	virtual ReturnType* Get(int a, int b) {
		ReturnType* pRT = new ReturnType(a*2+b*2);
		return pRT;
	}
};

ReturnType으로부터 상속받은 ReturnType2 클래스가 있으며 Base로부터 상속받은 Derive1과 Derive2가 있다. 분명한것은 GetValue라는 순수가상함수의 반환타입이 상속받은 Base와 다르다는 점이다. 하지만 완전이 다른것은 아니고 반환타입이 상속관계를 갖는다. 이런 상속관계가 반환타입을 다르게 할 수 있는 이유가 되는 것이다.

내 코드는 걸레다, 개선을 위한 강한 자극이 필요하다.

문득.. 내 코드가 걸레로 보인다. 기분 탓일 수도 있겠지만.. 예전에 오픈소스로 공개한 코드를 살펴봤을때의 그런 일목요연하고 간결하며 체계적인 느낌이… 내가 작성한 코드에서는 느껴지지 않는다.

개발에 대한 체계적인 교육을 받지 못한 이유일까… 어쩌면 요즘 넘쳐대는 버그로 인해, 아직은 그 원인을 알지 못하는 이유로.. 코드가 전반적으로 꼬여있다라는 선입견 때문일까…

요즘에는 C++에 대한 감이 많이 상실된 느낌이다. 매일같이 사용하는 언어인데 말이다. 매일같이 바쁘게 사용하다보니, 늘 쓰는 것만 쓰게된다. 분명 어디선가 더 좋은 문법과 구문이 있다는 것을 알고 있음에도.. 비효율적이기는 하지만, 그냥 전에 썼던 방식대로 해 나간다. 그러다보니 전에 알고 있던 중요한 문법과 구문도 쓰지 않으니 기억속에서 희미하게 잊혀져간다.

정도(옳바른 길)을 걷지 못하고 있다는 느낌이다. 먼가 자극이 필요하다. 배움이 필요하다. 정도(옳바른 길)로 가는 깨닭음이 절실히 필요하다….

Software Design에 대한 짧은 생각과 팁

  • 파생 클래스 생성에 부담이 느껴진다면, 여전이 클래스 계층에 대한 추상화가 덜 되어 있다는 증거다.
2008년 1월 2일 오후 4시 29일

 

  • 속성 맴버 변수를 외부로 노출시키지 말고 get/set 함수를 두어 접근하도록 하는 것이, 클래스간의 독립성을 유지하는데 도움이 된다. get/set 함수를 만드는 수고로움에 대한 보상으로 말이다.
  • Class Diagram의 작성은 “인터페이스의 정의”로 시작된다.

12월 6일 오전 9시 56분

 

  • 데이터베이스에서 한번 정의된 스키마의 변경에 많은 소요비행이 발생한다면, 소프트웨어 개발에서는 클래스 관계도와 같은 UML 설계문서가 아닌 “전제조건”의 변경에 많은 소요비용이 발생한다. 여기서 말하는 전제조건이란, 어떤 기능을 실행하기 위해 준비되어야할 조건이다.

    11월 27일 오후 5시

     

  • 두렵다. 구현 단계에서 결국은, 비록 길지는 않은 시간이지만, 짧지만도 않은 시간 동안 설계한 내용을 폐기해야할지도 모른다는 생각에…. 그래서 분석 설계는 최대한 간결하게 하라고 했나보다. “어차피 내일은 변하다”니말이다. 하지만 최소한 설계 단계가 의미있는 이유는 실제 구현단계에서 마주치게 될 위험요소를 미리 파악할 수 있다는 큰 장점이 있다는 점이다. 그래서 인지… 설계를 하면 할 수록 두렵다….

10월 4일 오전 11시 36분

  • 영업인력이 고객에게 기술적으로  감동을 줄 수 있도록 개발인력은 소프트웨어를 설계하고 개발해야 한다.

9월 19일 14시 55분

 

  • 예를들어, Base라는 클래스로부터 상속받은 Derived라는 클래스가 있다고 할때, Base의 생성자의 인자가 (int a, int b, int c, int d)라고 하면, Derived 클래스의 생성자도 Base의 생성자를 실행하기 위해 인자로써 (int a, int b, int c, int d)를 최소한 가져야 하는데.. 만약 Base의 생성자의 인자가 하나 추가되면 Derived의 생성자의 인자도 동일하게 추가되어야한다. 하나의 변경으로 두개 이상의 변경이 발생하는 이 문제를 해결하기 위해 Derived의 생성자의 인자로 바로 Base를 받아 해결할 수 있다.
9월 19일 10시 12분

 

  • 서술식 글쓰기도 설계 방법 중의 하나.. UML과 글쓰기의 적절한 결합이 필요하다..
    9월 18일 12시 49분

     

  • 어디 쓸만한 꽁짜 UML 툴없나… 지금 쓰고 있는 StarUML은 결과는 그런대로 산뜻하긴 한데, UML 스펙을 지원하지 않는게 넘 많다. 지원하는 척… 하곤 결국 완벽이 지원하지 않는 그런 모습. 언제 쓸만한 공짜 UML 툴 찾아봐야겠다.

    9월 14일 12시 57분

     

 

  • 소프트웨어 설계라는 것이 유지보수와 소프트웨어의 생명주기를 길게 하는 효과는 있으나, 소프트웨어의 성능에 오히려 방해가 되는 것 같다는 생각이 든다.

    9월 13일 9시 54분

     

 

XGE 4차 릴리즈 – 스타일

약 2주전쯤에 나온 결과물입니다. 아직은 만족스럽지 않은 결과인지라 올리지 않았는데요. 이번주부터 새로운 기능을 하게 되서 일단 정리차원에서 올립니다. 원본 이미지는 훨씬 큽니다. 클릭해 원본 크기로 봐주시길 바랍니다.






분위기는 밝은 파스텔 톤입니다. 이미지 심벌과 문자 라벨을 좀더 적절하게 적용하면 훨씬 나은 결과가 나오리라 기대해 봅니다. GDI+만을 사용했는데요. 처음엔 속도 문제가 걸려 일단 GDI+ 이전의 그리기 API인 GDI를 지원했습니다. 옵션에 따라 GDI+로 그릴때와 GDI로 그릴때로 구분해 줄 수 있습니다. 하지만 지금은 속도 문제보다는 느낌이 훨씬 더 나은 GDI+만을 사용하도록 되어 있습니다. 예전부터 느낀 것이지만 GDI+는 괜찬은 그리기 API라는 생각입니다. 위의 화면에 나타나지 않았는데… XGE의 그리기 기능 중에 하나인 복합심벌이 있습니다. 예를 들어서 단순한 라인인데.. 이 라인이 철도를 의미한다면 아래처럼 그려줄 수 있습니다.

Bug Fix..!!

버그를 잡다가, IDE도 덩달아 죽는 모습을 보면서.. 평소에는 그냥 의식하지 않던 위의 오류보고창의 글귀를 읽어보았습니다. “품질을 향상시키는데 도움이 됩니다”. 소프트웨어의 품질에 대해 생각을 하게 만듭니다. 소프트웨어의 품질이란 무엇일까? 품질… 얼마나 안정적인가? 또 일정한 수행 속도 퍼포먼스를 제공하는가? 딱 떠오르는게 이 두가지 항목입니다…

사실 위의 창을 캡쳐하여 블로그에 올리는 이유는, 오늘 잡았는지, 잡았다고 착각을 하고 있는지 확실하지도 않은….. 버그 2개를 잡으면서였습니다. 전부터 잡아야겠다고 버르고 있던 버그였는데, 이 버그가 영향을 미치는 새로운 기능 몇가지를 추가하기에 앞서… 이 버그를 잡아야 했던 까닭였지요. 9시에 출근해서 지금까지 이 두마리의 버그에 씨름을 했는데, 사실 한마리는 그냥 쉽게 해결되었고 또 다른 한마리 때문에 고생을 했습니다. 이런 버그는 잡기가 어렵다… 걍 포기할까? 꽁수를 부려볼까? 하는 유혹이들 무렴에.. 고맙게도 IDE가 죽으면서 위의 창이 뜨더군요. 품질향상은 단박!에 되는것이 아니고… 릴리즈된 이후에도 지속적으로 사용자의 피드백을 받아 향상되어야 한다는 MS의 가르침이랄까요?

아무튼, 오늘은 기능추가 하나 없이… 달랑 버그 2마리 잡았습니다. 그것도 정말 잡았는지, 잡은 듯 보이는지.. 애매하긴 하지만 말입니다. 여튼, 결론은 “단박에 버그 잡기는 희망 사항일뿐이므로, 너무 오늘 하루에 목매지마라” 입니다. 음… 끝으로 너무 피곤합니다………