東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

interfaceに物申す(2)

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

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商品 が泣き別れてます。
これもちょっと考えにくいつか許容し難いつか。

投稿日時 : 2009年1月6日 13:33

コメントを追加

# re: interfaceに物申す(2) 2009/01/06 14:18 ゆーち

あんま考えていませんが(^^;
「名詞」を interface するってのにムリがありそうな気がします。


interface I販売{
int 売値を決定();
}

class 商品 : i販売
{
int 原価;
}

class りんご
{
Color 色;
}

class 売り物りんご : りんご, 商品{}


名詞はオブジェクトになるけど、動詞はインターフェースどまり。「~する」と表現できるサ変名詞も「動詞」。

こんな感じじゃないのかなぁ・・・

# re: interfaceに物申す(2) 2009/01/06 14:24 επιστημη

C++ならともかくも、多重継承を許さんヤツでは
りんごと商品から導出できませんの。

たとえできても、それだとりんごの売値を客が決定できちゃうやん。

売り手以外には触れないinterface-methodを宣言したいワケよ。

# re: interfaceに物申す(2) 2009/01/06 14:29 ゆーち

(゜∀゜)多重継承を許さない?そーなんですか・・・

売値の決定は、見えない場所(売り物りんごのコンストラクタ)で、interface を継承された、「けちなおやじ」の売値の決定()メソッドに結びつけられるようにするので、客は決定できないって感じでとらえてました。

# re: interfaceに物申す(2) 2009/01/06 14:39 επιστημη

そーなんです。
代わりと言っちゃなんですがinterfaceだけは多重継承
できます(実体のない"名ばかりクラス"なので)。

そんとき、interfaceで宣言したメソッドはすべて
public扱いなんだけど、その一部を隠蔽したいことが
あるんじゃない(売値決定とか原価とか)?
そんときどーする? っておはなし。

# re: interfaceに物申す(2) 2009/01/06 15:10 ゆーち

interface は、Javaでちょいとかじりはしましたが、記憶の彼方ですw

継承せずに、interface をメンバーで参照できないでしょうか?
動的に売値を決定できる販売者と結びつけてインスタンスを作るようにし向けると、うまく行きそうな気がします。
Factoryでしたっけ?

# re: interfaceに物申す(2) 2009/01/06 15:18 επιστημη

いやだからぁ、
「売値決定に必要なメソッドを販売者以外に見せない」
方法があるか、なんです。

# C++なら firend で逃げられるけどね

# re: interfaceに物申す(2) 2009/01/06 15:59 ゆーち

なるほど。問題になっている部分を理解しました。

冬眠しますw

# re: interfaceに物申す(2) 2009/01/06 17:05 aetos

internal interface にして、ライブラリをソースコードごと提供w
そうでないと C++ と対等にならんでしょ。
いくら friend でもライブラリのバイナリだけ渡してどうにかするのは無理だよね。

# re: interfaceに物申す(2) 2009/01/06 17:39 επιστημη

> C++ と対等にならんでしょ
そーかしら。
Java/.Netはライブラリがメタ情報持ってるんだから
C/C++でのヘッダ+ライブラリ提供と等価ちゃうんかな?

# re: interfaceに物申す(2) 2009/01/06 18:41 aetos

ちゅーか、C++ でできるとして、どんなコードになるの?
ライブラリ化に言及している以上、りんごクラス内に顧客クラス名を書くわけにいかんよね。
ついでに「C++のライブラリ」ってのはソースコードなのかしら? バイナリなのかしら?

あと、この話題って、趣旨は「そういう言語機能がほしいよね」でおk?
「C# で / Java でなんとかする方法はある?」ではないよね?

姑息な手なら、EditorBrowsableAttribute、とか。

# re: interfaceに物申す(2) 2009/01/07 0:32 επιστημη

> りんごクラス内に顧客クラス名を書くわけにいかんよね。

うん、りんご の基底クラス 売りもん なら 商人 に対して
friendにできるやろぉ、と。

class 売りもん {
 friend class 商人;
private:
 virtual int 原価() const =0;
};

こいつの導出クラス りんご で原価()を再定義、と。

# re: interfaceに物申す(2) 2009/01/07 0:38 επιστημη

>「そういう言語機能がほしいよね」

ですね。

interfaceには
「利用者に提供する機能一覧」と
「作成者が実装する機能一覧」の二面があんじゃないかと。
で、この両者が一致しない場合も考慮してくれたらなーと。

C++のfriendによるprivate外しはあまりに乱暴にも思えます。

# re: interfaceに物申す(2) 2009/01/07 12:02 aetos

はふーん。
friendness って継承されるんやー。
親の友達は子の秘密を見放題だけど、友達の子には秘密を明かさないのね。
軋轢生みそう。

# re: interfaceに物申す(2) 2009/01/07 12:36 επιστημη

friendnessは継承されませんょ

class 売りもん {
 friend class 商人;
private:
 virtual int 原価() const =0;
};

では 商人 は 売りもん の 原価() を呼べますが、
商人から導出した 八百屋 には無理。

# re: interfaceに物申す(2) 2009/01/07 12:54 aetos

いや、売りもんの派生クラスであるりんごの原価は商人から見えることです。

> 商人から導出した 八百屋 には無理。

これこそ可能であってほしい気がするけどね。

# re: interfaceに物申す(2) 2009/01/07 13:23 επιστημη

あー。はいはい。

# 次世代のカプセル化手法 2009/01/07 21:48 凪瀬 Blog

次世代のカプセル化手法

タイトル  
名前  
URL
コメント