gentoo portageのSWTはx86_64で問題がある（org.eclipse.swt.gtk.OS.memmoveがないとおこられる）ようなので http://www.eclipse.org/downloads/ -> Other downloads -> SWT Binary and Source -> Linux (x86_64/GTK-2)をダウンロードして以下のようにインストール。

% su
% unzip swt-3.2-gtk-linux-x86_64.zip -d /usr/local/

compile and run a test program.

Test.java:

import org.eclipse.swt.widgets.*;

public class Test {
    public static void main(String[] args) {
        Display display = new Display();
        Shell shell = new Shell(display);
        shell.setText("Test Shell");
        shell.setSize(200, 200);
        shell.open();
        while (!shell.isDisposed()) {
            if (!display.readAndDispatch())
                display.sleep();
        }
        display.dispose();
    }
}

% export CLASSPATH=$CLASSPATH:/usr/local/swt-M20060629-1905-gtk-linux-x86_64/swt.jar
% export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/swt-M20060629-1905-gtk-linux-x86_64/
% javac Test.java
% java Test

You may also be happy to read following useful documents (notably org.eclipse.swt.widgets in official).

• http://help.eclipse.org/help31/nftopic/org.eclipse.platform.doc.isv/reference/api/overview-summary.html
• http://amateras.sourceforge.jp/cgi-bin/fswiki/wiki.cgi/swt?page=FrontPage

Nihongo unatenakunatta. Koredakara GUI application ha iya nanda.

foo.h:

class foo { ... };

bar.h:

class bar { ... };

があるとして

hoge.h:

#include "foo.h"
#include "bar.h"

class hoge {
private:
    foo f;
    bar b;
public:
    hoge();
    foo& get_foo();
    bar& get_bar();
};

hoge.cpp:

#include "hoge.h"

hoge::hoge() {}
foo& hoge::get_foo() { return f; }
bar& hoge::get_bar() { return b; }

と書くより

hoge.h:

#include <memory>

class foo;
class bar;

class hoge {
private:
    struct impl;
    std::auto_ptr<impl> pimpl_;
public:
    foo& get_foo();
    bar& get_bar();
};

hoge.cpp:

#include "foo.h"
#include "bar.h"
#include "hoge.h"

struct hoge::impl {
    foo f;
    bar b;
};

hoge::hoge() : pimpl_(new impl) {}
foo& hoge::get_foo() { return pimpl_->f; }
bar& hoge::get_bar() { return pimpl_->b; }

と書くほうがすばらしいよという話。前者の場合はhoge.hをincludeした時点でfoo.hとbar.hまでincludeされてしまって、おまけにfoo.hやbar.hに変更が加えられてしまった場合にhoge.hはもちろんのことそれをincludeしているヘッダファイルまで変更が波及してしまうことになり、結果としてコンパイルが遅くなる。一方後者の場合はhoge.hの他への依存性はほぼゼロである。前方宣言を使うのは当然のことであるが、ここではそれ以上にpimplイディオムが大活躍している。つまりimplのポインタにfooやbarを格納してしまうことにより、それらのサイズや定義を知る必要がないのだ。ゆえにいくらhoge.hをincludeしているヘッダファイルがあろうともfoo.hやbar.hの変更はそれらに波及しえない。これによって変更に対する耐性が保証され、結果としてコンパイルが速くなる。

しかしpimplイディオムのメリットはそれだけではない。いやpimplの本質上、メリットがコンパイルの高速化だけでとどまること自体がそもそもおかしい。挙げだすと切りがないのだが(要するにstackにおくこととheapにおくこととの差によるメリット)、個人的に非常に興味深いのは例外安全に対する驚くべき能力である。たとえばfoo.hが以下のようなアホなコードだったとしよう。

foo.h:

class foo {
public:
...
foo& operator =(const foo& rhs) {
    throw not_implemented_error(); // how stupid I am!
}
... 
};

このアホクラスを使ってテストコードを書く。

hoge a;
hoge b;
a = b;

このコードをpimplイディオムでないバージョンのhogeでコンパイルすると a = b の部分で例外が発生する。依存したクラスのおかげで自分のクラスまで非例外安全になるなんてなんてすばらしいのでしょう。しかしpimplイディオムの黒魔術にかかればそんな問題も一発。hoge.hとhoge.cppを以下のように改造する。

hoge.h:

#include <memory>

class foo;
class bar;

class hoge {
private:
    struct impl;
    std::auto_ptr<impl> pimpl_;
public:
    foo& get_foo();
    bar& get_bar();
    hoge& operator =(const hoge& rhs); // never throw
};

hoge.cpp:

#include "foo.h"
#include "bar.h"
#include "hoge.h"

struct hoge::impl {
    foo f;
    bar b;
};

hoge::hoge() : pimpl_(new impl) {}
foo& hoge::get_foo() { return pimpl_->f; }
bar& hoge::get_bar() { return pimpl_->b; }
hoge& hoge::operator =(const hoge& rhs) {
    if (this != &rhs) {
        pimpl_ = rhs.pimpl_;
    }
    return *this;
}

これで何回 hoge::operator = しようが決して例外が発生することはない。すばらしすぎる。

その他にも new impl_ するタイミングを調整できたり、 struct impl と本来のクラスに実装をわけて構成をわかりやすくしたり、(時と場合によるが)本体のコピーやswapが断然速いなど、pimplにはたくさんのすばらしいメリットがある。ただもちろんそんなにおいしいことばかりでもなく、heapを使う分のパフォーマンス低下は当然考えられる問題だ。しかしメリットとデメリットを計算したとき、最終的にはやはり符号は+になることだろう。

練習がてら解いてみる。かなり適当。

from math import ceil

class IMGroups:
  def optimalTime(self, N):
    res = 1000000
    for i in range(1, N):
      tmp = int(i + ceil(float(N) / i))
      if tmp < res:
        res = tmp
    return res

#include <iostream>
#include <vector>
#include <string>

#define MOD 10000

using namespace std;

int n;
int memo[18][1 << 15];
vector<string> b;

int go(int k, int d1, int mask) {
    int& res = memo[d1][mask];
    if (res != -1) return res;

    if (k == 0) return res = 1;
    if (d1 >= 2 * n - 1) return res = 0;

    res = go(k, d1 + 1, mask) % MOD;
    for (int i = 0; i < n; i++) {
        int j = d1 - i;
        int d2 = n - 1 + i - j;

        if (i < 0 || i >= n || j < 0 || j >= n) continue;

        if (!(mask & (1 << d2)) && b[i][j] == '.') {
            res += go(k - 1, d1 + 1, mask ^ (1 << d2));
            res %= MOD;
        }
    }

    return res;
}
 
class Bishops {
public:
    int count(int k, vector<string> board) {
        n = (int)board.size();
         b = board;
        if (k > 2 * n - 1) return 0;
        memset(memo, -1, sizeof(memo));
        return go(k, 0, 0);
    }
};

#if 0

int main() {
    vector<string> board;
    board.push_back("........");
    board.push_back("......#.");
    board.push_back("........");
    board.push_back(".#......");
    board.push_back("........");
    board.push_back(".....#..");
    board.push_back("........");
     board.push_back("...#....");

    Bishops bishops;
    cout << bishops.count(7, board) << endl;

    return 0;
}

#endif

class DeckShuffler:
  def getDeck(self, n, shuffled):
    res = range(1, len(shuffled) + 1)
    while n > 0:
      tmp = res[:]
      for i, x in enumerate(shuffled):
        tmp[i] = res[x - 1]
      res = tmp
      n -= 1
    return res

AAB
AAB
BBB

class SquareCounting:
  def howMany(self, grid):
    w = len(grid[0])
    h = len(grid)
    sq = {}
    res = 0
    def row(c, l, t, r):
      while l < r:
        if grid[t][l] != c:
          return False
        l += 1
      return True
    def include(c, l, t, r, b):
      for s in sq.get(c, []):
        if s[0] <= l and s[1] <= t and s[2] >= r and s[3] >= b:
          return True
      return False
    for l in range(w):
      for t in range(h):
        c = grid[t][l]
        r = l + 1
        while r < w and grid[t][r] == c:
          r += 1
        b = t + 1
        while b < h and row(c, l, b, r):
          b += 1
        r = l + min(r - l, b - t)
        b = t + min(b - t, r - l)
        if not include(c, l, t, r, b):
          sq.setdefault(c, []).append([l, t, r, b])
          res += 1
    return res

class ConvexityIssues:
  def howMany(self, values):
    res = 0
    n = len(values)
    for i in range(n - 2):
      for j in range(i + 2, n):
        a1 = float(values[j] - values[i]) / (j - i)
        for k in range(i + 1, j):
          a2 = float(values[k] - values[i]) / (k - i)
          if a1 < a2:
            res += 1
    return res

ふとしたことから以下のような不思議な現象を発見してしまいました。

test.cpp:

#define N (64*500)
            
class wrap {
    int data[N];
public:     
    wrap() {
        int i;                      
        for (i = N - 1; i >= 0; i--)
            data[N - i + 1] = i;
    }
                 
    void doit() {
        int i, j, tmp;               
        for (i = 0; i < N - 1; i++) {    
            for (j = i + 1; j < N; j++) {
                if (data[i] > data[j]) {
                    tmp = data[i];
                    data[i] = data[j];
                    data[j] = tmp;
                }
            }
        }
    }
};
            
int main() {
    wrap a;  
    a.doit();
}

test.c:

#define N (64*500)
            
int data[N];

void init() {
    int i;
    for (i = N - 1; i >= 0; i--)    
        data[N - i + 1] = i;
}

void doit() {
    int i, j, tmp;
    for (i = 0; i < N - 1; i++) {    
        for (j = i + 1; j < N; j++) {    
            if (data[i] > data[j]) {
                tmp = data[i];
                data[i] = data[j];
                data[j] = tmp;
            }
        }
    }
}

int main() {
    init(); 
    doit();
}

% g++ test.cpp -o test.cpp.out
% time ./test.cpp.out
./test.cpp.out  5.01s user 0.00s system 94% cpu 5.311 total
% gcc test.c -o test.c.out
% time ./test.c.out
./test.c.out  3.84s user 0.00s system 95% cpu 4.048 total

classのオーバーヘッドがあるんでこれは当然なんですが、

% g++ -O3 test.cpp -o test.cpp.out
% time ./test.cpp.out
./test.cpp.out  1.14s user 0.00s system 92% cpu 1.233 total
% gcc -O3 test.c -o test.c.out
% time ./test.c.out
./test.c.out  1.32s user 0.00s system 93% cpu 1.412 total

奇妙ですね。

% g++ -O3 -c test.cpp -o test.cpp.o
% objdump -t test.cpp.o
SYMBOL TABLE:
00000000 l    df *ABS*  00000000 test.cpp
00000000 l    d  .text  00000000 .text
00000000 l    d  .data  00000000 .data
00000000 l    d  .bss   00000000 .bss
00000000 l    d  .note.GNU-stack        00000000 .note.GNU-stack
00000000 l    d  .comment       00000000 .comment
00000000 g     F .text  00000067 main
% gcc -O3 -c test.c -o test.c.o
% objdump -t test.c.o
00000000 l    df *ABS*  00000000 test.c
00000000 l    d  .text  00000000 .text
00000000 l    d  .data  00000000 .data
00000000 l    d  .bss   00000000 .bss
00000000 l    d  .note.GNU-stack        00000000 .note.GNU-stack
00000000 l    d  .comment       00000000 .comment
00000000 g     F .text  00000020 init
0001f400       O *COM*  00000020 data
00000020 g     F .text  0000004e doit
00000070 g     F .text  0000006e main

initとdoitがinlineになってないじゃん。それぞれ一回しか呼ばれていないので全然関係ないのですが、一応inline化しましょう。gccマニュアルによるとスタンドアロンなオブジェクトのインライン展開にはstatic inlineを使わないとだめだよとのことなので以下のように修正します。

test.c:

#define N (64*500)

int data[N];

static inline void init() {
    int i;
    for (i = N - 1; i >= 0; i--)
        data[N - i + 1] = i;
}

static inline void doit() {
    int i, j, tmp;
    for (i = 0; i < N - 1; i++) {
        for (j = i + 1; j < N; j++) {
            if (data[i] > data[j]) {
                tmp = data[i];
                data[i] = data[j];
                data[j] = tmp;
            }
        }
    }
}

int main() {
    init();
    doit();
}

% gcc -O3 -c test.c -o test.c.o
% objdump -t test.c.o
SYMBOL TABLE:
00000000 l    df *ABS*  00000000 test.c
00000000 l    d  .text  00000000 .text
00000000 l    d  .data  00000000 .data
00000000 l    d  .bss   00000000 .bss
00000000 l    d  .note.GNU-stack        00000000 .note.GNU-stack
00000000 l    d  .comment       00000000 .comment
00000000 g     F .text  0000006e main
0001f400       O *COM*  00000020 data

おし消えました（一応asmでも確認）。

% gcc -O3 test.c -o test.c.out
% time ./test.c.out
./test.c.out  1.33s user 0.00s system 94% cpu 1.411 total

まあ当然の結果です。以下にtest.cpp.outとtest.c.outのdesasmされた.textをのせます（gccの-Sでもいいのですが読みにくいので）。

odjdump -d test.cpp.o:

00000000 <main>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   57                      push   %edi
   4:   56                      push   %esi
   5:   53                      push   %ebx
   6:   81 ec 0c f4 01 00       sub    $0x1f40c,%esp
   c:   83 e4 f0                and    $0xfffffff0,%esp
   f:   83 ec 10                sub    $0x10,%esp
  12:   8d b5 e8 0b fe ff       lea    0xfffe0be8(%ebp),%esi
  18:   b8 ff 7c 00 00          mov    $0x7cff,%eax
  1d:   8d 95 f0 0b fe ff       lea    0xfffe0bf0(%ebp),%edx
  23:   90                      nop    
  24:   89 02                   mov    %eax,(%edx)
  26:   83 c2 04                add    $0x4,%edx
  29:   48                      dec    %eax
  2a:   79 f8                   jns    24 <main+0x24>
  2c:   31 db                   xor    %ebx,%ebx
  2e:   8d 7b 01                lea    0x1(%ebx),%edi
  31:   89 f8                   mov    %edi,%eax
  33:   81 ff ff 7c 00 00       cmp    $0x7cff,%edi
  39:   eb 16                   jmp    51 <main+0x51>
  3b:   8b 0c 9e                mov    (%esi,%ebx,4),%ecx
  3e:   8b 14 86                mov    (%esi,%eax,4),%edx
  41:   39 d1                   cmp    %edx,%ecx
  43:   7e 06                   jle    4b <main+0x4b>
  45:   89 14 9e                mov    %edx,(%esi,%ebx,4)
  48:   89 0c 86                mov    %ecx,(%esi,%eax,4)
  4b:   40                      inc    %eax
  4c:   3d ff 7c 00 00          cmp    $0x7cff,%eax
  51:   7e e8                   jle    3b <main+0x3b>
  53:   81 ff fe 7c 00 00       cmp    $0x7cfe,%edi
  59:   89 fb                   mov    %edi,%ebx
  5b:   7e d1                   jle    2e <main+0x2e>
  5d:   8d 65 f4                lea    0xfffffff4(%ebp),%esp
  60:   5b                      pop    %ebx
  61:   5e                      pop    %esi
  62:   31 c0                   xor    %eax,%eax
  64:   5f                      pop    %edi
  65:   c9                      leave  
  66:   c3                      ret    

objdump -d test.c.o:

00000000 <main>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   56                      push   %esi
   4:   53                      push   %ebx
   5:   83 e4 f0                and    $0xfffffff0,%esp
   8:   83 ec 10                sub    $0x10,%esp
   b:   ba ff 7c 00 00          mov    $0x7cff,%edx
  10:   b9 01 7d 00 00          mov    $0x7d01,%ecx
  15:   8d 76 00                lea    0x0(%esi),%esi
  18:   89 c8                   mov    %ecx,%eax
  1a:   29 d0                   sub    %edx,%eax
  1c:   89 14 85 00 00 00 00    mov    %edx,0x0(,%eax,4)
  23:   4a                      dec    %edx
  24:   79 f2                   jns    18 <main+0x18>
  26:   31 db                   xor    %ebx,%ebx
  28:   8d 73 01                lea    0x1(%ebx),%esi
  2b:   89 f0                   mov    %esi,%eax
  2d:   81 fe ff 7c 00 00       cmp    $0x7cff,%esi
  33:   eb 26                   jmp    5b <main+0x5b>
  35:   8b 0c 9d 00 00 00 00    mov    0x0(,%ebx,4),%ecx
  3c:   8b 14 85 00 00 00 00    mov    0x0(,%eax,4),%edx
  43:   39 d1                   cmp    %edx,%ecx
  45:   7e 0e                   jle    55 <main+0x55>
  47:   89 14 9d 00 00 00 00    mov    %edx,0x0(,%ebx,4)
  4e:   89 0c 85 00 00 00 00    mov    %ecx,0x0(,%eax,4)
  55:   40                      inc    %eax
  56:   3d ff 7c 00 00          cmp    $0x7cff,%eax
  5b:   7e d8                   jle    35 <main+0x35>
  5d:   81 fe fe 7c 00 00       cmp    $0x7cfe,%esi
  63:   89 f3                   mov    %esi,%ebx
  65:   7e c1                   jle    28 <main+0x28>
  67:   8d 65 f8                lea    0xfffffff8(%ebp),%esp
  6a:   5b                      pop    %ebx
  6b:   5e                      pop    %esi
  6c:   c9                      leave  
  6d:   c3                      ret

test.c.oのほうはリンク時にdataのアドレスが0x0にrelocateされるんですが、それを除けば全く同じです。となればネックになっているのはdataのfetchだと考えるのが普通なんですが、ssもdsも速度的には同等であるはずですし、置かれるデータ構造が同じうえ、キャッシュはlinear addressでされるらしいので、どこで遅くなるのか見当もつきません。実効アドレッシングで差がついてるのか、あるいはちゃんとアドレッシングの原理を理解していないのか、COMMONなオブジェクトはなんらかの理由があって遅いのか、はたまた、等々。いまだ未解決。

以下の資料を読みあさっています。

http://www.intel.co.jp/jp/developer/download/index.htm#ia32

わかりしだい追記したいと思います。誰かわかる人いたら教えてください。この辺の知識はかなり疎くてしょうがないですもう。

追記。ValgrindにCachegrindというCPUのキャッシュ機構をシミュレーションしてキャッシュミス数等をプロファイルする機能があることを知ったので試してみました。なお（ちゃんと調べてないですが）、このマシンのL1 Data Cache Sizeは16KBらしいのでtest.cpp、test.cのdataのサイズをそれにあわせました。

% valgrind --tool=cachegrind ./test.cpp.out
==17087== I   refs:      1,209,567,234
==17087== I1  misses:            1,021
==17087== L2i misses:              584
==17087== I1  miss rate:          0.00%
==17087== L2i miss rate:          0.00%
==17087==                      
==17087== D   refs:        537,402,348  (268,898,767 rd + 268,503,581 wr)
==17087== D1  misses:        7,818,505  (  7,817,144 rd +       1,361 wr)
==17087== L2d misses:            6,058  (      4,759 rd +       1,299 wr)
==17087== D1  miss rate:           1.4% (        2.9%   +         0.0%  )
==17087== L2d miss rate:           0.0% (        0.0%   +         0.0%  )
==17087==                      
==17087== L2 refs:           7,819,526  (  7,818,165 rd +       1,361 wr)
==17087== L2 misses:             6,642  (      5,343 rd +       1,299 wr)
==17087== L2 miss rate:            0.0% (        0.0%   +         0.0%  )
% valgrind --tool=cachegrind ./test.c.out
==17094== I   refs:      1,208,158,555
==17094== I1  misses:              934
==17094== L2i misses:              524
==17094== I1  miss rate:          0.00%
==17094== L2i miss rate:          0.00%
==17094==
==17094== D   refs:        536,850,915  (268,466,100 rd + 268,384,815 wr)
==17094== D1  misses:        7,806,491  (  7,805,248 rd +       1,243 wr)
==17094== L2d misses:            2,210  (        997 rd +       1,213 wr)
==17094== D1  miss rate:           1.4% (        2.9%   +         0.0%  )
==17094== L2d miss rate:           0.0% (        0.0%   +         0.0%  )
==17094==
==17094== L2 refs:           7,807,425  (  7,806,182 rd +       1,243 wr)
==17094== L2 misses:             2,734  (      1,521 rd +       1,213 wr)
==17094== L2 miss rate:            0.0% (        0.0%   +         0.0%  )

この結果を見たかぎりではC版のほうが当然速くなるはずなのですが...どうやらキャッシュミスとかアラインメントの問題でもないようです（cachegrindを信用して）。再調査します。

GUIプログラミングは非常に退屈で冗長でつまらない作業だ。しかしそれぐらいならまだいい。今日のGUIライブラリは一種キチガイじみた設計になっている。これがすばらしきOOPの産物なのかとまことに崇拝したい気分である。なるほど僕にはOOPを自由に操る能力が欠けているのかもしれない、あるいは業務には必要な一種の妥協性というのが足りないのかもしれない、しかしどちらにしても時間をかければ解決できると思っていた。つまりは、OOP的にカプセル化されたコンポーネントをある複雑構造で保持し、それの更新あるいは発信をリスナを使って他のカプセル化されたコンポーネントへ反映させることが、OOPに基づいた設計ならば簡単である、あるいは仮に簡単でないにしろ時間をかければ可能であると。しかしそれは幻想にすぎなかったのだ。もう一度言うがこれは僕の能力の欠如なのかもしれないし、もしそうならばむしろうれしいぐらいなのである。なるほどそれらはOOPに基づいてカプセル化されている、それはまことに圧巻するほどに。しかし見てみよ、実際使うにはカプセルを完全なまでに分解せねばならぬではないか。これではカプセル化の恩恵を受けるどこか、ただのガラクタと化したカプセルの外殻が内部へのアクセスをただ妨げるだけで、むしろその矛盾性に設計者は苦しむのである。さて以下のような場合を考えてみよう。コンポーネントAとコンポーネントBは互いに関与すべき機能性を保持しているのだが、それはOOPによればコンポーネント化によって分離されるべきものである。つまりは第三者であるコンポーネントCのようなものを持ってきてコンポーネントAとコンポーネントBの仲介者にしなければならない。さてここでコンポーネントBがコンポーネントAの更新情報を逐次受け取れるようにリスナを設定したいとする。コンポーネントAとコンポーネントBは分離させるべきものなので、仲介者であるコンポーネントCがその仕事を請け負うのだが、さてあなたが注意深い設計者ならばコンポーネントCにその仕事を委託することにおそらくためらうだろう。なぜならそこに本来OOPによって取り除かれるべき依存性が、以前より複雑さをまして存在しているからである。仲介者であるコンポーネントCは依存方向に加えて依存範囲や依存方法などさまざまな情報を持たなければならない。そしてあなたはそれが依存に依存していることに気づかれるだろう。かくしてすばらしきOOPの概念は依存を増やすにまで達した。ここで僕が言いたいのはOOPを真っ当から否定することではない。むしろ閉鎖的にカプセル化されたコンポーネントによる関係性がOOPの概念に矛盾するということが言いたいのだ。それはとくにGUI（のリスナ）プログラミングにおける設計に顕著に現れる。Treeのあるアイテムをダブルクリックしたらあるボタンがフォーカスされる、さてこのような処理をOOPの概念に矛盾することなく実装するにはどのようにしたらよいのか。なるほどMediatorパターンを使って関係を隠蔽し統括するのか。おそらくTreeItemとButtonがフラット構造に配置されているのならOOPは饒舌になるだろう。しかし実際問題、そのようなケースはまれで、大抵の場合は皮肉なことにかかる構造はOOPに基づき複雑にカプセル化されている。どのカプセルも口をあけたがらない。口をあけさせるためにカプセルに特殊な処置をほどこしてMediatorだけを特別に通れるようにする。そしてMediatorはそのわずかに開いた口の隙間を息苦しそうに通り抜けていくのである。あまりに馬鹿げてやしないだろうか。一体他への関与をも閉ざしてしまうカプセル（プライベートなリスナセットを持っている）の用途はどこにあるのだろうか。もちろんOOPは暗黙的に（あるいは明確に述べているかもしれない）依存は決して悪くはないと述べている。それはカプセルがアトム的でないことが許される点からも容易に解せられる。しかし同時にGoFなるものがカプセル化の優位性をこれでもかと語っている。またライブラリ設計者はきまってカプセル化を美学的にとらえてこよなく愛す。一方利用者は美しきカプセル化が織り成す戦慄すべき醜悪さと矛盾性に苦しむのである。なるほどOOPはプログラミングを容易にし簡潔にし明快にする。このことは誰も否定はできない。また以下のことは将来において願わくは現在においても肯定されるべきである。つまり閉鎖的なカプセルというのは何もなしえないということ、そしてむしろその閉鎖性がゆえに開口性に複雑に依存するということである。