[Java] Visibility에서 추가했으면 하는 것….

Java visibility는 private, protected, default(package private), public 이렇게 4단계가 있다.
그런데 개인적으로 한단계 정도 더 있었으면 한다.

기능별로 block을 형성하도록 programming할 수 있어야 한다. 그게 oop의 기본이기도 하다.
하나의 class가 하나의 block을 형성할 수 있으면 좋겠지만, 보통 여러개의 class가 하나의 기능 block을 형성한다.
그리고, 이 기능 block의 내부 interface는 package private으로 하고, 외부 interface는 public으로 둔다.
이게 Java에서의 일반적인 programming방법이다.
그런데, 어떤 기능 block 자체가 더 큰 기능 block의 한 부분이게 하고 싶은 경우는 어떻게 해야 하는가?
물론, 재 사용성을 위해서 모든 기능 블럭은 자체적으로 완벽하게 동작하도록 디자인하고, 관련 interface는 public으로 해 둘 수 있게 하는것이 이상적이긴 하다.
그렇지만, 대부분의 경우, 큰 기능 블럭의 한 부분임을 가정하고 programming하는 경우가 많다.
왜냐하면, 일반적인 기능블럭(public interface를 가지는…)을 만들어 내기 위해서는 추가적인 많은 노력들이 필요하기 때문이다.
그런데, Java의 visibility는 이런 경우를 해결해 줄 수 없다.
(하나의 package로 구성된 기능 block의 interface는 public이여야만 한다.)
그래서 개인적으로 추가적인 안을 제시해 본다.

*** tree-based name space ***

name space가 tree형태를 가진다. java convention을 이용해 설명하면, ‘.’을 separator로 하고, 각 name이 tree의 path를 의미하도록 하는 것이다.
예를 들면, ‘com.java.io’라면, ‘java’는 ‘com’의 child 이고, ‘io’는 ‘java’의 child가 된다.

***  parent private ***

visibility가 자신의 parent에게만 되도록…

음.. visibility가 자꾸 많아지는 것도 안 좋긴 한데… 일단 이런게 있었으면 좋겠다… 단점도 있을 것 같은데.. 좀더 고민해 보자…

[C/C++] Encapsulation tip in C.

Usually, pointer of not-opened-structure is used to hide module’s information.
C dummies may use ‘void*’ to do this. But, it’s not good way.
Let’s see following example.
(Following codes are test in GCC4.4 with ‘-Wall’ option.

typedef void module_t;             /* <-- *1 */
typedef struct _sModule module_t;  /* <-- *2 */

module_t* create_module(int arg);
int       do_something(module_t* m, int arg);
...
do_something((int*)m, 1); /* <-- *a */

Pointer of any type can be casted to ‘void*’, and ‘void*’ can be casted to pointer of any type without warning.
So, in case of (*1), (*a) doesn’t generate any warning. That is, it is NOT TYPE SAFE (in compile time).
But, in case of (*2), GCC give warning like “… incompatible pointer type …”. It’s TYPE SAFE.
And, interestingly, compiler doesn’t complain anything about (*2) because, compiler doesn’t need to know size of ‘struct _sModule’.
Only pointer is used. So, knowing size of pointer type is enough and compiler already know it.
So, in terms of syntax, it’s ok too!

[Prog] Object Oriented Programming

The most important thing of OOP is “Making objects that developer don’t need to look inside of it.”. Reliable objects are foundation of OOP. Then let’s think about this more.

* Object should respond at all cases.

That is, crashing inside object should not be happened! object should be in valid state at any case. If software is crashed inside object, developer should analyze internal code of object, and this is what we want to avoid.

* Reducing possibility of misuse interface should be considered when interface is design.

That is, usage of interfaces should be easy and intuitive. If not, developer need to investigate for object’s internal parts to know correct usage. And, usually, interdependent interfaces leads to misuse. For example, “Interface B should be used after interface A is called”, “Interface A should not be called after interface B is called” and so on. So, if possible, reduce dependency among interfaces of objects.

* Interface should be well-commented.

In the same context with above, developer don’t need to look into the object that is well-commented. In my opinion, comments of interface should include at least following things.
  + behavior of interface.
  + prerequisite to use the interface.
  + explanation about each parameters.
  + description about return value.
And, adding usage example is recommended.

* For object to starts supporting minimal set of interface is better.

Adding interface is easy. But deleting interface is difficult because it may affect to number of other objects that already use the interface. And, stabilizing object having small number of interface, is easier. Starting from minimal set can also help developer escape from temptation of over-engineering

 
Next important point is relations among objects.
Software created by OOP consists of lots of objects and relations. To understand software’s behavior, knowing relations and inter-operations among objects is significant.

* Software documentation.

Design concept, policy, block diagram, used patterns and so on is needed to be documented to help reader to understand overall shape of software.

 
There is also disadvantage of OOP.

* Performance drop.

In every object, there are lots of routines for checking and handling unexpected cases. And in general, software in OOP consists of lots of objects. So, inevitably, number of duplicated check and handling are unavoidable – all objects may check same thing. And sometimes this drops performance very much.