オブジェクト指向システムの設計 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(火) 00:26:06.13ID:H6eyWyRr
>>651
意味がわかんない
どう仕様変更されるかもわからないのにそんな言葉出しちゃう時点で
テメーはクソだから発言しなくていいよ
2017/09/19(火) 00:27:06.08ID:yzSynM5D
>>639
ああすまん、俺が言っているのは「スニペット」と言うのかもしれん。
（俺自身はあの機能は嫌いだから使ってないが、たぶん意味的にはこれ）

モジュールというよりは「お約束的コード」の塊を持っておき、
それをベースにその都度必要なら改変して使う、って奴。
それで使えると判明したら「お約束的コード」に新しい機能を取り込む。
JavaScriptはGUIの装飾が主だから、割とこんな感じのほうが上手く行く気がする。
2017/09/19(火) 00:27:42.18ID:stFT2Xr6
>>649
関数型も完璧すぎるC言語に対抗するためのマーケティングと捉えてる？
2017/09/19(火) 00:29:49.11ID:H6eyWyRr
>>654
名前なんかなんでもいいんだろ
言語と必要であれば設計手法も付けて売り出せれば本当になんでもいいんだと思うよ
2017/09/19(火) 00:30:54.19ID:stFT2Xr6
>>652
え、どう仕様変更されるかわからないからって仕様変更への対応しやすさはまったくの度外視でシステム作っちゃうのお前
2017/09/19(火) 00:32:11.91ID:stFT2Xr6
>>655
構造化もマーケティング、手続きもマーケティング、さあどこまで遡ればマーケティングと無縁の世界、お前の桃源郷に辿り着くんでしょうかw
2017/09/19(火) 00:34:11.72ID:9ArzpmiB
>>645
> そもそもなぜここまでメリットの説明できないものを
> 効果がありそうに言うの？

メリットというか、人間のメンタルモデルに一番マッチしてるから
使いやすいってだけだよ

小学校入学前の子供であっても、車という種類（クラス）があって
白い車、黒い車、なんて属性（プロパティ）や
走る、止まる、曲がる、なんて処理（メソッド）が
車に紐付いてるって理解してるだろ？

なんかその道のプロは、オブジェクト指向の真のメリットは
継承やカプセル化や多態性とか言ってるけど、
それはオブジェクト指向の応用でできることであって、
オブジェクト指向はわかりやすいっていうのが
（メリットではなく）特徴
2017/09/19(火) 00:35:21.48ID:H6eyWyRr
>>657
ちゃんと見定めればいいんじゃないかな？
役に立つものと立たないものを
2017/09/19(火) 00:38:39.43ID:9ArzpmiB
>>656
> え、どう仕様変更されるかわからないからって仕様変更への対応しやすさはまったくの度外視でシステム作っちゃうのお前

仕様変更に対応しやすくするために必要なのは、
コードを書かないこと。これはオブジェクト指向とは関係ない。
コード量が少なければ、仕様変更で書き換えるコードも少なくなる。

オブジェクト指向的にはモジュールを抽象化して、拡張性を持たせることだろうが
それは過剰な設計になって複雑さが増すだけで無駄になることが多い。

最初に作り込むのをやめて、最低限動くコードを書くのが良い。
これもオブジェクト指向とは関係ない話
2017/09/19(火) 00:40:09.40ID:m+YtWxtc
プロトタイプ開発
2017/09/19(火) 00:40:23.37ID:6o+b/JQG
>>652
仕様変更はユーザーの既知の言葉でなされる
2017/09/19(火) 00:41:58.60ID:9ArzpmiB
ユーザーの既知の言葉はオブジェクト指向ではない
2017/09/19(火) 00:47:42.06ID:stFT2Xr6
>>659
オブジェクト指向は役に立つね
2017/09/19(火) 00:48:50.65ID:H6eyWyRr
>>664
お前、ミソが腐ってるからな
2017/09/19(火) 00:53:31.47ID:m+YtWxtc
>>665
お前、性根が腐ってるからな
2017/09/19(火) 00:54:13.00ID:stFT2Xr6
>>660
オブジェクト指向と関係ないか
じゃあどんな設計手法となら関係ある？手続き型も関数型も、再利用のしやすさ、仕様変更への対応のしやすさとはまったくの無関係？
どんな設計手法を取ろうと、仕様変更への対応はまったく同じだけのコストがかかる？
2017/09/19(火) 01:00:45.76ID:6o+b/JQG
>>663
ユーザーの既知の言葉をクラス化したと言ったはずだが
お前には何もできないね
2017/09/19(火) 01:03:40.84ID:9ArzpmiB
>>667
> じゃあどんな設計手法となら関係ある

どんな設計手法とも関係ない。
例えば仕様変更に備えて既存のコードを読みやすくするために
わかりやすい変数名をつけることは、どの設計手法とは関係あるか？と
聞かれてお前、なんて答える？

そういうレベルの話

> どんな設計手法を取ろうと、仕様変更への対応はまったく同じだけのコストがかかる？
場合による。どれが最高とかはない。銀の弾丸はないのだよ君
2017/09/19(火) 01:05:01.44ID:9ArzpmiB
>>668
ユーザーの既知の言葉には
動詞もあるはずだが、それもクラスにしたのか？
2017/09/19(火) 01:08:32.48ID:6o+b/JQG
>>670
動詞はクラスのメソッドだろ
基本くらい勉強してこい
2017/09/19(火) 01:09:31.94ID:9ArzpmiB
ユーザーの既知の言葉をクラス化したというが
じゃあオブジェクト指向以外ではできないと思うのか？

理由はクラスが無いからできないと思ってる？
関数しか無いからユーザーの既知の言葉は関数になると思ってる？

違うな。C言語で作られたLinuxでも見ればわかるだろう。
他の手法ではモジュール（またはファイル）になるんだよ
2017/09/19(火) 01:23:49.02ID:yzSynM5D
まあバトるのはいいと思うけど、結局のところsmalltalkの話と似たような事になっていて、

・smalltalkが「遅延結合」で実現しようとしたことは、現在は他の手法で十二分に達成されており、
わざわざsmalltalkを用いる必要はない
・OOPのメリットは、現在では他の手法でも得られるため、OOPに頼る必然性はない。

だからメリットが見えないのなら使わなければいいだけ。
JavaScriptとかの状況だと、OOPで書いてもあまりメリットないのは事実だし。
2017/09/19(火) 01:32:29.64ID:y3g67zRP
ID:H6eyWyRr

完全なるガイジ
こういうのが現場に一匹でも紛れ込んでいたら
さぞ迷惑だろうな
2017/09/19(火) 01:35:21.15ID:6o+b/JQG
>>672
それはオブジェクト指向言語でないとできないかという話か?
設計の話をしてんだよ
できるしgtkとかC言語でオブジェクト指向設計で組んだプログラムもある
オブジェクト単位で分けたならオブジェクト指向設計だし、そうでないなら他の設計だろ

モジュールはオブジェクトだったり機能分割だったりより包括的な言葉だ
お前の言っていることは間違えてる
2017/09/19(火) 01:49:41.82ID:9ArzpmiB
結局さ、オブジェクト指向が生きるのは実装の話なんだよね。
言語より外に出ないでほしい。
2017/09/19(火) 02:07:01.99ID:OkajuEzq
オブジェクト指向言語で実装しやすいように設計したり
オブジェクト指向言語で実装した場合に後でメンテナンスが楽になるように設計するのが
オブジェクト指向設計じゃろ？
2017/09/19(火) 02:07:22.02ID:6o+b/JQG
弁解せずに話し飛ばして逃げたか
ID:9ArzpmiBが恥を晒すだけのスレになってしまったな
2017/09/19(火) 02:13:40.15ID:NMSJB/uW
「オブジェクト指向」って言葉自体、色んな意味で使われて混乱の元になっていたのは事実だわな。
最近の本では
「オブジェクト指向でなぜつくるのか」
がそのあたりの状況も含めてすっきり整理して分かりやすかった。

とりあえず
「オブジェクト指向プログラミング」
「オブジェクト指向設計」
「オブジェクト指向分析」
はきっちり分けて会話しないとますます混乱するな。
2017/09/19(火) 02:38:22.83ID:9ArzpmiB
>>678
それについて弁解しろと？
2017/09/19(火) 02:45:40.97ID:OkajuEzq
>>678
横レスだが君のレスのほうが普通におかしいよ

>まともに作ったオブジェクト指向プログラムでは
>ユーザーの既知の言葉とクラスが対応している

ユーザーの既知の言葉が先にあって
それをオブジェクト指向言語で実装しやすく・メンテしやすくするために
対応するクラスを作ったんだよね？
オブジェクト指向言語以外でも同じように実装しやすく・メンテしやすくするために
対応する関数やデータ型を作るだけじゃないの？

ユーザーの既知の言葉にどの程度対応付けできるかは
実装言語で扱える抽象化の方法にもよるけど
対応付けができるのはオブジェクト指向言語に特有のことではないよ
2017/09/19(火) 02:46:40.11ID:9ArzpmiB
>>679
一時期オブジェクト指向が目的になってる感があったよね

オブジェクト指向の適用範囲はプログラミング
そして設計のうち基本的な部分までだろう。

基本的な設計というのは具体的に言えばフレームワーク。
そのフレームワークというのは汎用的なもので
フレームワークの利用者に具体的な処理の部分だけを
書けばいいような形に設計するから、オブジェクト指向を意識する必要はなくなる。

またサーバー設計とかデータベース設計（オブジェクト指向データベースは除く）は
そもそもオブジェクト指向とは関係ない
2017/09/19(火) 03:07:31.07ID:6o+b/JQG
>>681
だから言語の話はしてないって
ガイジかよ
2017/09/19(火) 04:43:07.90ID:1X4lIwJc
>>651
その通り
DDDの発想だね

>>667
そんな訳ないよな
仕様変更しやすいのはOOのメリット
2017/09/19(火) 04:52:13.36ID:1X4lIwJc
>>681
＞対応付けができるのは
＞オブジェクト指向言語に特有のことではない

横レスに横レスだが……

OOPじゃないと「できない」わけじゃないが
OOPの方が「やりやすい」
2017/09/19(火) 05:09:27.48ID:Js438x12
・「オブジェクト指向」には「抽象データ型をクラス等でやる（カプセル化・継承・多態性）」と「遅延結合を（メッセージを送ってとかを方便にして）徹底する」という２種類あり混ぜると危険

・「オブジェクト指向」には「〜プログラミング」（前二者の混在）の他に「〜分析」（前者の強い影響下）「〜設計」（後者の強い影響下）があり混ぜるとワケワカメ

って二段階において区別が付かない人間がいるともう議論はおろか会話すら成り立たなくなるといういい例だったな

ついでにこのスレには「遅延システムを言語仕様に持ち込むな」とかいう宗教のSmalltalkアンチ＆他人の話は読み飛ばすくせに自分の意見は押し付けるガイジがいて、話がエンドレスエイト
2017/09/19(火) 07:09:47.56ID:H6eyWyRr
>>686
で？
それってどこの資料に書いてあるの？
テメーの意見だろ
死ねよ
2017/09/19(火) 07:52:39.18ID:oNO26kuq
>>686
もうSmalltalkはゴミだから存在価値なしって結論出たろ
その時に反論できなかったくせにシレッと復活させんな
2017/09/19(火) 09:41:53.11ID:baYuuAVc
>>687
オブジェクト指向プログラミング（のひとつ）が、抽象データ型（簡単に言うとユーザー定義のデータ型のこと）を
クラスなどで実装するアイデアだというのは、ビャーン・ストラウストラップが次で提唱（厳密には整理）しています
http://www.stroustrup.com/whatis.pdf

大枠としては、Simulaという言語が初めて作った「クラス」という言語機能を使って
整数型や浮動小数点少数型、文字列などといった通常は言語組み込みのデータ型と同様に
プログラマがデータ型を拡張できるようにしようというアイデアです。メリットは、いったん必要なデータ型を定義して
しまえば、そのデータ型やそれ同士の操作というかたちでプログラムの記述を抽象化（換言すると
シンプルに）できるというところにあります。

ストラウストラップのこのアイデア（正確には同時期に抽象データ型の発案者のリスコフ、Simulaの設計者の
ダールとニガードは当然として、Eiffelのバートランド・メイヤーらも同様の発想に到達しています）に準じれば
オブジェクト指向プログラミングのメリットのひとつは抽象データ型（データ抽象ともいう）を実践することと変わりませんから
（もちろんクラスを使うことで追加して継承による差分プログラミング、その結果の多態性を享受できます）、
メリットを検索したければまず"抽象データ型" "利点" などとしてググるとちゃんと出てきます。

まずここまでよろしいでしょうか？
2017/09/19(火) 09:49:26.36ID:H6eyWyRr
>>689
え？どこに仕組みが書いてあるの？ｗ
そもそもそいつの理論自体クソなんじゃねコレ

メリットは、いったん必要なデータ型を定義して
しまえば、そのデータ型やそれ同士の操作というかたちでプログラムの記述を抽象化（換言すると
シンプルに）できるというところにあります。

はぁ？
これが本当にメリットになっているか
こんな曖昧な表現で誰も検証してねぇのがそもそもの間違いなんだよ
2017/09/19(火) 09:59:43.63ID:E7A1w6jZ
俺はオブジェクト指向言語でプログラミングを覚えたから、やっぱり設計するときもベースになるのはオブジェクト指向だな
なんかやたらとオブジェクト指向に噛みついてる人がいるけど、勝手に自分がいいと思う方法論でやればいいじゃんっていうw
2017/09/19(火) 11:47:50.43ID:baYuuAVc
>>690
とりあえず、まずは抽象データ型をクラスを使って実践するアイデアの「オブジェクト指向プログラミング」が
それなりに名の知れた先達のアイデアであり、>>686個人の意見ではないことを言外に了解いただけたことは良かったです

抽象データ型（ユーザー定義のデータ型）のメリットについてはデータ型自体のメリットが当たり前すぎて
それを具体的に意識できないとちょっとピンと来にくいかもしれません
たとえばもし浮動小数点数データ型（float）が言語の組み込みでなかったとしたら
小数同士の演算やそれを入力・表示するためにプログラムを書くときに
どんな不都合が生じるかを考えると逆にメリットをイメージしやすいと思います

そもそもデータ型というのは人間とコンピューターの両方に対しこれから扱おうとするデータが
何を意味するのかについての情報を共有するためのタグのような役割を果たします

浮動小数点数ならその型であるfloatを宣言することで
人間側は変数や関数を通じて浮動小数点数（指数表現付き小数）を扱えることを知ることができ
コンピューター側は変数に代入された、あるいは関数に渡されたビット列データが浮動小数点数として
つまり各ビットが符号、指数部、仮数部のどれを表しているかを知り、ビット列に対し相応しい扱いをすることができるわけです

もしこのデータ型という情報がビット列データや変数、関数に附随させることが出来なかったら
たとえば浮動小数点数同士の加算を行なう関数（仮にadd_float）を呼び出すにも
渡したビット列が果たして本当に浮動小数点数を表すのか
そもそもそのadd_float関数を使うことが適切なのかの判断がしにくくなり
プログラムの正しさを保証・把握しにくくなります

また応用として（こちらの方が即効性のあるメリットですが）変数や関数にもデータ型情報を付加することができれば
同一名の関数や演算子を渡すデータ型ごとに適切に振る舞わせることが可能になり
プログラムの記述をシンプルにすることに役立ちます
a, b が float で、add_float(a,b) の場合、add_int、add_fractionなどというようにデータ型ごとに
いちいち区別せずに単に add(a,b)で済ませることが出来たり
演算子を用いてもっとシンプルに a + b と記述することも可能になります
2017/09/19(火) 12:15:42.13ID:lAmeNxGf
>>692
そいつらもなんも説明してないよな
そいつらの説明する文書にメリットの具体的な仕組みがない
曖昧な表現で溢れてて
本当にメリットなのか誰にもわかなくなってしまった
694デフォルトの名無しさん
垢版 |
2017/09/19(火) 12:26:34.99ID:sTkEDscL
>>691
自分が初めてちゃんとやったプログラミングがVisualWorksでの開発だったから，
今後他の言語でプログラム組むようになったら大変だろうなと思う
2017/09/19(火) 12:45:28.49ID:baYuuAVc
>>694
最初の本格的プログラミングが商用Smalltalkというのは羨ましいですね
2017/09/19(火) 14:50:14.42ID:OkajuEzq
>>685
DDDはオブジェクト指向かどうかに関係ないよ
DDDをF#でやる例
http://www.slideshare.net/ScottWlaschin/domain-driven-design-with-the-f-type-system-functional-londoners-2014

OOPの方が「やりやすい」場合があるのも確かだけど
そういう主張は往々にしてそれはOOPでのやり方しか知らないから
2017/09/19(火) 15:02:00.92ID:OkajuEzq
>>692
抽象データ型はOOPじゃなくても
現在に使われてる言語の大半で実現できることなのでそのメリットを長々と語っても意味がない
抽象データ型を”クラス”を使って実現することがOOPの特徴だと言うなら
“クラス”を使うことのメリットを説明しないと
2017/09/19(火) 15:19:08.58ID:6o+b/JQG
設計の話で言語がー言いだす
ガイジは言語スレ行けよ
2017/09/19(火) 16:11:27.59ID:E7A1w6jZ
>>696
F#はマルチパラダイムだけど、いったんそれは置いとくとして、オブジェクト指向言語と非オブジェクト指向言語ではどっちがDDDやりやすいの？
オブジェクト指向言語しか知らないから教えてほしいな
2017/09/19(火) 16:31:00.62ID:baYuuAVc
>>697
おっしゃるとおりです
ただ ID:H6eyWyRr への説明だったのであえてデータ型まで掘り下げました
2017/09/19(火) 17:08:27.00ID:1X4lIwJc
>>692
C++やJavaは抽象データ型を重視するOOP

ただJavaScriptはプロトタイプベースだから
オブジェクト指向の全部じゃないんだけど
静的型OOPの主流ではある


>>689
＞もし浮動小数点数データ型（float）が
＞言語の組み込みでなかったとしたら
この例は分かりやすかった

（抽象）型設計していくのが
C++やJavaのOOP
2017/09/19(火) 17:13:43.45ID:1X4lIwJc
>>696
別にPrologでDDDやってもいいんだよ

でもエリックエヴァンスのDDD本では
オブジェクト指向がメインになってるので
そこを無視して「関係ない」と言ってはいけない

やっぱりOOPの方がDDDをやりやすい
703デフォルトの名無しさん
垢版 |
2017/09/19(火) 19:39:03.99ID:3IGf5g9v
このスレなら信頼できるレスを期待できると信じて質問しますです。

<< 質問 >>

デザインパターンは、大手企業の開発者以外では使われていないのだろうか？

特に地方では、全くと言っていいほど使われていないのだろうか？
2017/09/19(火) 19:55:22.09ID:8vQ/BDKS
>>703
よほどのことが無い限りOSS使って開発するのがほとんどだから意識しないうちに触ってるとかはよくある
Factoryパターンとかは頻繁につかうからデザインパターン勉強してないやつが設計しても出てくる
デザインパターンバリバリに意識して設計されてるのは見ない
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
＞日本語を学んで上達
日本語は母語だから自然と上達するが
英語だと学ばないとカタコトのまま
数学だとさらに意識的な学習が必要

プログラミング言語は英語や数学に近い
意識的に学習しないと上達しない
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況