オブジェクト指向は愚かな考え。この世は計算式 ★3©2ch.net (946ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
592: デフォルトの名無しさん [sage] 2016/08/04(木) 00:19:01.73 ID:jTAWnEUa(1/22) AAS
> クロージャで実装しているのだから、
クロージャで "何を" 実装しているの？
594: デフォルトの名無しさん [sage] 2016/08/04(木) 00:25:35.63 ID:jTAWnEUa(2/22) AAS
いや、何を実装したのかを聞いたんだが？
実装したものは何？
597(1): デフォルトの名無しさん [sage] 2016/08/04(木) 00:34:51.00 ID:jTAWnEUa(3/22) AAS
>>595595(1): デフォルトの名無しさん [sage] 2016/08/04(木) 00:30:18.03 ID:ynLXOlFE(1) AAS
>>590
あのあたりはむしろメモリや記憶装置いくらでも使える現代向けというか
過去にオブジェクト指向の要素をちょっとだけ輸入してみた中途半端なオブジェクト指向言語が次々出ては滅びの興亡続けてたのは
"コンパイル後のサイズが大きいじゃないか"とかいまじゃヘソが茶を沸かすような理由がメインなわけだし。
パターンは機能じゃないよ。設計。
デコレータパターンという設計
この設計の実装はいろいろある。
決まっていない。
Javaだったらクラスで実装し
クロージャーでも実装できるってだけの話。
598: デフォルトの名無しさん [sage] 2016/08/04(木) 00:36:04.52 ID:jTAWnEUa(4/22) AAS
wikipediaにすら書いてあるしｗ
外部ﾘﾝｸ:ja.wikipedia.org
デザインパターンは、よく使われる設計を一般化された形でまとめたものに過ぎない。
そのため、具体的な実装を提供するものではなく、
あくまでもコンセプトとして参照されることが意図されている。
つまり、サンプルコードは、実装例に過ぎない。
601: デフォルトの名無しさん [sage] 2016/08/04(木) 00:45:06.02 ID:jTAWnEUa(5/22) AAS
>>599599(1): デフォルトの名無しさん [sage] 2016/08/04(木) 00:42:01.96 ID:w6fnMNqO(2/4) AAS
>パターンは機能じゃないよ。設計。
それで、その設計パターンとは合致しないけど
同等の機能や目的を満たす他の設計はあり得る
ってことでしょ？
俺の言ってることと一緒だね
わざわざ複雑にしないでいいよｗ
やりたいことがある。
でも説明するのが面倒くさい。
じゃあ「デコレーターパターン」と呼びましょう。
これで話は通じてるじゃん。
だからこれだけの情報でコードを書くことができる。
そのデコレーターパターンを
クロージャーで実装したんでしょ？
そういえば良いんだよ。
602: デフォルトの名無しさん [sage] 2016/08/04(木) 00:48:34.94 ID:jTAWnEUa(6/22) AAS
>>600じゃあ一緒に勉強していきましょう（笑）
外部ﾘﾝｸ:www.techscore.com
> 前章でも説明したとおり、デザインパターンとは、「よく出会う問題とそれにうまく対処するための設計」を
> まとめたものです。 デザインパターンを利用するメリットとして、最初にあげられるのが、
> 「再利用性の高い柔軟な設計ができる」という点です。各パターンには、多くの知恵が凝縮されています。
> これまでは、設計者の直感や経験などに依存していた設計が、デザインパターンを導入することで、
> 初心者でも先人たちが詰め込んだ「知恵」を利用した設計をすることが可能となります。
> また、先人たちの知恵を参考にすることで、設計力の向上も期待できます。
>
> 次のメリットは、「技術者どうしの意思疎通が容易になる」ことが挙げられます。
> デザインパターンを習得している技術者どうしであれば、設計について相談するとき
> 「Singleton パターンで行きましょう」とか「Strategy パターンが応用できるのではないでしょうか」と
> いうようにパターン名で設計の概要の合意を取ることが可能です。デザインパターンを
> 習得していない技術者には「こんなクラスを作って、このクラスはこんな役割を持っていて・・・。」と
> 延々と説明しなければなりません。このように、デザインパターンを学習しておくことで
> 開発者どうしの意思疎通がスムースになるのです。
あなたは何で勉強していますか？
606: デフォルトの名無しさん [sage] 2016/08/04(木) 03:16:53.36 ID:jTAWnEUa(7/22) AAS
やっぱりデザインパターンを
実装パターンと勘違いしているとしか思えないな。
まず大前提としてデザインパターンに言語は関係ない。
だから言語は関係なく設計の話、
オブジェクト指向での設計の話を考える。
そうするとそこにデザインパターンが出てくる
ここまでで言語の話は出てこないから
当然実装の話もでてこないんだよ。
607: デフォルトの名無しさん [sage] 2016/08/04(木) 03:18:24.28 ID:jTAWnEUa(8/22) AAS
OOPじゃなくてC言語でも当てはまる話だよね。
シングルトンやデコレータなどは。
C言語であってもオブジェクト指向で設計していれば
自然とデザインパターンは出てくる。
609: デフォルトの名無しさん [sage] 2016/08/04(木) 09:14:32.03 ID:jTAWnEUa(9/22) AAS
>>608608(1): デフォルトの名無しさん [sage] 2016/08/04(木) 06:27:25.67 ID:iDV12Qqy(2/5) AAS
>>605
だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
JavaやC++の表現力で解決する妥協案を集めたものなの。
JavaやC++の表現能力や抽象度が低いことを勝手にOOPの表現能力の低さにすり替えるな。
それはオレオレ定義ですよね。
612(2): デフォルトの名無しさん [sage] 2016/08/04(木) 09:33:48.07 ID:jTAWnEUa(10/22) AAS
> だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。
じゃあなんでこんな本が存在するんですか？ｗ
Rubyによるデザインパターン-Russ-Olsen/
外部ﾘﾝｸ:www.amazon.co.jp
JavaScriptデザインパターン
外部ﾘﾝｸ:www.oreilly.co.jp
The Design Patterns Smalltalk Companion
外部ﾘﾝｸ:www.amazon.com
616: デフォルトの名無しさん [sage] 2016/08/04(木) 09:38:22.54 ID:jTAWnEUa(11/22) AAS
>>615え？捨て台詞？ｗ
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でクロージャを使った実装で実現できる。
644(1): デフォルトの名無しさん [sage] 2016/08/04(木) 20:41:57.05 ID:jTAWnEUa(14/22) AAS
イテレーターパターンをSmalltalkで書いてみたわけね。
648(1): デフォルトの名無しさん [sage] 2016/08/04(木) 21:15:46.97 ID:jTAWnEUa(15/22) AAS
>>647647(1): デフォルトの名無しさん [sage] 2016/08/04(木) 21:08:55.10 ID:ILqHD9/M(1) AAS
>>642
クロージャを使ったらデコレータとは言わないのでは？
デコレータは継承による多態性を用いたものに限定すべき。
同じ事をやる方法なんていくらでもあるから、
そこは継承によるものと限定しておかないと意味分からなくなる。
無論、今のC++やJava、C#だってクロージャもしくは
それに類似した機能を使って同じ様なことはできるし、
Smalltalkだって継承を使ったデコレーターはできる。
言語によってできることできないことと、
各言語の流儀みたいなものは切り分けて考えるべき。
デコレータの説明として、インターフェイスを同一視して
動的に機能を拡張していくとは書いてあるが
継承を用いることとは書いていない。
650(1): デフォルトの名無しさん [sage] 2016/08/04(木) 21:29:07.85 ID:jTAWnEUa(16/22) AAS
Structureは日本語にしたら
構造って意味ですよｗ
653(1): デフォルトの名無しさん [sage] 2016/08/04(木) 21:34:27.18 ID:jTAWnEUa(17/22) AAS
> そこが実質的な定義だと（俺様が）言ってるの。
知らんがなｗ
お前が何を言ったところで、
Structureは日本語にしたら構造
Definition（定義）じゃない。
まさか単語の意味を強弁するとは思わなかったなｗ
655: デフォルトの名無しさん [sage] 2016/08/04(木) 21:51:04.78 ID:jTAWnEUa(18/22) AAS
説得力0ｗ
657: デフォルトの名無しさん [sage] 2016/08/04(木) 22:03:13.75 ID:jTAWnEUa(19/22) AAS
構造の一例ねｗ
659(1): デフォルトの名無しさん [sage] 2016/08/04(木) 22:12:49.41 ID:jTAWnEUa(20/22) AAS
まさかデザインパターンがGoFの23個だけだと？
あれはパターン例だよ
661: デフォルトの名無しさん [sage] 2016/08/04(木) 22:20:23.44 ID:jTAWnEUa(21/22) AAS
Structureは日本語にしたら構造
Definition（定義）じゃない。
国語と英語の問題なｗ
663: デフォルトの名無しさん [sage] 2016/08/04(木) 22:45:18.74 ID:jTAWnEUa(22/22) AAS
効いてる効いてるｗ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.039s