スレッドメモ
MLやNewsのスレッドをメモする試み。
2003-10-14 (火)
◆ [oosquare-ml] 羽生田さん＠豆蔵会長との OO な対談記事
[03755] 友枝ななめねこ敦 (10/14)
Meme は本屋にも売っているらしいのですが，実はweb上にも載っています．
[03757] Hidehiko AKASAKA (10/14)
あと、驚いたのが「スロー・プログラミング」。「アジャイルはスローとセットでなければならないのです」とありますが、全くその通りだと思います。
# でもどうやって共存させるのだろう？やっぱり、反復の切れ目？？
[03762] 友枝ななめねこ敦 (10/14)
感覚的ですが，スローの中にアジャイルが納まるような気がしています．
[03770] 篠塚克利 (10/15)
ファーストフードの代表がマクドナルド、スローフードの代表がフレンチのコース料理だとします。このときの両者の違いは、注文した品が一度にトレイに載って出てくるか、一品ずつ出てくるかだと思います。
そう考えると、従来の開発方法こそがファーストフードであり、約束した機能を一度にデプロイしようとするわけです。当然、発注元は消化不良を起こし、不満が残ります。
これに対して、アジャイルは約束した機能を優先度の高い順にデプロイし、発注元にじっくりと味わってもらうわけです。そして、「この機能はちょっと脂っこかったから、デザートはあっさりしたのが良い」などの仕様変更に、臨機応変に応じることができるわけです。
◆ [oosquare-ml] C++ でのカプセル化
[03817] 井上美香子 (10/17)
いえ、JavaのパッケージはC++のfriendに比べたらずいぶん不完全な仕組みだと感じています。（C++のfriendが完全だということではないですけど……）
私はJava歴の方が長いのですが、実はあまり気に入っていないので……
パラメタライズドクラスはない、多重継承はない、Stringクラスだけ仕様が違って特別扱い……どうもしっくりきません。
[03818] Hideaki ONARU (10/17)
Eiffelではfeatureごとにきめ細かく公開先を指定できますよね。
「このfeatureはクラスAとBだけ、
このfeatureはクラスAとCだけ、
このfeatureはみんなに見せて、
このfeatureは誰にも見せない」のように。
[03824] Satoshi Sawada (10/17)
そういう意味からすると、Java での selective export は確かに非常に大雑把ですね。
private/package private/protected/public ですから。
とはいえ、今まで公開先のクラスを指定したいと思ったことはないので、必要ないかな、という気もします。
Java はその辺、割り切っているのだと思います。
[03828] Mikako Inoue (10/17)
Java派の人は「多重継承の実装のコンフリクト」を指してダメだダメだとおっしゃるのですけど、あれは実装のコンフリクトではなくて、インターフェイスのコンフリクトなんではないかと思うのです。
ですから、同様の問題がJavaのinterfaceを使っても起こります。
[03830] Satoshi Sawada (10/17)
多重継承は必ずしもダメではないです。ただ、実装がコンフリクトするということは、複数の異なるコンテキストがひとつのクラスに押し込められていることを意味します。
つまり、書かれているような interface の競合や多重継承のコンフリクトは、設計が不適切だと言うサインです。
クラスに対する責任が多すぎるのが原因です。
[03871] seraphy (10/18)
いつから、どのような目的でC++にfriendが導入されたのか知りませんが、非メンバ演算子のオーバーライド時にはfriendが必須でしょう。しかし、それ以外のケースでは、じつは必ずしも必要ないように思われます。