オブジェクト指向は愚かな考え。この世は計算式 ★3©2ch.net (961ﾚｽ)
上下前次1-新
638(1): デフォルトの名無しさん [sage] 2016/08/04(木) 18:59:34.21 ID:iP1jJ0aF(1) AAS
>>610610(3): デフォルトの名無しさん [sage] 2016/08/04(木) 09:31:36.26 ID:0aO0sFCL(1/13) AAS
デザパタの実装はいろいろあっていいし、言語によって簡単に書けたりそもそも必要なかったりもする。
「オブジェクト指向における再利用のためのデザインパターン」←GoFのデザパタ提唱本ね。念のため。
プログラミング言語の選択は重要である。なぜなら、どの言語を使うかによってどのような観点でデ
ザインパターンをまとめるかが違ってくるからである。我々のパターンはSmalltalk/C+十レベルの言
語形態を想定している。その選択によって、容易に実現できることとできないことが決まる。たとえば、
もし、我々が手続き型言語を想定していれば、Inheritance(継承)、Encapsuladon(カプセル化)、
Polymorphism(ポリモルフィズム)といったデザインパターンを組み入れたであろう。また、我々のパタ
ーンの中には、あまリー般的でない言語によって直接サポートされているものもある。たとえば、CLOS
はマルチメソッドを有しているので、Visitorパターン(P.53)のようなパターンは必要性がなくなるの
である。実際のところ、SmalltalkとC十+の間にも違いがあり、どちらの言語を使うとより簡単に表現
できるかは、パターンによっても違ってくる(例としては、Iteratorパターン(P.275)を参照)。
iteratorはどっちが楽なの？
639(2): デフォルトの名無しさん [sage] 2016/08/04(木) 19:27:18.45 ID:0aO0sFCL(12/13) AAS
>>638
Smalltalk と C++ との比較で？ それならもちろん Smalltalk です。
（同書P.289より）
Smalltalkではiteratorを明示的に定義する必要はない。標準的なコレクションクラス(Bag、
Set、Dictionary、OrderedCollection、Stringなど)で、内部iteratorのメソッドdo:を定義してい
るからである。do:はブロック(つまり、closure)を引数としてとる。
（標準的なコレクションクラスの例になぜか名前がありませんが当然Arrayも含みます。念のため。）
640(1): デフォルトの名無しさん [sage] 2016/08/04(木) 19:40:49.06 ID:HlIXxJdQ(1/2) AAS
>>639
それでいうと今のC++もSTLでイテレーターが実装されてるから、
必要ないって言ってるようなもんじゃね？
別にSmalltalkが特別ってことにはならない。
641: デフォルトの名無しさん [sage] 2016/08/04(木) 20:21:25.52 ID:jTAWnEUa(12/22) AAS
>>635635(2): デフォルトの名無しさん [sage] 2016/08/04(木) 18:07:30.87 ID:iDV12Qqy(5/5) AAS
>>626
だーかーらー、
デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、というバッドノウハウは静的型OOPLのためのものにすぎなくて、
同等の機能はSmalltalkでクロージャを使った実装（当然、上記デコレータパターンの実装ではない）で実現できる。
という主張に、どうして「じゃあSmalltalkで実装したデコレータパターンはどうなんだよ」がどれだけ的外れか理解できてる？
> デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、
修飾オブジェクトで被修飾オブジェクトでラップしてっていうのは
Javaでの実装であって、Rubyのデコレーターパターンには必須ではないよ。
642(1): デフォルトの名無しさん [sage] 2016/08/04(木) 20:23:12.92 ID:jTAWnEUa(13/22) AAS
デコレータパターンは言語によっていろんな実装が有って
Javaでは修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで
型に互換性を持たせる、というバッドノウハウが静的型OOPLだから必要になるけど、
デコレーターパターンはSmalltalkでクロージャを使った実装で実現できる。
643(2): デフォルトの名無しさん [sage] 2016/08/04(木) 20:37:49.54 ID:0aO0sFCL(13/13) AAS
>>640
Smalltalkが特別ってことにはならないという点については同意します。
ただ、クロージャーを引数にとる内部イテレーターはとても簡潔な記述を可能にするので
C++がSTLを介してイテレーターが組み込みであっても、記述の負担の軽さはSmalltalk方式の方が優位かとも
とはいえ、C++のコードがどんな感じになるかははずかしながら当方ちょっと予想が付きかねますので、
もし可能でしたら、C++のSTLを使って書いてSmalltalkのと比較をさせてもらうことはできますか？
あいにくウィキペにはIteratorの例はないので、こちらの比較的シンプルなJavaの例を
外部ﾘﾝｸ:qiita.com
Smalltalkで書いてみました
外部ﾘﾝｸ:ideone.com
もちろんSmalltalk方式を採用した言語（たとえばRuby)なら、Smalltalkと同程度にシンプルに書くことはできます
そんなわけでRuby版も念のため
外部ﾘﾝｸ:ideone.com
644(1): デフォルトの名無しさん [sage] 2016/08/04(木) 20:41:57.05 ID:jTAWnEUa(14/22) AAS
イテレーターパターンをSmalltalkで書いてみたわけね。
645: デフォルトの名無しさん [sage] 2016/08/04(木) 20:47:45.80 ID:XSjm71+w(1) AAS
イテレータパターンを使わずとも
既にあるイテレータを使った、でしょ
646(2): デフォルトの名無しさん [sage] 2016/08/04(木) 20:55:24.22 ID:HlIXxJdQ(2/2) AAS
>>643
for each (range based for）でいいじゃん。
for (auto& item : collection)
{
// print an item
}
クロージャ風がいいなら、
std::for_each(collection.end(), collection.begin(), [](auto& item){ /* print */}
アイテレーターが登場するけど昔の名残みたいなもんで、
本質じゃないだろ？（範囲を指定してるだけ）
647(1): デフォルトの名無しさん [sage] 2016/08/04(木) 21:08:55.10 ID:ILqHD9/M(1) AAS
>>642
クロージャを使ったらデコレータとは言わないのでは？
デコレータは継承による多態性を用いたものに限定すべき。
同じ事をやる方法なんていくらでもあるから、
そこは継承によるものと限定しておかないと意味分からなくなる。
無論、今のC++やJava、C#だってクロージャもしくは
それに類似した機能を使って同じ様なことはできるし、
Smalltalkだって継承を使ったデコレーターはできる。
言語によってできることできないことと、
各言語の流儀みたいなものは切り分けて考えるべき。
648(1): デフォルトの名無しさん [sage] 2016/08/04(木) 21:15:46.97 ID:jTAWnEUa(15/22) AAS
>>647
デコレータの説明として、インターフェイスを同一視して
動的に機能を拡張していくとは書いてあるが
継承を用いることとは書いていない。
649: デフォルトの名無しさん [sage] 2016/08/04(木) 21:21:02.95 ID:CmNfOhbZ(1/6) AAS
>>648
それは定義じゃないだろ。GoF本では定義はStructureのところだ。
650(1): デフォルトの名無しさん [sage] 2016/08/04(木) 21:29:07.85 ID:jTAWnEUa(16/22) AAS
Structureは日本語にしたら
構造って意味ですよｗ
651: デフォルトの名無しさん [sage] 2016/08/04(木) 21:30:27.36 ID:CmNfOhbZ(2/6) AAS
>>650
んなことは分かってるだろ。そこが実質的な定義だと言ってるの。
そのあとにImplementationが来て、その構造の実装法やアレンジを述べる流れ。
652: デフォルトの名無しさん [sage] 2016/08/04(木) 21:33:42.86 ID:TDXgEb4R(1) AAS
継承してないと使えないとかじゃ困る。
653(1): デフォルトの名無しさん [sage] 2016/08/04(木) 21:34:27.18 ID:jTAWnEUa(17/22) AAS
> そこが実質的な定義だと（俺様が）言ってるの。
知らんがなｗ
お前が何を言ったところで、
Structureは日本語にしたら構造
Definition（定義）じゃない。
まさか単語の意味を強弁するとは思わなかったなｗ
654: デフォルトの名無しさん [sage] 2016/08/04(木) 21:39:49.22 ID:CmNfOhbZ(3/6) AAS
>>653
暗黙の定義ってやつだ。プログラミングしてるなら分かれ。
655: デフォルトの名無しさん [sage] 2016/08/04(木) 21:51:04.78 ID:jTAWnEUa(18/22) AAS
説得力0ｗ
656: デフォルトの名無しさん [sage] 2016/08/04(木) 21:51:55.34 ID:VNJ4iqic(1) AAS
この場合、構造、だとしても問題無い件。
パターンの構造はこうであると定めてる。
657: デフォルトの名無しさん [sage] 2016/08/04(木) 22:03:13.75 ID:jTAWnEUa(19/22) AAS
構造の一例ねｗ
658: デフォルトの名無しさん [sage] 2016/08/04(木) 22:10:23.67 ID:CmNfOhbZ(4/6) AAS
デザインパターンなんだから特定の構造を集めたものだからな。
同じ事ができるならなんでもいいならパターンとはいわない。
まあ馬鹿は無視して議論続けてくれ。
659(1): デフォルトの名無しさん [sage] 2016/08/04(木) 22:12:49.41 ID:jTAWnEUa(20/22) AAS
まさかデザインパターンがGoFの23個だけだと？
あれはパターン例だよ
660: デフォルトの名無しさん [sage] 2016/08/04(木) 22:14:24.41 ID:CmNfOhbZ(5/6) AAS
>>659
それこそ誰もそんな話はしていないわけだが。
国語のテストとか悪かったでしょ？
661: デフォルトの名無しさん [sage] 2016/08/04(木) 22:20:23.44 ID:jTAWnEUa(21/22) AAS
Structureは日本語にしたら構造
Definition（定義）じゃない。
国語と英語の問題なｗ
662: デフォルトの名無しさん [sage] 2016/08/04(木) 22:24:49.05 ID:CmNfOhbZ(6/6) AAS
アホの一つ覚えとはこのこと
上下前次1-新書関写板覧索設栞歴
あと 299 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.657s*