[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2ch.scのread.cgiへ]
Update time : 01/06 06:56 / Filesize : 295 KB / Number-of Response : 972
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

オブジェクト指向は愚かな考え。この世は計算式 ★3



1 名前:デフォルトの名無しさん mailto:sageteoff [2016/01/05(火) 02:10:25.72 ID:hJUQcrkl.net]
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
https://twitter.com/ProgrammingMono/status/665702678006140928

研究グループは、血管新生注において血管が伸長する際の血管内皮細胞注運動を制御するしくみを、生物学と数理モデル・
コンピュータシミュレーションを融合させた先端的な研究手法により明らかにしました。

生物は、最小の機能単位である細胞が寄り集まった多細胞体です。しかし、細胞の集まりが、組織や器官といった
秩序ある形態や構造をつくり機能するしくみはほとんど分かっていません。中でも血管は、体中の全組織に十分な
酸素や栄養源を効率よく供給するため、組織や組織の間に入り込み、血管外の環境との相互作用により、巧妙な
枝分かれ構造をとっています。

これまでに本研究グループは、新しく血管がつくられる(血管新生)際の細胞の動きに着目し、特に血管内皮細胞の
動きをリアルタイムで可視化し、定量的に捉えることを可能にしてきました。

今回さらに、血管の伸長を制御するしくみについて、細胞が自発的に自らを制御して動く過程(自律的過程)と、
隣接した細胞から適宜影響を受けて動く過程(協調的過程)がうまく共存することで、全体の動きが巧みに統制
されていることを世界に先駆けて実証しました。

興味深いことに、血管内皮細胞が前後したり、お互いに追い抜きあったりという血管新生で見られる複雑な細胞集団の
動きを制御している中枢部分は、細胞一つ一つの動き(スピードと方向性)の「確率的な変化」として十分説明できる
ことをコンピュータシミュレーションで実証しました。
www.jst.go.jp/pr/announce/20151120-2/#YOUGO3

前スレ
オブジェクト指向は愚かな考え。この世は計算式 ★2
peace.2ch.net/test/read.cgi/tech/1450153388/

620 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 11:37:47.99 ID:0aO0sFCL.net]
>>619

もしそうだとしても、少なくとも>>591は「GoFの(デコレーター)」と明記すべきですよね

621 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 12:27:01.14 ID:CY/jwgqy.net]
smalltalkって簡単に色々できるんでしょ?
なんで現代でメジャーじゃないの?

622 名前:デフォルトの名無しさん [2016/08/04(木) 12:30:59.74 ID:IwXa2U8x.net]
日本語の方が優れてるのに、世界じゃ日本人しか使ってないだろ?

623 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 12:31:27.57 ID:79cTVfxr.net]
MSがVisual Smalltalkをつくらなかったから

624 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 12:57:32.53 ID:iDV12Qqy.net]
>>620
GoFの定義如何に関わらず、>>546はデコレータパターンの実装ではないのだが?

625 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 13:05:00.50 ID:rDDGHvQu.net]
はやく、
人間クラスと美少女クラスの問題に
たどり着いてくれよ。

626 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 13:16:23.28 ID:0aO0sFCL.net]
>>624
だとするとちょっと分からないのですが、
あなたの言う「Smalltalkなら簡単に記述できる構造や機能」で実現された
デコレーターパターン(GoFの定義如何に関わらない)というのを提示してもらうことはできますか?
Smalltalk は書けないということでしたら、端的に方針だけ示してもらえればこちらで書きますので。

そもそも Smalltalk ではデコレーターパターンが不要(なので、実装はナンセンス)とのお考えでしたら
代替として Smalltalk 組み込みのどういう構造や機能を使うかを示してもらえればさいわいです。

627 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 14:01:27.52 ID:gwNa+xfa.net]
つか、>>546のruby版って一体何?
デコレータパターンのつもり?

628 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 14:13:24.61 ID:0aO0sFCL.net]
>>627
自分にはウィキペのデコレーターにあるJavaの例の要求仕様は満たしているように見えるけど。
具体的にはどこが不満?



629 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 14:41:37.79 ID:gwNa+xfa.net]
>>628
あ、デコレータパターンの実装だったんだ。
同じ感じでこれ実装できる?
class Log
def output(s)
puts s
end
end

class TimeStampLog
def initialize(log)
@log = log
end

def output(s)
@log.output "#{Time.now} #{s}"
end
end

class PidLog
def initialize(log)
@log = log
@pid = Process.pid
end

def output(s)
@log.output "[#{@pid}] #{s}"
end
end

630 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 14:42:24.41 ID:gwNa+xfa.net]
log = TimeStampLog.new(PidLog.new(Log.new))
log.output 'aaa'
log.output 'bbb'

log2 = PidLog.new(TimeStampLog.new(Log.new))
log2.output 'aaa'
log2.output 'bbb'

結果:
[24968] 2016-08-04 14:41:58 +0900 aaa
[24968] 2016-08-04 14:41:58 +0900 bbb
2016-08-04 14:41:58 +0900 [24968] aaa
2016-08-04 14:41:58 +0900 [24968] bbb

631 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 16:18:58.29 ID:0aO0sFCL.net]
>>629

これでいい?

ideone.com/WGTiOD

632 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 16:59:33.41 ID:gwNa+xfa.net]
>>631
なんか実装手段が違ってきてますが・・・。

>>546のruby版はいったいどういう意図なのかが知りたいんだけど。
「rubyでclosureを使えばデコレータパターン同等のことができる」とか、そういう「意図」。

633 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 17:09:10.90 ID:0aO0sFCL.net]
>>632
> なんか実装手段が違ってきてますが・・・。

本質部分は変えてないでしょ
変えたのも、クラスを直にいじるか、モジュールをprependするかくらいなもので


> closureを使えばデコレータパターン同等のことができる

>>540,545,546 の流れで、件のコードにそれ以外の意図を思いつくなら逆に聞きたい

634 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 17:41:28.54 ID:gwNa+xfa.net]
>>633
うまく説明できないので、最後まで残っている違和感だけを説明して終わる。

WikipediaのDoublePriceクラスで、何か振る舞いを変えようと思えばDoublePriceクラスのみを変更すればいい。
DecoratorTestクラスの変更もしなくていい。

一方、>>546のコードだとそうはいかない。
これを「デコレータパターンを実装している」といっていいのか?
というのが俺の違和感。
まあ、それが本質なのか本質じゃないのかはわからんが。

635 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 18:07:30.87 ID:iDV12Qqy.net]
>>626
だーかーらー、

デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、というバッドノウハウは静的型OOPLのためのものにすぎなくて、
同等の機能はSmalltalkでクロージャを使った実装(当然、上記デコレータパターンの実装ではない)で実現できる。

という主張に、どうして「じゃあSmalltalkで実装したデコレータパターンはどうなんだよ」がどれだけ的外れか理解できてる?

636 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 18:33:42.23 ID:0aO0sFCL.net]
>>634
> 一方、>>546のコードだとそうはいかない。

単純に、ideone.com/WW8gva はデコレートをテストにハードコードしているからそうなるってだけで
ideone.com/HOkUN1 というふうに書いておけば、デコレーターの振る舞いを変えたければ
それを定義した decorate_price.rb だけを変えれば、decorate_price_test.rb は変更不要でしょう。

637 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 18:57:12.60 ID:0aO0sFCL.net]
>>635
なるほど。たしかにおっしゃるとおりです。的外れなことを言ってすみません。

638 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 18:59:34.21 ID:iP1jJ0aF.net]
>>610
iteratorはどっちが楽なの?



639 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 19:27:18.45 ID:0aO0sFCL.net]
>>638
Smalltalk と C++ との比較で? それならもちろん Smalltalk です。

(同書P.289より)
Smalltalkではiteratorを明示的に定義する必要はない。標準的なコレクションクラス(Bag、
Set、Dictionary、OrderedCollection、Stringなど)で、内部iteratorのメソッドdo:を定義してい
るからである。do:はブロック(つまり、closure)を引数としてとる。

(標準的なコレクションクラスの例になぜか名前がありませんが当然Arrayも含みます。念のため。)

640 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 19:40:49.06 ID:HlIXxJdQ.net]
>>639
それでいうと今のC++もSTLでイテレーターが実装されてるから、
必要ないって言ってるようなもんじゃね?
別にSmalltalkが特別ってことにはならない。

641 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:21:25.52 ID:jTAWnEUa.net]
>>635
> デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、

修飾オブジェクトで被修飾オブジェクトでラップしてっていうのは
Javaでの実装であって、Rubyのデコレーターパターンには必須ではないよ。

642 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:23:12.92 ID:jTAWnEUa.net]
デコレータパターンは言語によっていろんな実装が有って
Javaでは修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで
型に互換性を持たせる、というバッドノウハウが静的型OOPLだから必要になるけど、
デコレーターパターンはSmalltalkでクロージャを使った実装で実現できる。

643 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:37:49.54 ID:0aO0sFCL.net]
>>640
Smalltalkが特別ってことにはならないという点については同意します。

ただ、クロージャーを引数にとる内部イテレーターはとても簡潔な記述を可能にするので
C++がSTLを介してイテレーターが組み込みであっても、記述の負担の軽さはSmalltalk方式の方が優位かとも

とはいえ、C++のコードがどんな感じになるかははずかしながら当方ちょっと予想が付きかねますので、
もし可能でしたら、C++のSTLを使って書いてSmalltalkのと比較をさせてもらうことはできますか?

あいにくウィキペにはIteratorの例はないので、こちらの比較的シンプルなJavaの例を

qiita.com/jonichonpa/items/208dc2361414f93efacf

Smalltalkで書いてみました

ideone.com/oplhQu

もちろんSmalltalk方式を採用した言語(たとえばRuby)なら、Smalltalkと同程度にシンプルに書くことはできます
そんなわけでRuby版も念のため

ideone.com/xlQZqc

644 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:41:57.05 ID:jTAWnEUa.net]
イテレーターパターンをSmalltalkで書いてみたわけね。

645 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:47:45.80 ID:XSjm71+w.net]
イテレータパターンを使わずとも
既にあるイテレータを使った、でしょ

646 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:55:24.22 ID:HlIXxJdQ.net]
>>643
for each (range based for)でいいじゃん。

for (auto& item : collection)
{
// print an item
}

クロージャ風がいいなら、
std::for_each(collection.end(), collection.begin(), [](auto& item){ /* print */}

アイテレーターが登場するけど昔の名残みたいなもんで、
本質じゃないだろ?(範囲を指定してるだけ)

647 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:08:55.10 ID:ILqHD9/M.net]
>>642
クロージャを使ったらデコレータとは言わないのでは?
デコレータは継承による多態性を用いたものに限定すべき。
同じ事をやる方法なんていくらでもあるから、
そこは継承によるものと限定しておかないと意味分からなくなる。

無論、今のC++やJava、C#だってクロージャもしくは
それに類似した機能を使って同じ様なことはできるし、
Smalltalkだって継承を使ったデコレーターはできる。

言語によってできることできないことと、
各言語の流儀みたいなものは切り分けて考えるべき。

648 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:15:46.97 ID:jTAWnEUa.net]
>>647
デコレータの説明として、インターフェイスを同一視して
動的に機能を拡張していくとは書いてあるが
継承を用いることとは書いていない。



649 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:21:02.95 ID:CmNfOhbZ.net]
>>648
それは定義じゃないだろ。GoF本では定義はStructureのところだ。

650 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:29:07.85 ID:jTAWnEUa.net]
Structureは日本語にしたら
構造って意味ですよw

651 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:30:27.36 ID:CmNfOhbZ.net]
>>650
んなことは分かってるだろ。そこが実質的な定義だと言ってるの。
そのあとにImplementationが来て、その構造の実装法やアレンジを述べる流れ。

652 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:33:42.86 ID:TDXgEb4R.net]
継承してないと使えないとかじゃ困る。

653 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:34:27.18 ID:jTAWnEUa.net]
> そこが実質的な定義だと(俺様が)言ってるの。


知らんがなw

お前が何を言ったところで、
Structureは日本語にしたら構造
Definition(定義)じゃない。

まさか単語の意味を強弁するとは思わなかったなw

654 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:39:49.22 ID:CmNfOhbZ.net]
>>653
暗黙の定義ってやつだ。プログラミングしてるなら分かれ。

655 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:51:04.78 ID:jTAWnEUa.net]
説得力0w

656 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:51:55.34 ID:VNJ4iqic.net]
この場合、構造、だとしても問題無い件。
パターンの構造はこうであると定めてる。

657 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 22:03:13.75 ID:jTAWnEUa.net]
構造の一例ねw

658 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 22:10:23.67 ID:CmNfOhbZ.net]
デザインパターンなんだから特定の構造を集めたものだからな。
同じ事ができるならなんでもいいならパターンとはいわない。
まあ馬鹿は無視して議論続けてくれ。



659 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 22:12:49.41 ID:jTAWnEUa.net]
まさかデザインパターンがGoFの23個だけだと?
あれはパターン例だよ

660 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 22:14:24.41 ID:CmNfOhbZ.net]
>>659
それこそ誰もそんな話はしていないわけだが。
国語のテストとか悪かったでしょ?

661 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 22:20:23.44 ID:jTAWnEUa.net]
Structureは日本語にしたら構造
Definition(定義)じゃない。

国語と英語の問題なw

662 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 22:24:49.05 ID:CmNfOhbZ.net]
アホの一つ覚えとはこのこと

663 名前:デフォルトの名無しさん mailto:sage [2016/08/04(木) 22:45:18.74 ID:jTAWnEUa.net]
効いてる効いてるw

664 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 05:47:03.48 ID:Q5sCXOre.net]
あるプログラム片の構造がパターンカタログのものと異なっていたら、
そのプログラム片はそのパターンの実装とは言えないな。

実際問題として、このスレで出ているRuby実装は、GoFに掲載されたデコレータパターンの実装ではない。
それを無視するなら、あなた (ID:jTAWnEUa) にはデザインパターンを使うための
最低限の素地が備わっていないということ。

665 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 07:23:44.09 ID:TLRbqbFt.net]
>>644
あまりにひどくて、なにをいっているかわからなかった。SmalltalkはともかくRubyのコードも読めないのかと。

内部イテレーターを使ったこの実装をイテレーターパターンだと言い切るのはどう考えても無理があるし、
同じ理屈でクロージャーを使った件の実装をデコレーターパターンだと言い張っているなら混乱するだけだからやめてほしい。

666 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 08:28:16.86 ID:liZAD7d5.net]
>>664-665
この二人は単に常識的な発言をしているだけだが
きっと相手には伝わらないだろうね

667 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 11:01:37.11 ID:RHt058cj.net]
結局オブジェクト志向が理解出来なくて管を巻いていたら
世間はプロトコル志向に移ってしまったでござるの巻
お前ら何周遅れたら走り出す気になるの?

668 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 12:54:45.79 ID:Vwi1FrEy.net]
Swiftのプロトコルも何周回目か遅れですよ?
ScalaやRustのトレイトとか知らないんですか?



669 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 13:11:37.22 ID:ccW8btWE.net]
イテレータをアイテレータって書いてる人がいるけど
どこの方言なの?
weblioさんの発音もイテレータなんだけど

670 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 14:20:51.80 ID:1PWjv4l0.net]
weblioワロタw もっとちゃんとした辞書持って来いよ。
Merriam Websterとかさ。和英辞書を引用して日本語論じたりしないだろ?

色々調べてみたけど、Wikitionaryのiterateでは二重母音の発音も載せてる。
その他の辞書では見つからなかった。

実際に英語ネイティブのアメリカ人が/ai/でも発音しているのを聴いたこともある。
伝統的には一般的な発音じゃなかったけど、IT界隈でよく使われているうちに、
発音変種が発生したんじゃないか? 英語発音学的にはどちらでも許容されそうだし。

671 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 14:53:55.08 ID:1z/JWFxp.net]
>>669
方言というより極度の経験不足なんだろ
イテレータについて人と語った事が無いから
間違いがずっと正されずにここまで来たんだろうな

672 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 15:20:22.46 ID:Y7jgmn2a.net]
>669
iとかitとかitrとかiterとかに略すから
アイ、イット、アイター、アイターとかって呼んでいるのでは
発音している本人に聞かないと真相はわからんがな

673 名前:デフォルトの名無しさん [2016/08/05(金) 15:25:47.40 ID:j/FnlCNZ.net]
クロージャはデコレータじゃないとかPythonに全面的に喧嘩売りすぎだろ

674 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 15:40:45.96 ID:O4e+hfU+.net]
クロージャーを使った実装はデコレーターパターン(GoFの)ではないという話なんだが

675 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 15:47:55.44 ID:1PWjv4l0.net]
>>673
別のパターンって言ってるだけでは?
覚えやすさや関連性からデコレーターの名前を関するのは自由だけど。

676 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 16:10:54.07 ID:b8/AN42w.net]
Rubyのprependを使った例はDecoratorとしてもいい気がするが、単なるクロージャをDecoratorとは呼べない気がする

677 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 16:22:03.55 ID:VlcB2rw7.net]
デコレータパターンの機能を持っている設計を
全部デコレータパターンとしてしまっては
デザインパターンの意味がないからな

そりゃどんな方法でも同等の機能は実現するかもだが
ある程度を設計をパターン化して縛るのが目的でもあるからね
なんでもOKだったら意味ないよね

678 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 16:30:02.44 ID:1z/JWFxp.net]
カタログ化の価値を下げようとする連中は居るんだよ
広義のデザインパターンは〜とか
○○も××パターンの亜流と言えるだろう〜とか
拡大解釈と独自解釈でどんどん元の輪郭をぼやかしていくんだよ



679 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 18:48:03.79 ID:zTXcoGD+.net]
>>677
ケーキにホイップクリームのせるのもおちんぽにコンデンスミルクかけるのもデコレーションには違いないだろ実装が違うだけでやってることは完全に同じなのだから継承か委譲かクラスかクロージャかといった細かい違いを気にしなくていいからこその設計だと思うのだよ

680 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 18:50:15.99 ID:zTXcoGD+.net]
実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ

681 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 19:29:11.85 ID:Q5sCXOre.net]
>>680
そうか、おまえがいう「デザイン」「ソフトウェア設計」は実装を縛らないのか。
ずいぶんフリーダムなプログラマだなw

682 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 19:48:51.35 ID:7blLYh/r.net]
クラス図レベルがデザインパターン。
そこから実際にどう具体的な言語でコードに落とし込むかが実装。

クラス図レベルで全く違うものはパターンとして別物です。

683 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 20:06:03.26 ID:i8crE51h.net]
おまいら、自動翻訳で日本語をえいごにして、出た英語を自動翻訳で日本語にして、元の日本語と違うってモンクいってるんだよな?

684 名前:デフォルトの名無しさん mailto:sage [2016/08/05(金) 20:28:42.82 ID:1l5AtzWC.net]
>>670
それ単に英語がなまっているだけだから

685 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 08:01:13.80 ID:70rUJ/gH.net]
>>684
なまってるんじゃなくて、発音が[i]の母音に強いアクセントがつくと[ai]に転じるのは普通。
iterateの第1母音は普通は[i]だが、iterateという語を特に強調する時には[ai]になることもある。

ちなみにweblioはUS出身のNLP研究者にも評価が高かったりするから、そう馬鹿にしたものでもない。

686 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 10:06:20.97 ID:FhFbCTi8.net]
>>685
だから英語の訛りでドイツ語やフランス語では起こらない
https://ja.wikipedia.org/wiki/%E5%A4%A7%E6%AF%8D%E9%9F%B3%E6%8E%A8%E7%A7%BB

687 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 10:13:18.00 ID:BacY3CwA.net]
だからどうしたんだって話

688 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 10:17:01.24 ID:BZ9Nu5V3.net]
アイテレータ君は頑張りどころを間違えてる



689 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 11:27:40.31 ID:70rUJ/gH.net]
>>686
Haben Sie gelesen, eine deutsche Übersetzung?

690 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 12:00:01.53 ID:rJo5wxwi.net]
https://translate.google.co.jp/#de/ja/Haben%20Sie%20gelesen%2C%20eine%20deutsche%20%C3%BCbersetzung%3
あなたはドイツ語の翻訳を読んでいましたか?

691 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 12:02:23.29 ID:rJo5wxwi.net]
>>689
Was davon ist im Zusammenhang mit?

692 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 13:54:29.24 ID:70rUJ/gH.net]
>>691
Das ist meine Frage.

693 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 15:01:07.75 ID:rJo5wxwi.net]
Nein, es ist meine Frage

694 名前:643 mailto:sage [2016/08/06(土) 19:33:40.65 ID:rdi0Pbkh.net]
そんなアイレテーター君にヒントをもらった>>646 ですが、
週末の余暇を使って調べ調べ C++ で書いてみました。

ideone.com/aMHgqO

なるほど。このくらい抽象化して簡潔に書けるなら
今の C++ には35年ほど前の Smalltalk 同様イテレーターパターンは不要と言い切ってよさそうですね。

惜しむらくは逆順用の range-based for くらい用意しておけよ…、という不満は残りますが。^^;

695 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 20:05:53.09 ID:OCZ+hMAU.net]
そもそもbegin, endなどのモロモロが
既に(外部)イテレータ以外の何物でもないわけでw

内部イテレータ形式を欲しがるかどうかはともかく
range-based forとかはどうでもいいよねこの場合

696 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 20:24:55.16 ID:fG7kY+EI.net]
アメリカ英語なんて
英語の方言そのものだろ。w
トマトをトメイトゥとか、
ポテトをポテイトゥとか
馬鹿みたいな発音するんだぜ。
アイテレーターみたいな馬鹿っぽい発音が好きなのか?

697 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 21:29:05.67 ID:rdi0Pbkh.net]
>>695
おっしゃりたいことがよくわからなかったのですが
「イテレーター(内部なり外部なりの)が標準で提供されていればイテレーターパターン(GoFの)はいらない」
という主張(>>639,646)に対して「そもそも〜」はどういう反論で、
range-based forがなぜ「どうでもいい」という話になるのしょうか?

698 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 22:17:57.01 ID:70rUJ/gH.net]
>>693
おいおい、Neinに続いて肯定文とか、なんなんだその日本語みたいなドイツ語もどきはw



699 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 22:19:24.01 ID:70rUJ/gH.net]
>>696
はいはい、あなたは馬鹿ですよ。認めてあげましょう。

700 名前:デフォルトの名無しさん mailto:sage [2016/08/06(土) 22:20:26.81 ID:70rUJ/gH.net]
>>695
>そもそもbegin, endなどのモロモロが
>既に(外部)イテレータ以外の何物でもないわけでw

だめだ、こいつは手の施しようがないw

701 名前:デフォルトの名無しさん mailto:sage [2016/08/07(日) 00:32:53.21 ID:Z9t6ZbaZ.net]
>>697
ごめん
流れつかめて無かったわ

標準のコンテナにイテレータがあるんなら
それを使う限りはイテレータパターンの必要も無い
(内部イテレータ形式もrange-based forも無くてもいい)

それだけの話
スレの最初のほうに既に書かれてる話

702 名前:デフォルトの名無しさん mailto:sage [2016/08/07(日) 00:34:17.18 ID:JriZaYfU.net]
もう少し正確に言えば、言語やライブラリが
イテレータパターンを実装しているから、
あとはそれに従うだけって感じかな。
意識せずにイテレータパターンを使っている。

703 名前:デフォルトの名無しさん mailto:sage [2016/08/07(日) 00:40:31.89 ID:fZ/XAaEO.net]
>>702
そやね
その言い方は正しい

704 名前:デフォルトの名無しさん mailto:sage [2016/08/07(日) 06:55:15.73 ID:N62pNMnU.net]
>>702
「意識せずにイテレータパターンを使っている」は大間違い。

705 名前:703 mailto:sage [2016/08/07(日) 08:03:17.31 ID:vAScX9Az.net]
>>704
そやね
そっちが正しい
パターンを使うのは設計者だからね

706 名前:デフォルトの名無しさん mailto:sage [2016/08/08(月) 12:57:55.81 ID:TCnmrmuR.net]
おっすおらフリーダムプログラマ
日夜社畜プログラマと戦ってるだ

707 名前:デフォルトの名無しさん mailto:sage [2016/08/08(月) 13:46:12.84 ID:jSuSjrUB.net]
>>702
> もう少し正確に言えば、言語やライブラリが
> イテレータパターンを実装しているから、

正確に言うなら、イテレータパターンというのは、
> コンテナオブジェクトの要素を列挙する手段を独立させることによって、コンテナの内部仕様に依存しない
> 反復子を提供することを目的とする
実装パターンのことで(Wikipediaより)、言語やライブラリがiterableな何かを提供しているからといって、
それらがイテレータパターンを実装しているとは限らない。

708 名前:デフォルトの名無しさん mailto:sage [2016/08/08(月) 13:48:55.90 ID:jSuSjrUB.net]
>>680
> 実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ
発想が逆だね。
ある機能を実現するための実装パターンを分類・カタログ化したものが、GoFのデザインパターンだ。



709 名前:デフォルトの名無しさん mailto:sage [2016/08/08(月) 21:13:01.03 ID:BQ4UM/x3.net]
まさしくその通りだね
そして同じ機能だったらどんな設計でもOKとしてしまっては
デザインパターンの意味がない
でもこの話題はもう終わりにしたいね

710 名前:デフォルトの名無しさん mailto:sage [2016/08/08(月) 21:24:02.49 ID:aqLNls7E.net]
だからデザパタなんか、屋根を屋根といってるだけで、トタンなのか瓦なのか藁葺きなのか何も定義してないって言っただろ。
だから積み木のおうちでも構わないんだよなぁ

711 名前:デフォルトの名無しさん mailto:sage [2016/08/08(月) 21:38:41.07 ID:dN7u7NbH.net]
パンピーは屋根には天井がセットでついてくると本気で思ってそうだから怖い。

712 名前:デフォルトの名無しさん mailto:sage [2016/08/08(月) 21:41:39.71 ID:q4pU/gN8.net]
>>709
とは言っても言語が違ってもデザインパターンは通用するわけで
実装がたった一つというわけじゃないのは確か

C言語でオブジェクト指向をすることだってあるし、
クラスがなかったES5時代のJavaScriptでもデザインパターンは作れた。

重要なのはデザインパターンの設計に出てくる登場人物があるかどうかではないだろうか?
例えば、Decoratorパターンだと、Component、ConcreteComponent、
Decoretor、ConcreteDecoratorという登場人物がある。

これはクラス図で書かれているだろうけど、別にクラスである必要はない。
例えばクロージャーを使って実装してもかまわない。
またインターフェースは明示的に継承していなくても、事実上特定の関数を実装していなければ
正しく動かないなら、それはインターフェースを使っていると言ってもいいだろう。

これと同じ登場人物が出てくるものは同じデザインパターンといっても良いだろう。

713 名前:デフォルトの名無しさん mailto:sage [2016/08/08(月) 21:46:47.76 ID:rabkqueT.net]
そこまで行ったら別物だって。
クロージャーやら使ってクラス図レベルで逸脱してもいいという
宗派をひらきなよ。

714 名前:デフォルトの名無しさん mailto:sage [2016/08/08(月) 21:57:23.36 ID:q4pU/gN8.net]
>>713
そうはいってもだね。
クラス図がないES5でもデザインパターンの
設計通りに作れるでしょ?

715 名前:デフォルトの名無しさん mailto:sage [2016/08/09(火) 05:48:45.82 ID:tGFAeOU0.net]
>>712
ばーか

716 名前:デフォルトの名無しさん mailto:sage [2016/08/09(火) 07:42:08.32 ID:ttLAI02G.net]
>>714
クラス、クラス図がないからデザパタにクラスは不要というのは、本末を転倒してますよ。

GoF も述べているように(>>610) クラスの無い言語では、クラスの役割りを「カプセル化」パターン、
「継承」パターン等で補ってから、その上でたとえばデコレーターパターンを実現しているというだけです。

717 名前:デフォルトの名無しさん mailto:sage [2016/08/09(火) 09:40:43.48 ID:zWs+JfAu.net]
>>716
なるほど。言語仕様としてクラスの有無ではなく
継承パターンができていれば、その実装がクロージャーでも
かまわないということですね。

そして継承パターンと言うものには、何が何を継承している
という概念があるはずですから、その「何」が登場人物に
なるわけですか。

718 名前:デフォルトの名無しさん mailto:sage [2016/08/09(火) 10:28:51.94 ID:GFJow9Sf.net]
登場人物という考え方がバカっぽくて無理



719 名前:デフォルトの名無しさん mailto:sage [2016/08/09(火) 15:03:31.41 ID:V7FsU68Q.net]
「○○言語だともっと簡単に実装できる」君と
「クロージャを使えばもっと簡単に実装できる」君は
いい加減うざいよ?

720 名前:デフォルトの名無しさん mailto:sage [2016/08/09(火) 16:26:29.88 ID:tGFAeOU0.net]
>>719
その通りだと思います。
まずはソフトウェア設計は実装ではないが、
実装を縛る規範であるということを
理解したらいいと思います。

それが理解できたら帰っておいで。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<295KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef