オブジェクト指向システムの設計 173 [無断転載禁止]©2ch.net

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2017/08/08(火) 17:52:14.38ID:4Kd2O+xB
前スレ
オブジェクト指向システムの設計 172
http://mevius.2ch.net/test/read.cgi/tech/1467992113

類似スレ
手続き型システムの設計 1
http://mevius.2ch.net/test/read.cgi/tech/1500282714
2017/09/19(火) 20:27:42.88ID:6o+b/JQG
>>703
デザインパターンは良く使われてるデザイン、設計をパターン化したものだ
そのデザイン自体は無能でなければどこかしらで使っているだろうが、
パターンとして認識してるかは別だ
2017/09/19(火) 20:32:55.48ID:oRSrnZEU
フレームワークは、デザパタの集積だから、知らず知らず使ってる

フレームワーク製作者は、デザパタの勉強が欠かせないけど、
使う方は、知らなくても使える
2017/09/19(火) 21:38:54.06ID:oUqqEkrK
>>703
singletonはよく使われてる
2017/09/19(火) 21:47:07.15ID:yzSynM5D
>>703
デザパタ自体はあるあるに名前を付けただけだから知ってても知らなくても使ってる。

コードを配置するときに、結果的に○○パターンというのはあるが、逆に、
デザインパターンの中からどれにするか選ぶ、という奴はいないと信じたいが、どうなん？
構造を検討するのならクラス図を直接ホワイトボードに書けばいいだけで、（名前がまるで直感的でないので)
それをわざわざ会議で「ここは○○パターンで行きましょう！」ってのもないと信じたいが、これもどうなん？

というか俺はあの名前を真面目に覚える気にはならない。
あれって、継承/委譲/インタフェース等の組み合わせを全部展開して命名しただけであって、
それより継承/委譲/インタフェースをそれぞれどういう時に使うかをしっかり抑えたほうがいい気がしている。
例えるなら、物理でma=Fとsin/cosで終わるところを、
角度30度の斜面のときは…とか展開して覚えている感があるので気に入らない。
それ以前にクロージャ/関数ポインタ等、もっと使える部品も入ってないし。
というわけで、俺はデザパタはいらない子、と思っている。（使っているが、デザパタとは意識してない）

まあそれ以前に、最近は継承はいらない子、委譲だけでよし、ってのも流行ってるみたいだが。Goとか。
2017/09/19(火) 22:28:41.59ID:1X4lIwJc
>>703
ストラテジーみたいに単純なものは
意識されなくても自然と使われてる
ビジターとか複雑なのはあまり使われてない

デザパタは意識して組まなくてもいいが
一通り学んだ方がいい
「これは○○パターンだな」って分かると
設計するときの土台になるから
2017/09/19(火) 22:29:43.79ID:GKe55KcR
デザインパターンって打つのも億劫か
2017/09/19(火) 22:56:50.66ID:xOoZ3PLO
デザパタは神話
カタログ化こそに異議があるという意見もあるが
それこそ噴飯物
読者のレベルにもよるのはわかってるが
だいたいガバガバ理解ですれ違ってるのを見る
GoFのことかと思えば
GoFのことではなくて独自用語ぶっこんできたりもする
(>>704に見られる「Factoryパターン」であったり)

設計のための勉強に使うと言い切ったほうがまだマシに思える現状
2017/09/19(火) 22:57:09.49ID:xOoZ3PLO
×異議
○意義
2017/09/19(火) 23:07:22.41ID:1X4lIwJc
>>711
>>704は「Factory」だけで意味通じる

GOFの23パターンだと
Factory MethodかAbstract Factoryだけど

そこまで融通が利かなかったから
そりゃ使いにくいだろうけど
2017/09/19(火) 23:15:17.03ID:xOoZ3PLO
断言していいと思うけど

・（いわゆる）ファクトリメソッド
・Factory Methodパターン
・Abstract Factoryパターン

この区別は>>704には無いし
後者二つについての理解は不十分だと思うｗ
デザパタデザパタ言ってみても
早速その辺で深い溝を感じる
2017/09/19(火) 23:28:15.81ID:9ArzpmiB
おい、デザパタ用語使わずに
デザパタの話しろよ
2017/09/19(火) 23:42:04.65ID:yzSynM5D
つまり、方言が多くて意味無いって事か？

俺も、>>704で通じると思う派だが、しかし確かに>>714の3つって何よ？とも思い、確認してみたが、
正直、区別する必要なくね？理解は以下でいいか？

・（いわゆる）ファクトリメソッド＝factory関数をどこかに用意して使う
・Factory Methodパターン＝factory関数をメソッドとして提供する
・Abstract Factoryパターン＝＝factory関数を別クラスに配置する

要するに直newせずにファクトリ呼べ、ってだけで全部同じだが。
俺はデザパタのこの手の無駄に組み合わせ数が爆発してる感が大嫌い。
OOPもそうだが、デザパタもここまできたらデザパタが目的になってる感がある。
2017/09/19(火) 23:51:52.40ID:9ArzpmiB
デザパタはパターンに名前を付けたことに
意義があるというが眉唾

だからデザパタ用語を使わずに
デザパタの会話しろ

できるだろ！
2017/09/19(火) 23:53:38.39ID:xOoZ3PLO
>>716
一部にのみレス返す

・（いわゆる）ファクトリメソッド
インスタンスを返すメソッド
単にメソッドのこと

・Factory Methodパターン
インスタンス化をサブクラスに任せる
サブクラス化時にオーバーライドすることによって
親クラス内部で使ってるインスタンスの一部を置き換える
メソッド、親クラス、派生クラス、という関係性の中にあるパターン

・Abstract Factoryパターン
インスタンス群を作成するファクトリを抽象化する
ファクトリごと置き換えて、インスタンス群を丸ごと置き換えたい時使う
インスタンス群、ファクトリごと、が特徴
こーいうのはクラスライブラリを作って他人に提供しようとしたとき欲しくなるパターン
2017/09/19(火) 23:54:32.93ID:xOoZ3PLO
インスタンスを返すメソッド
↓
インスタンスをnewして返すメソッド

のほうがいいかな
2017/09/20(水) 00:07:15.23ID:fL5PgjM3
>>718
了解した。ｊこれでいいか？
・（いわゆる）ファクトリメソッド＝factory関数は非仮想関数
・Factory Methodパターン＝factory関数は仮想関数でオーバーライドされる
・Abstract Factoryパターン＝数クラスのfactory関数を纏めて抽象化

上2つは区別の必要なし、
下1つはメタ気味だからこれが適切な場合に「ファクトリ」と言えば上2つと混同することはなさそう。
って感じだなあ、俺は。
2017/09/20(水) 00:17:42.90ID:BVH1qyCN
>>707
地獄のstaticおじさんやんけ！
2017/09/20(水) 00:24:55.54ID:fL5PgjM3
ちと補足すると、

・（いわゆる）ファクトリメソッド＝factory関数は非仮想関数
・Factory Methodパターン＝factory関数は仮想関数でオーバーライドされる

この2つが普通に「ファクトリ」と呼ばれるもので、俺は区別する必要が無いと思っている。
これらを使ったクラスが複数合った場合、それらを束ねるために

・Abstract Factoryパターン＝数クラスのfactory関数を纏めて抽象化

が使われると思うので、下から組む場合には、文脈的に混同されることはないはず。
上から組む場合は若干齟齬があるかも。
2017/09/20(水) 00:30:04.30ID:aRa9PEEA
電気回路でも有名なやつには名前がついているものだからなぁ
組み合わせたり改良して使うのだろうから
〜の亜種、ということが多いのかもしれないが
2017/09/20(水) 00:31:45.57ID:LoYhuMpt
関数とメソッドの違いについて
2017/09/20(水) 00:42:43.36ID:lixqcDrr
お前らいつまでデザパタイコールGoFなのw
2017/09/20(水) 01:08:02.93ID:DOSxYj0U
>>699
どっちでやりやすいかは対象のドメインと
モデリングする人間のメンタルモデルによる
例えばDDD本に出てくる経路選択サービスなんかは
関数型の考えでモデリングするほうが自然に思える人が多いんでない？

実装言語としては型の表現力の高さや抽象化のしやすさは重要
F#のUnion TypeみたいのがあるとそれがないScalaでは面倒くささが全く違う
2017/09/20(水) 01:43:57.85ID:NjwKaGnN
ScalaがOOP寄りでF#がFP寄りだから
関数型ならF#の方が組みやすいが

Scalaが選ばれるときは
Javaとの親和性で選ばれる
Java（Web、Android）かWindowsか
2017/09/20(水) 01:47:25.09ID:NjwKaGnN
DDDがOOPの方がやりやすいのは
ビジネスソフトには
状態を持ったモデルが多いから

状態を持たない経路探索なんかは
関数型（論理型）の方が得意だが
全体のサービスの一部なら
マイクロサービスでそこだけ関数型にしてもいい
2017/09/20(水) 09:02:53.40ID:jNWRVYAN
デザインパターンすら書くのも面倒なのか
730デフォルトの名無しさん
垢版 |
2017/09/20(水) 09:18:34.29ID:Ga15J+U7
まっ、デザパタは現場では死言ということがわかった。

簡単なごく当然な（デザパタと言うほどのことはないイテレーターとかコマンドとかファクトリメソッドとか・・・）

パターンは自然と使われているということね。

みなさん、サンクス。
731デフォルトの名無しさん
垢版 |
2017/09/20(水) 09:19:40.96ID:Ga15J+U7
× 死言
〇 死語
2017/09/20(水) 09:21:37.84ID:qH6V6v7k
×　\r\r
〇 \r
2017/09/20(水) 10:43:59.15ID:yYGRyM8i
Iterator パターンは、イテレータを提供するパターンだぞ
独自のデータ構造なんかを作った際に、それを辿れるようなイテレータを提供すること

既にあるイテレータを使ってるからといって
Iterator パターンを使ってるのとは違う
設計することと、設計されたものを使うことは違う
Iterator パターンを使って設計するのと、そのイテレータを使うことは違う

デザパタへの誤解は仕方ない
必要になるまでは分からないだろうから
設計の立場に立つまでは分からないだろう
ならばせめて
必要になるまではせめて語らないでほしい
2017/09/20(水) 11:18:37.43ID:qH6V6v7k
イテレーターがプログラム機能として初めから無い言語が無くなってきたから
パターンを意識しなくてよくなったんだよな。
2017/09/20(水) 11:40:51.15ID:yYGRyM8i
そう、その言い方が正しい
2017/09/20(水) 12:46:50.80ID:DYqQfVY4
使う側も含めてのパトゥーンだろ
2017/09/20(水) 19:13:16.31ID:NjwKaGnN
イテレータが言語にあるから
もうデザパタいらない
って考えは非常に短絡的だと思う

それだと言語に標準である
配列のイテレータとか以外で
独自のデータ構造を走査するとき
とたんにゴチャゴチャになる
2017/09/20(水) 20:04:03.57ID:fL5PgjM3
>>733
> 設計の立場に立つまでは分からないだろう
> ならばせめて
> 必要になるまではせめて語らないでほしい
多分ここが間違っていて、というよりはポリシーの違いだが、
君の職場は「設計」と「コーダー」が完全に分離していて、「コーダー」にはデザパタの知識は必要ないのか？
俺が知っている限り、設計とコーダーの分離は失敗だったと聞いているが。

そもそも設計において必要なのは「外部インタフェースの固定」だ。これは
・（いわゆる）ファクトリメソッド(A)
・Factory Methodパターン(B)
・Abstract Factoryパターン(C)
として、(A)→(B)の場合には外部（使う側）のソースコードの改変は全く必要ないし、
(B)→（C)にアップグレードする場合も正しく隠蔽されていれば同様だ。
中身を見せていれば(B)→(C)時にダウンキャストが必要になるが、これはそもそも設計が悪いし、
それでもラップすれば、外部ソースは改変無しで保てる。
だから使う側からすると「ファクトリを必ず呼ぶ」ことを徹底すればそれでよく、
中身が(A)(B)(C)のどれでも関係なく、クラス担当者が最適なものを選べ、でしか無いと思うが。
最悪駄目駄目なら差し替えればいいだけだし。本来これが隠蔽のメリットだろうに。

>>737
いらんだろ。イテレータ自体、
・走査を begin(), next(), end() と抽象化すれば実装によって異なる走査が必要でも隠蔽できます
なんだし、言語側のイテレータもこれとインタフェース合わせてあるし。
同じ思想を2度学んでも意味が無い。
仮にデザパタがGoF以外の100人から提唱されているとして、それぞれ微妙に方言があり、
「○○のデザパタでは△△のことをこう呼びます」ってのを色々覚えても意味無いだろ。
デザパタのイテレータパターンと言語のイテレータ」は違います！ってのは俺にはこう見える。
どうでもいいことにこだわりすぎだ。
2017/09/20(水) 21:01:08.70ID:NjwKaGnN
>>738
いやいるだろ
言語と設計（思想）が分離する

「外部インタフェースの固定」が有効なのはいいが
そういうのもイテレータとかデザパタから学んでいく
2017/09/20(水) 21:12:23.35ID:8N1Ug+q3
お？アランケイは終わったのか？
どの辺りのレス番から再開すればいんだ
2017/09/20(水) 21:21:18.96ID:V1jqjPnq
便所の落書きに永続性を求めてはいかんw
2017/09/20(水) 21:28:11.72ID:fL5PgjM3
>>739
いる/いらないの言い合いは意味無いが、やっぱり俺は区別の必要は無いと思うぞ。
「言語のイテレータ」は「デザパタのイテレーターパターン」を言語側に取り入れた機能であり、
「言語のイテレータ」を正しく使える＝「デザパタのイテレーターパターン」を正しく使える、となるから、
別に学ぶ必要はない。

言語と設計(思想)の分離と言うのは、例えば依存性逆転の法則(DI)等であって、
これは言語とはまったく無関係だから、どの言語でも使えるし、また、使わなくとも実装可能だ。
とはいえこれも、例えばフレームワークは基本的にDI的であるので、
フレームワークを正しく使うようにすれば自然と身に付く。
(フレームワークに沿って記述することが必要であり、これはプチDI）

上達を登山に例えれば、デザパタは一つの登山道であるが、それ以外のルートもあるということ。
どれが効率がいいのかは知らんが、
少なくともデザパタを通らないと頂上にたどり着けない、って事はない。
本来デザパタの目的はこの「上達への最短ルートの開発」だったはずだが、
GoFからして冗長で暴走気味だと思うよ。
2017/09/20(水) 21:42:10.80ID:IJ0bOnfP
DIP=Dependency Inversion Principle
DI=Dependency Injection
2017/09/20(水) 21:48:59.10ID:lixqcDrr
>>742
イテレータの本質はコレクションとアルゴリズムの分離だから学ぶ意味はあるよ
イテレータのことをコレクションを走査するインタフェースとしか捉えないなら、いまや大抵の言語でサポートされてるから使い方だけ知ってればいいけど
2017/09/20(水) 21:58:17.38ID:NjwKaGnN
>>742
＞「言語のイテレータ」を正しく使える＝
＞「デザパタのイテレーターパターン」を正しく使える
ならないって

たんにループ文の代わりに使ってるだけだと
言語でサポートしてない部分になった途端に
分からない、出来ないゆとりになる

ただ使うだけでなく仕組みを知る必要があるが
仕組みを学ぶにはデザインパターンが有効
2017/09/20(水) 22:01:51.52ID:NjwKaGnN
言語やフレームワークを使ってれば
パターンが自然と身につくってのは大いに疑問

OOP言語のJava使ってても
中身は手続き型で書いてるケースがよくある

自然と身につくのは道具の使い方だけで
パラダイムは意識的に学習しないと分からない
2017/09/20(水) 22:04:20.27ID:FueCi3Km
いいんだよ
そんなのどうせ金にならねぇから
工数が決まっちまった後の話に力を入れるな
2017/09/20(水) 22:21:45.45ID:fL5PgjM3
>>746
本人に学ぶ気があれば、使っていれば身につくんだよ。
お前は日本語を学んで上達したのか？違うだろ。使って上達したんだよ。

もっと分かりやすい例で言うと、ギャグだな。
「鉄板」「お約束」「乗り突っ込み」等のデザパタはあるが、
これらをデザパタとして学ばないと「乗り突っ込み」出来ないのか？
違うだろ。使ってるのを見て学んだんだよ。
（トンキンでは学ぶのかもしれないが、関西人のは地だぞあれは。
「ふーん、で、オチは？」という環境にいるから自然と身につくんだよ）
2017/09/20(水) 22:24:58.78ID:DOSxYj0U
用意されたイテレータを使うだけの人と
イテレータやジェネレータを自分で作って使える人とでは
力にかなりの差があるのでパターンとして学ぶことの意義はあると思うけどな
2017/09/20(水) 22:51:24.28ID:lixqcDrr
>>748
オブジェクト指向設計は学ばなくても使ってれば身に付くという思想なら、そもそもこのスレに何しに来てんの？お喋り？自分の考えを聞いてほしくて？
2017/09/20(水) 22:59:41.30ID:NjwKaGnN
>>748
＞日本語を学んで上達
日本語は母語だから自然と上達するが
英語だと学ばないとカタコトのまま
数学だとさらに意識的な学習が必要

プログラミング言語は英語や数学に近い
意識的に学習しないと上達しない
2017/09/20(水) 23:01:29.19ID:NjwKaGnN
>>749
まさに要点はそこだね
使うだけの人になるよな

使うだけなら慣れれば十分だが
作る人になるには学ぶ必要がある
2017/09/20(水) 23:06:42.94ID:fL5PgjM3
>>750
むしろお前は何しに来てんだ？
デザパタ学べば上達するなら、本なりサイトでも読めばいいではないか。
2017/09/20(水) 23:14:19.88ID:fL5PgjM3
>>751
× > 英語だと学ばないとカタコトのまま
○　英語は使わないとカタコトのまま
これはほぼ通説だぞ。むしろ俺の説を補強してどうする？

学ぶ＝イメトレであって、それは上達を早める方法ではあるが、
学ぶだけでは上達しないんだよ。使わないといけない。
もちろん使ってさえいれば上達するか？と言えばそうじゃない。
日本人内でも文章の上手下手があるように、いろいろ意識して使って無いと駄目だ。
いわゆる職人気質だよ。今よりも上を常に求めているか？ということ。
2017/09/20(水) 23:16:09.78ID:VBPZEd03
デザパタは名前が付いてることが大事なんだよ
その一言で共通認識ができる

こんな基礎もわからん馬鹿がデザパタはいらないキリッ
とかいいながらペチプァ〜でウンコードモリモリ大将軍してるんだろ？
PHPと共に死んで欲しいね
2017/09/20(水) 23:19:26.12ID:NjwKaGnN
>>754
＞英語は使わないとカタコトのまま
違う、もちろん実際に使わないで
座学だけではダメだが
発音は意識して学ばないと
いくら使っててもカタコトのままというのが定説
2017/09/20(水) 23:30:17.48ID:VBPZEd03
おい聞いてるのかペチプァ
単価最底辺の土方ども
生きてるだけ無駄なんだよ屑が
今すぐ死ねよ！
2017/09/20(水) 23:45:01.20ID:VZIyuCp2
>>756
英語は使わないとカタコトのまま
ということは否定するんですよね？
2017/09/20(水) 23:50:15.80ID:fL5PgjM3
>>756
もう完全に脱線しているが、さらに続けると、

> 発音は意識して学ばないと
> いくら使っててもカタコトのままというのが定説
これは正確ではない。
一般日本人について、確かに君の上記意見は当てはまる。
しかしこれはエラーをフィードバックする「耳が無い」からであって、
逆に言えば「耳がある」人は意識して学ぶ必要はない。例えばネイティブの幼児とかがそうだ。

脳科学的に、確か聴覚は幼児期に発達して、そのまま終わりだったはず。
それで俺たちはLとRが聞き分けられない耳になってしまって、結果、LとRの発音が出来なくなる。
これは、先天的聴覚障害者がアーウーとしか言えず、正しく発音ができない（滑舌が著しく悪い）ことからもわかる。
聴覚障害は口蓋の障害ではないのに正しく発音できないのは、
自分の発音が聞こえず、正しく発音できていないことを認識して修正できないから。
（分かりやすく言えば、噛んだことが分からないから）

英語についていえば、LとRの違いがわかる耳があれば、明らかに違う（らしい）のであっさり上達する。
(むしろ、何でこれが聞き分けられないの？と不思議らしい）
俺らみたいに、「耳がない」人が「正しい発音」をする為には、
俺らも聴覚障害者と同様に、正しい発音をする為の口や舌の動きを意識しないと上達しない、というだけ。

だからまあ、エラーをフィードバックできれば自己学習で上達はする、ということにはなる。
つまり自分で書いた糞コードが糞だと認識できれば、上達する、とも言える。
2017/09/20(水) 23:58:32.97ID:DOSxYj0U
イテレータをパターンとして学ぶ価値があるかどうかから
パターンそのものの価値があるかどうかに話変わってるよね
んでもって、その英語の話はもうパターン関係なくなってる
2017/09/20(水) 23:59:45.04ID:DOSxYj0U
もしLとRを聞き分けられるようになる<LRパターン>があるとしたら
パターンを学んだやつのほうが学習効率が高く上達が早いわけだ

そのパターンを知らないやつ独学でいくら努力しても
いつまでたってもLとRが聞き分けられない可能性もある

無理やりパターンにつなげるとだけど。
2017/09/21(木) 00:11:32.59ID:F/cUryZs
>>760
そうじゃない。

自分のコードが糞だと認識する為には、逆に、良いコードならこんな感じになるはず、と想像できる必要がある。
当然、あらかじめ「良いコード」を知っておく必要がある。
だからコードリーディングも同様に上達の手法ではある。これもよく言われてるだろ。

もちろんデザパタ学習も上達の方法だし、やればいい。
ただ、頻出パターンならコードリーディングでも当然遭遇するし、>>704はそういうことなんだよ。
だから>>704が理解出来ない＝OSSを使ってない、コードリーディングしてない、ということ。
どっちが上達が早いのかは知らん。両方やるのがベストなのだろうが。
デザパタ学習が唯一の道ではない。
2017/09/21(木) 00:14:31.04ID:ijaAIW4i
>>758
英語は使わないとカタコトのまま
英語は学ばないとカタコトのまま

上の両方を肯定する
「使ってれば学ばなくても自然と覚える」
という片方だけを否定することを否定する
2017/09/21(木) 00:17:36.42ID:ijaAIW4i
>>759
クリティカルエイジ以前の幼児が
英語を自然と身につけるのは知ってる

プログラムの話に戻ると
幼児の頃からプログラミングしていた
奴なら自然と身につくかもしれないが
一般人については意識して学ぶべき
2017/09/21(木) 00:18:52.78ID:EmOs9oCs
内部がどんな実装か知ってる必要ないね
使い捨ての土方なら
2017/09/21(木) 00:28:25.80ID:F/cUryZs
>>764
俺が否定しているのは、君らが学びの方法が唯一デザパタ学習だと信じていることだ。
これは明らかに間違いで、>>762の通り。コードリーディングでもデザパタは身につく。
OOP信者と同様、デザパタ信者もまた、視野狭窄だ。
2017/09/21(木) 00:35:05.01ID:ijaAIW4i
>>766
もちろん唯一の道じゃないけど
コードリーディングだけで
デザインパターンを身につけるのは効率が悪い

あらかじめパターンを知ってて
「これは○○パターンだな」っていう方が
圧倒的に上達が早い
2017/09/21(木) 00:50:20.24ID:n0XifzBg
時間の無駄になる相手に
レスを返しては行けない

分かる人だけ守って欲しい
自分の時間を守って欲しい
2017/09/21(木) 00:59:26.34ID:K0No9bcT
>>762
何がそうじゃないのかわからんのだがww

今度は「デザパタ学習が唯一の道ではない」に主張を変えたのか
その主張なら誰も否定しないだろね
最初からデザパタ学習が唯一の道なんて言ってる人いないから
2017/09/21(木) 01:08:43.31ID:N1EOCCyb
デザパタとリアルで言っても大丈夫でしょうか？
2017/09/21(木) 01:40:52.00ID:QBtXCTqk
>>770
いやー、やめとけ
2017/09/21(木) 01:43:18.55ID:F/cUryZs
>>767
君がそう思うのならそれでいい。
ただ事実として言えるのは、「デザパタ」は頻出パターンであり、当然他でも言及されてるんだよ。

例えばファクトリー、以下はJavaScriptの例だが、クロージャの部分でさらっと出てくる。
ただしJavaScriptの場合はクロージャを生成する為にファクトリーを積極的に使う理由があり、GoFの範囲を超えている。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Closures
もちろんイテレータはプログラミング言語C++の中でハゲが力説しているし、
ストラテジーについては継承まんまだろ。OOP言語なら確実に説明されてる。

各言語機能も、作った側は「こう使って欲しい」ってのがあるから、それぞれ力説されてる。
(K&Rはあまりにも淡々としすぎているが)
だから頻出パターンならいい教科書で各言語機能を学べば自然と目にしてる。
そして文法は学ぶ必要があるから、これらは読むしかない。
その後にデザパタを見ても、頻出パターンは確実に重複するんだよ。
そしてどうでもいいパターンを学ぶ意味はないし。

デザパタは結局頻出パターンだから、学ぶ気があればどの方法でも自然と身につく。
コードリーディングでも、教科書を読んでも。
「デザパタ自体を学習せねば！色々初めて見るし！」と思ったのなら、それは君らが普段からあれこれ見落としているだけ。
デザパタなんてそこかしこに転がっている。いちいち言及されてないけど。
だから本来はわざわざ別に学習しなければならない物でもないのさ。
2017/09/21(木) 02:03:32.34ID:2yneGSNP
>>772
> 文法は学ぶ必要があるから、これらは読むしかない。

文法はコード書いたり読んだりしてれば自然と身につくよ
日本語の文法を学ばない人に日本語は使えないかというとそうじゃないだろ？
教科書を読むのが文法を学ぶ唯一の方法だと思ったら大間違いだよ

はい、これがお前的反論パターンw
2017/09/21(木) 02:29:40.61ID:q11aClZE
ハロパタ
2017/09/21(木) 02:35:36.57ID:ijaAIW4i
>>772
上から目線で捉えていることは
無条件で正しいとでも思ってるのかな
「君がそう思うのならそれでいい」が

GOFの23パタをすべて習得してるのは当然の前提として
GOF以外のデザパタもあるし
GOFの23パタからアレンジしたものもある

日本ではマイナーなものもある
Null Objectなんかは最近浸透してきたが
Type ObjectとかExtension Objectとか他にも色々ある

またイテレータと同様に
ビジターにも内部／外部があるとか
関数型やジェネリックの書き方があるとか
発展的なトピックもある

だからデザパタ単体で学習した方が整理される
言語を学んでいるときはパターンより文法に
コードリーディングしてるときは
実装のテクニックに目が行きがちだしね
776デフォルトの名無しさん
垢版 |
2017/09/21(木) 05:42:15.46ID:eSaSp7RC
みなさん、ほんとうにデザパタを使っているんですか？

簡単な分かり易いものは使っているんでしょうが、これぞっていうパターンを
使っている人このスレに居ますか？

大手企業のパッケージ開発やフレームワーク開発に従事している秀才プログラマー
が使っているのは度々見ましたが、中階層、低階層の現場では見たことありません。

ちなみに我輩はしがない流れ者の派遣プログラマー（プログラム設計もやってます）です。
2017/09/21(木) 06:50:22.15ID:aDCr5zcn
アルカンシェルパターンはよく使ってるね
最強のパフォーマンスを目指す選ばれた者だけが行使することを許された神ーGODーの力
2017/09/21(木) 07:20:26.51ID:QBtXCTqk
>>776
使ってねぇって言ってるだろハゲ
2017/09/21(木) 07:51:05.32ID:xOLq2+H5
>>776
http://www.techscore.com/tech/DesignPattern/index.html/
適当にググって出て来たここに紹介されてる奴を眺めて思い返してみたけど、ほぼ全部使ってるわ
もちろん、これはナントカパターンだ赤ペン先生でやったぞ！ってモロに意識しながら使うと言うよりか、いつも書いてるあのコードってカタログから選ぶとこのパターンだなって感じ
2017/09/21(木) 09:12:15.36ID:Xs4LibNR
>>771
やっぱりそうですよね
普通にデザインパターンって言いますよね
うっかりデザパタとか言わないように気を付けます
2017/09/21(木) 15:56:35.21ID:EmOs9oCs
>>776
GUIで使われるようなものはwebだと使う機会なかったりするし
無理に使うようなものじゃない

GoFのデザインパターンは共通認識としての意味合いが強いから
勉強しとかないと話にならない
2017/09/21(木) 16:00:36.62ID:QBtXCTqk
>>781
はぁ？
一度も使ったことねーけど？ｗ
2017/09/21(木) 18:57:33.91ID:jvulp0iD
パターンハラスメント
2017/09/21(木) 19:07:59.73ID:EmOs9oCs
>>782
毎回長々と説明してるのか
生産性の低い環境でやってるんだな
2017/09/21(木) 19:29:18.74ID:ffbJfIAO
デザインパターンなんてゆとりには通じないよ
ゆとりはif文とforループしか理解できない
彼らとのコミュニケーションは全て懇切丁寧に一から説明しないといけない
そして彼らはそれが当たり前だと思っている
甘やかされて育った人間があれほど厄介な生き物になるとは思わなかった
違う生き物と話しているようで辛い
2017/09/21(木) 20:01:30.88ID:0x00hAVC
デザパタの分かる年寄りより
分からない若いのを雇うのがIT土建屋
2017/09/21(木) 20:13:18.07ID:EmOs9oCs
>>786
若いから安く買えて
工数かかるから高く売れるんだな
サビ残人身売買
2017/09/21(木) 20:18:00.45ID:ffbJfIAO
使い潰してもいくらでも捕獲できるし便利っちゃ便利だわな
2017/09/21(木) 20:18:42.03ID:N1EOCCyb
デザインパターン
2017/09/21(木) 21:59:15.38ID:F/cUryZs
>>775
なんだゆとりか。

つか、君は結局何が言いたいんだ？
> 圧倒的に上達が早い (>>767)
については、俺は既に
> どっちが上達が早いのかは知らん。 (>>762)
と言っているんだから、平行線だし、ここの議論では結論は出ない。
各自が各々の考えを主張できるだけだ。
君がそう思うのなら、君はそうすればいいだけ。俺はそうは思わないから、俺はそうしない。
それ以上でも以下でもないだろ。勝手に切れるゆとりは多いが。

> コードリーディングしてるときは
> 実装のテクニックに目が行きがちだしね
それは君がそうだってだけ。自覚できているのなら、そうならないように気をつけながら読めばいいだけ。

>>785
ゆとりが糞なことについては同意。
てかまじで、>>775とか何が言いたいのか分からん。
同意してくれなきゃヤダってゴネてるのか？としか。
よく見かけるけどね、このパターン。
2017/09/21(木) 22:05:21.29ID:QBtXCTqk
デザパタなんて使わねーよ
2017/09/21(木) 22:53:56.69ID:1e+K8/4+
>>791
使ってることに気づいていないクズ
2017/09/21(木) 23:13:46.19ID:F/cUryZs
>>776
何でもそうだが、デザパタもやりすぎたら手段が目的化するんだよ。>>775とか。
言われてみれば使ってるっていう、>>779位がちょうどいい頃合だと思うよ。

何が問題って、GoF自体が古いからではあるが、今ならもっと単純にできるものが大量に有って、
というかGoFの時点で既にアクロバティック気味で、何がやりたいんだこいつらは？って感じなんだよ。
名前も厨二過ぎてイミフだし。
結局はOOPの文法の全ての組み合わせから、あるあるに厨二な名前をつけただけ、っていう。
例えばコンテナ等でお約束的に使われる「型消去」だが、GoFにはないだろ。
（見落としかもしれんが、それなら「型消去」と直感的な名称の方が断然良いからGoFが使われないだけ）
だからWikiにも書いてある通り、俺は
> デザインパターンをむやみに適用するのは不適切であり、不適切な使用はコードの複雑さを無意味に高めてしまうと注意している。
> 一部のデザインパターンは、プログラミング言語（例: Java, C++）の機能の欠損の印であると主張されることがある。
の側面もかなりあると思うよ。
2017/09/21(木) 23:14:03.96ID:F/cUryZs
>>776(続き）
ただ、使ってる/使ってないと言えば、それは確実に使っている。
既に言ったがストラテジーは継承そのものだから、OOPならほぼ間違いなく使うし、
オブザーバーってのはフレームワークのイベントモデルがこれ(.NETとHTMLはそう）なので、
例えばC#やJavaScriptにおいてこれを使ってないというのはありえない。（自覚しているかどうかは別）
なおJavaScriptはこれを言語自体にも取り込もうとしたが、いいところまで行って頓挫した。
https://www.html5rocks.com/ja/tutorials/es7/observe/
本当に頻出なら言語で直接サポートした方が便利だから、そうなって行くものなんだよ。
それがイテレータであってね。
だから、この類の「言語新機能」を追いかけていても、頻出パターンについては自然と学習することになる。
GoFは1995だし、それからソフトウェア工学も進歩しなかったわけではない。（Javaは10年間進歩しなかったが）
新しい言語は分かりきっている問題に対しては対策をしてくる。
そしてGoは「継承はいらない」という彼らなりの結論を出してる。
GoFなんて古典を妄信するより、Goが何故こういう結論を出したのか考えるほうがいいと思うぞ。

> ちなみに我輩はしがない流れ者の派遣プログラマー（プログラム設計もやってます）です。
君がここら辺の話について来れないのなら、とりあえずまず読んでみろ、ではある。
それでどう思うかは君の自由だ。

多分結局は適性なんだよ。パターンから選ぶほうが楽なら積極的に使えばいい。
俺にはデザパタは粒度が大きすぎる。自分で継承/匿名関数等を使って組み上げるほうが楽だ。（というより直感的）
ただし結果的には同じようなことになっているとも思うが。
2017/09/21(木) 23:55:29.08ID:2yneGSNP
ストラテジーが継承そのものってどういう意味？

HTMLのイベントモデルがオブザーバーってどういうこと？
2017/09/22(金) 00:00:17.04ID:kB3Gqsn3
>>794
> そしてGoは「継承はいらない」という彼らなりの結論を出してる。
> GoFなんて古典を妄信するより、Goが何故こういう結論を出したのか考えるほうがいいと思うぞ。

いまでもGoFを学ぶ意味があると言うと、盲信してることにされちゃうんだね
ということは、Goの出した結論をGoを指示する人は盲信してるの？

まぁGoが正しいわけじゃないし、SwiftやScalaが出した答えも考える価値があるね
2017/09/22(金) 00:31:51.44ID:sr7lvu8c
>>796
> まぁGoが正しいわけじゃないし、SwiftやScalaが出した答えも考える価値があるね
その通りだ。俺は自分で考えろと言っているだけだ。

GoFが古いのは事実だ。
その間にソフトウェア工学が進歩していると仮定するなら、当然問題は解決されてくる。
実際そうなっているわけでね。
メジャー言語では、Javaは例外的に全く進歩してないが、
他言語(C++/C#/JavaScript)はなんだかんだで色々試行しているよ。

俺自身、継承はちょっと結合が強すぎるとは感じる。
ただ全部委譲の方がいいか？と言われれば、どうかな？とも思うが。
とはいえ、「全部委譲でよし、継承イラネ」ってのは2chでも散見されるだろ。

で、君はSwiftやScalaを知っているんだろ？それはどうなっているんだ？
2017/09/22(金) 00:32:11.77ID:Nn2M/THg
>>794
> そしてGoは「継承はいらない」という彼らなりの結論を出してる。
> GoFなんて古典を妄信するより、Goが何故こういう結論を出したのか考えるほうがいいと思うぞ。

継承という文法がなくても
継承を別の方法で実装できるからでしょ？

「継承はいらない」ではなく「継承を直接行うための文法はいらない」が正しい
そしてGoでも継承自体はやる。
2017/09/22(金) 00:38:17.90ID:9s7VGfiV
ほんと、ストラテジーが継承そのものってどういうことよ？？
最近はOOでも関数を渡せる言語が増えてきたから
ストラテジーの実装は継承使わないほうが多いと思うぞ

古臭いGoFをそのまま学ぶ必要はないだろうが
単に各パターンを知る・使えるようになることよりも
パターンを通してOOの設計原則を学ぶことが重要
2017/09/22(金) 09:48:55.51ID:eeRMTLx0
アラン・ケイやGoFのデザパタに触れるとスレが荒れるということは分かった
2017/09/22(金) 11:19:40.04ID:b6yHr9//
名前がついてるものの中でも
クイックソートやB+Tree、線形補完でスレが荒れるなど聞いたことないし
やはり何か根本的に微妙なんだろうな
2017/09/22(金) 12:09:12.17ID:z4GP1i1k
良し悪しを証明出来ないからだろう
アルゴリズムのオーダーとかなら数学で証明できるから議論の余地がない
数学的に曖昧なものほどバカでも議論に入る余地があるから調子乗って参加しちゃう
こういう議論でしか話せないんだよバカは
2017/09/22(金) 12:52:53.21ID:gDV2cvxW
クイックソートでも再帰を使えないアホウが発狂するぞ
どんなネタでも発狂するキチガイは存在する
2017/09/22(金) 14:02:03.76ID:juWn7/fD
再帰なんてわかんなかったら繰り返しになるまでコード書いて見ればいい
繰り返し部分を関数にすれば作成完了だ

しかし、スタックオーバーフローで死ぬ
ここまでがワンセンテンスだ
2017/09/22(金) 14:30:09.14ID:b6yHr9//
要は名前を付けるほどの物でも無かったんじゃね、説
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況