ObjectOriented

わんくま東京勉強会#56 懇親会ふぉろー

επιστημη — Sun, 20 Feb 2011 00:32:00 GMT

懇親会の席上でおもろいネタで盛り上がってました:

　「コンストラクタが例外を投げるのはアリか?」

僕は「ないわー」派についていたのですが、帰りの電車に揺られて酔いを醒ましてるうちに「アリかも」と思い始めてました。# かなはるちゃんいぢめてごめんよー

そもそも例外処理てぇのは
「エラーを検出できるが対処できない」呼ばれ側と
「エラーに対処できるが検出できない」呼び側
との間でエラーをやり取りするためのからくり、なハズです。

するってーと例外ちゅーのは
"あり得ないこと"が起こった事を知らせるっちゅーより、
"対処不能なこと"が起こった事を知らせるもんだろ、と。

であるなら、コンストラクタ内で"対処不能なこと"が起こったのならその旨を呼び側に伝えるべく例外投げるのはアリかと思うですね。

※ かたやデストラクタで例外投げるのはどんなもんよ。
デストラクタは往々にして暗黙のうちに呼ばれるし、.NETだといつ呼ばれるかはおろか確実に呼ばれるかすら定かじゃない。んなもんcatchできひんやん。

わんくま東京勉強会#56 LTふぉろー

επιστημη — Sun, 20 Feb 2011 00:29:00 GMT

昨年夏の横浜勉強会以来とーんとご無沙汰してたわんくま勉強会、おさしみぶりに顔出しました。日本マイクロソフト＠品川新社屋に潜入したかったし。

…えー、中さんゴメンナサイ。Kinect Game DVDを一枚おシャカにしてまいました。この埋め合わせは必ずや。どうかご寛恕いただきますよう平身低頭 _o/L

今回はえムナウ御大プロデュースでWPF/Silverlightスペシャル。native屋の僕が付け入るスキなどあろうはずもなく、LTで茶を濁すことに。

LTやらせろと手ぇ挙げてはみたものの、肝心のネタを決めかね、あろうことか触り始めてわずか二時間のPythonでくっちゃべったわけですが案の定しゃべり足りんうちにTime Overコいてまいました。ちーと悔しいのでここでふぉろー。

Pythonは多重継承を許します:

class Base1:
def fun(self):
print('Base1.fun()')

class Base2:
def fun(self):
print('Base2.fun()')

class Derived(Base1,Base2):
pass # なにもしない

とか書けばDerivedはBase1とBase2から導出されます。ここで:

d = Derived() # インスタンスをこしらえて
d.fun() # fun()を呼ぶ

とかやるとd.fun()はBase1.fun()とBase2.fun()のどっちが呼ばれるでしょか。
C++でこんなの書いたらどっちのfun()を呼ぶか決めかねてコンパイルエラーです。
かたやPythonでは動いてしまいます。

d.fun()されたとき、Derivedそれ自身はfun()を持たないので、基底クラスに遡って探しにいきます。メソッドを解決する順序:MRO(Method Resolution Order)はクラス定義時にカッコ内にに並べた順となります。

class Derived(Base1,Base2):

と定義したのでMROは:

Derived
Base1
Base2

の順となり、d.fun()はBase1.fun()が呼ばれることになるです。

MROの裏をかいてみましょうか。

class Base1:
class Base2:
class Derived1(Base1,Base2): # [1]
class Derived2(Base2,Base1): # [2]
class MoreDerived(Derived1,Derived2):

こんなコード書くとMoreDerivedのMROを決定する際に([1]と[2]においてBase1とBase2の順序が異なるために)Base1とBase2のどっちを先にするか決めかねてエラーになるですよ。

よーするにPythonの多重継承は単一継承に置き換えることで実現する"なんちゃって多重継承"と考えられます。だとすれば単一継承しか許さない.NETで実装したPython処理系:IronPythonが作れるのも頷けますです。

エンジンがかからない...

επιστημη — Fri, 06 Feb 2009 11:09:00 GMT

朝から活性化レベルが落ちてるなー。アタマが回りださないわ。

昔書いたコード群とか、既存のプロジェクトとかからよさげなコード片を
くすねて再利用ってよくやります。

「あ、これもーらいっ♪」って{ から } まで切り取って貼り付けてコンパイル
すると「...がありません」て怒られる。別のナニカを呼んでたみたい。
なのでそこも切り取って貼り付ける。またしても「...がありません」て怒られる。
...いもづる式に依存しちゃってんのね。

そか、こんないもづる依存を断ち切るためにも、
interfaceで実装を分離するんだよなー。
んでもってDI(でぺんでんしぃ・いんぢぇくしょん)に繋がるわけかー
とかぽやーと思った。ｱｯﾀﾘﾒｰなんだけど。

...いかん茶が足りん。茶っぱのストックが...うあぁぁぁ orz

interfaceとダック・タイピング

επιστημη — Tue, 27 Jan 2009 09:12:00 GMT

ネタ元 → Interfaceが使いこなせない。

interfaceは"責務の集合"に名前(カテゴリ)を与えるものですな。
利用者視点ではその名を冠するものが"～できる"ことが約束されており、
実装者視点ではその名を冠するかぎり"～できる"ことを保証せにゃなりません。
作るひとと使うひとの間の契約とでも申しましょうか。

Java/.NETにはinterfaceがありますけども、C++にはありません。
C++は多重継承があるから、純粋仮想関数だけで構成された
classをinterfaceの代わりに用いたりします。
てゆっかー、多重継承のできないJava/.NETが多重継承のかわりに
用意した、って雰囲気なんですけども。
# Java/.NETはinterfaceならいくつも継承(実装)できますからね

C++ではtemplateを使ったダック・タイピングって手法があります。
"鴨とはなにか"(=interface:鴨は～できる)が明確に定義されてなくたって、
鴨のようにふるまうならそいつぁ鴨とみなしていぃじゃない、
ってリクツです。

#include <iostream>
using namespace std;

// トランプの場札
struct CardDeck {
void draw() { cout << "カードを一枚引く\n"; }
};

// 預金口座
struct Account {
void draw() { cout << "預金を引き出す\n"; }
};

// 製図器
struct Drafter {
void draw() { cout << "図面を描く\n"; }
};

// ...に対し draw する： drawできるならDrawableとみなしていいじゃない
template<typename Drawable>
void draw_by(Drawable& target) {
target.draw();
}

int main() {
draw_by(CardDeck());
draw_by(Account());
draw_by(Drafter());
}

トランプの場札、預金口座、製図器に共通の基底クラス(=interface)はありません。
が、どれもdrawできるんだからDrawableとみなすわけや。

かーぢなりちぃとかれぢでんしぃとか(ご意見伺い)

επιστημη — Tue, 20 Jan 2009 14:46:00 GMT

設計書書いてます。こりこりと。
フェイズ的には機能から詳細に掛かるくらい。

クラス・ダイアグラムやら状態遷移やらファイル・フォーマットやら、
詳細設計に必要となりそうなもんを詰め込んでる最中なのですが

それぞれのクラスについて、そのインスタンスが:
- それはアプリケーション内に常駐(resident)するか、
　それとも使いたいときにひょこっと起こして(transient)使い捨てるか。
- それはアプリケーション内にいくつある(cardinality)のか?
　常に1? 常に5? 1個以上いくつでも? 最小0の最大27?

なんて情報、どこに/どんなふぅに書きます?
クラス・ダイアグラムにはクラス間の関係として1対1とか1対nとか
書きますけどもこれはあくまでクラスとして、ですよね。

実際に動いてるときの動的な数はどこに/どのように書くのが吉なんでしょか。

スマートな案が出てこなかったので、暫定的にcardinality/residencyの章を
こさえてそこにクラス毎の数および生成/消滅タイミングを書いてるんだけど、
どぉもしっくりいかない。この章だけがポコっと浮いちゃうみたいな。

「アイデア」とか「俺はこうする/こうしてる」とかあったら教えてくださいまし。

[追記] ここでナゼか夏椰さんがアタマに浮かぶ(説明不能)...

あのさ、DatabaseでCRUD(Create, Read, Update, Delete) てのがあるやん。
アレのクラス版を表形式で書くのはどうだろう。
各クラスに対し、インスタンスがCreate, Read, Update, Delete されるタイミングを明記しておくの。
ホントに使い捨てのUtilityクラスはいいとして、主要なクラスについてこの表を
埋めることができない(あるいは悩む)ようなら、まだ設計が甘いことの証左になるよねぇ。

interfaceに物申す(3)

επιστημη — Wed, 07 Jan 2009 09:24:00 GMT

interfaceに物申すのコメントでちらっと出てきた NVI について。

NVI:non-virtual interface : 非仮想インタフフェイス
そこそこ名の通ったイディオムかと思うです。

class なにか {
public:
virtual void なにかする() { ... }
};

じゃなくて

class なにか {
public:
void なにかする() // non-virtual
{ あーする(); こーする(); }
protected:
virutal void あーする();
virtual void こーする();
};

てなｽﾝﾎﾟｰで、公開メソッドをvirtualにしないってスタイル(イディオム)。
導出クラス側では直接なにかする() を再定義すんじゃなく、
あーする() やこーする() を再定義するなり再利用するなりせぇ、と。

こうしておけば、後日なんらかの理由でなにかする() のインタフェースが変更に
なったとき、再定義されたなにかする() の変更をこいつの導出クラス全員に
お願いして回らんでええわけや。

C++の場合、再定義させないkeyword: finalやsealedに相当するものを
持ち合わせてないのでその代わり、の意味もありますです。

interfaceに物申す(2)

επιστημη — Tue, 06 Jan 2009 13:33:00 GMT

ちょっと長くなりそうだったのでエントリ立て。

interfaceに物申すのself コメント:

　　interface I商品 {
　　　int 売値();
　　}

　　interface I売りもん : I商品 {
　　　int 原価();
　　}

　　とかやっといて、商店は I売りもんをもってるけど、
　　お客さんには I商品として見せろ。

　　ってーことかしら。
　　なんか直接的じゃないんだよなー...

　　八百屋さんはりんごを I売りもんとして扱います。

　　class りんご : I売りもん {
　　　Color 色() { ... }
　　}

　　お客さんには値段しか書かれていない真っ黒な袋に入った
　　I商品として見せろって?
　　じょーだんじゃない、お客はりんごが欲しいんだ。

ではこれは?

interface I商品 {
　int 売値();
}

interface I売りもん {
int 原価();
}

// 店頭に並べるりんご：色と売値を公開。
interface Iりんご : I商品 {
Color 色();
}

// 八百屋が仕入れたりんご。店頭に並べるが原価はナイショ
class 売りもんのりんご : I売りもん, Iりんご {}

こうすれば八百屋さんはお客に Iりんごを提供できます。
んが、I売りもんと I商品が泣き別れてます。
これもちょっと考えにくいつか許容し難いつか。

interfaceに物申す

επιστημη — Tue, 06 Jan 2009 12:10:00 GMT

interfaceね。その名の通りインタフェイスのみを宣言したもの。
C++でいえば純粋仮想関数(pure-virtual-function)のみで構成されたクラス(みたいなの)。

たとえば:

interface I商品 {
int 売値();
}

JavaにしろC#/VBにしろ、interfaceに記述するメソッド(あるいはプロパティ)は
すべてpublic扱いとなります。
interfaceなんだからそれに対して"何ができるか"は
公開すんのがアタリマエだろ常考ってリクツでしょう。

けどね、隠したいメソッド/プロパティもあるんじゃないかしら。
たとえば、商品の原価は売り手にとっては重要だけど
買い手や競合他社には見せたくないよね。
だから願わくはinterfaceに書くメソッド/プロパティには公開限定子を指定できて
ほしいのね。 ↓こんな具合に。

interface I商品 {
public int 売値();
private int 原価();
}

隠しておきたいけど必要なメソッド/プロパティをどうやって表現するんだろう。
# C++ならprivateなpure-virtual-functionが許されるのにのに

この疑問はその昔JavaでObservable/Observer使ったときに感じたものです。
Observer.update はObservable側で発した変更通知を受けたときに(のみ）反応すべきもの。
だからこいつは勝手に呼んでもらっちゃ困ります。隠しておきたいはずです。
なのにpublicにならざるを得ないのです。

それぢゃいかんだろぉ

επιστημη — Wed, 30 Jul 2008 09:49:00 GMT

それでいいんですかぃ? のつづき。

拡張メソッドによるなんちゃって多重継承に風穴を空けてみた。

    Android RTI = new Android();
    RTI.move();
    IMachine m = RTI; m.move();
    IHuman   h = RTI; h.move();

IMachine/IHumanにキャストしただけで
Androidの歩き方を忘れちゃいます。

正統(?)多重継承(C++)だと:

#include <iostream>

class Machine {
public:
virtual void move()
{ std::cout << "計算機がモーターを制御します\n"; }
};

class Human {
public:
virtual void move()
{ std::cout << "神経系が筋肉を制御します\n"; }
};

class Android : public Machine, public Human {
public:
virtual void move()
{ std::cout << "ギコギコ歩きますー\n"; }
};

int main() {
Android RTI;
RTI.move();
Machine* m = &RTI; m->move();
Human* h = &RTI; h->move();
};

ちゃんと継承してるんで、ちゃんと"ギコギコ"歩きます。

それでいいんですかぃ?

επιστημη — Wed, 30 Jul 2008 06:29:00 GMT

某所にて
「インターフェースに対して拡張メソッドでメソッドを追加するようにすれば、
事実上多重継承が実現できます」

ってゆーてた。えー、どゆことソレ? って突っ込んでみたところ:

interface Iほげらぶる {};

static class ほげらぶる実装 {
    public static void ほげ(this Iほげらぶる hoge) {
      Console.WriteLine("ほげほげー");
    }
}

interface Iぱよらぶる {};

static class ぱよらぶる実装 {
    public static void ぱよ(this Iぱよらぶる payo) {
      Console.WriteLine("ぱよぱよー");
    }
}

class ぺも : Iほげらぶる, Iぱよらぶる {
    public static void Main() {
      ぺも p = new ぺも();
      p.ほげ();
      p.ぱよ();
    }
}

なるほど、拡張メソッドによってインタフェースに実装を貼り付けることが
できるんだから、実装の貼り付いたインタフェースを多重継承すれば双方の
実装を継承できるってわけか。

でもねー、シグニチャがカブったらどないすんのよ。

interface IMachine {};

static class MachineImpl {
    public static void move(this IMachine machine) {
      Console.WriteLine("計算機がモーターを制御します");
    }
}

interface IHuman {};

static class HumanImpl {
    public static void move(this IHuman human) {
      Console.WriteLine("神経系が筋肉を制御します");
    }
}

class Android : IMachine, IHuman {
    public void move() {
      Console.WriteLine("ギコギコ歩きますー");
    }
    public static void Main() {
      Android RTI = new Android();
      RTI.move();
    }
}

Androidがmoveを再定義できるから破綻は免れたけども...
これでも多重継承できたというてえぇのやろうか。意見求ム。