[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

C++ doesn't support the 'interface' explicitly unlike Java. So, combination of abstract class and virtual function, is used.

Let's think of following case.

ModuleA
  A : pure abstract class (interface class).
  AImpl : implementation(concrete) class inherited from A.

External module that want to use ModuleA need to know interface, but don't need to know it's implementation. So, Knowing class A should be enough to use ModuleA. And this is tightly coupled with the way of instantiation.
Let's see below

A* instance = new AImpl(argument);

This is easy way. But, in this case, definition of 'AImpl' should be included in external code. This is not good in terms of 'Information Hiding'. We want to hide implementation details (even if it's header). See following example to do this.

----- A.h
class A // interface class
{
public:
    virtual ~A(){};
    static A* Create_instance(Arguments);
    int Interface_function_A(void) = 0;
    int Interface_function_B(void) = 0;
};

---- AImpl.h
#include "A.h"
class AImpl : private A
{
    friend class A;
    ...
}
...

---- A.cpp
#include "AImpl.h"
A::Create_instance(Arguments)
{
    AImpl* instance = new AImpl(Arguments);
    return static_cast(instance);
}

Now, knowing definition of class A is enough to use this module. Therefore, implementation details are completely hidden. Besides, inheriting as 'private', can prevent module from unexpected usage (AImpl can be used only through A). Here is sample usage.

#include "A.h"
...
A* instance = A::Create_instance(Arguments);
...
delete instance;

We made function for create instance. But, we should make destroying instance be possible by 'delete' keyword. Because, in many cases, knowing instance's concrete class at the moment of deleting it, is not necessary. And unifying interfaces to destroy instance (into using 'delete') is also good to read.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

In general, there is a table to help estimate schedule and this table usually categorize software according to software type(system product, business product and so on) and size(line of code - 10,000/20,000/.../500,000/... ). It is definitely very useful.
Now it's time to make table for me, my team and our company for more accurate estimation!! (We can use more customized categorization.)

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

아래는 모두 개인적인 의견임을 밝힌다.

전제 : 어떤 결정을 하기 전에, 최선의 결정이 무엇인지 아는 것은 불가능하다.

가능하다면, 의사결정을 민주적으로 하는 것이 좋다는데는 이견이 없다. 그런데, 회사에서는 '민주적'이라는 단어가 존재할 수 없다. 조직 자체가, 서열화 되어 있고, 의사결정권한은 한 사람에게 집중되어 있다. 따라서, 회사에서 말하는 '민주적'이란, 의사 결정권자가, 다른 사람들의 의견을 수렴해서, 최대한 여러사람이 공감할 수 있는 결정을 내리는 것을 말하리라.

그러나, 다음의 경우를 생각해 보자.

A와 B 라는 두가지 선택을 할 수 있는데, 의사결정권자의 마음이 이미 A로 기운 상황을 생각해보자. 이 의사 결정권자는 민주적인 결정을 하고 싶어한다 (누가나 그렇다.) 그래서 사람들을 불러 모아 놓고, 의견을 듣는다. 그런데 사람들은 B를 주장한다. 그렇지만 의사 결정권자의 마음은 바뀌지 않는다. 그래서 사람들을 설득하고자 한다. 동의를 얻어내기 위함이다. 그러나 설득이 되지 않는다. 따라서, 다시 사람들에게 시간을 준다. "A와 B 진정으로 어느 쪽이 옳은지 다시 한 번 생각해 보고, 다시 회의 하자." 그리고 다음 회의에서도 이전 회의와 똑같은 현상이 되풀이 된다. ("1+1=2" 와 같이 논리적인 답이 있는 것이 아니라면, 사람들은 자신의 뜻을 쉽게 바꾸지 않는다.)

위의 상황에서도 계속해서 소위 말하는 '민주적'인 의사결정을 고집해야 하는가? 물론, A와 B가 어떤 문제에 대한 의사 결정인지에 따라 다르겠지만, 만약, 이 결정이 부서 업무의 방향을 결정짓는 것이라면, 사람들은 이 결정이 내려지기 전까지는 아무일도 할 수 없고 시간만 보내는 상황이 될 것이다. 만약 이 문제가 시간을 다투는 것이라면, 차라리 어느 쪽이든 빨리 결정해서 밀고 나가는 것이 더 나을 수 있다. 이런 때는 의사 결정권자가 자신의 뜻을 독단적으로 관철시키는 것이 오히려 더 낫다고 생각한다.

+ Recent posts