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

**デフォルトの名無しさん** · 2017/08/08(火) 17:52:14.38

前スレ
オブジェクト指向システムの設計 172
http://mevius.2ch.net/test/read.cgi/tech/1467992113

類似スレ
手続き型システムの設計 1
http://mevius.2ch.net/test/read.cgi/tech/1500282714

**デフォルトの名無しさん** · 2017/09/18(月) 23:18:19.59

>>618
そんなにどこにでも書いてあるなら
リンクを5個ぐらい貼ってみろよ
オブジェクト指向の入門サイトにでもあるんだろ？
なにせ常識らしいからな

**デフォルトの名無しさん** · 2017/09/18(月) 23:20:22.40

>>616
ちなみに、分からなければ分からないでいい。
所詮はOOPも手段であり、OOPを用いずとも困ってないのなら、わざわざ使う必要はない。

**デフォルトの名無しさん** · 2017/09/18(月) 23:21:34.19

>>620
違うだろバカ
テメーはメリットなんか知らないだろ

**デフォルトの名無しさん** · 2017/09/18(月) 23:22:51.75

>>620
何偉そうにしてんの？
わからないくせに
わかるならいくつでも箇条書きで
書いてみろよアホ

**デフォルトの名無しさん** · 2017/09/18(月) 23:24:17.62

規模が大きくなるほど
手続き型で保守しにくくなる

大規模プログラムで保守性が高まるのは
オブジェクト指向のメリットのひとつで
いろんな入門書に書いてある

**デフォルトの名無しさん** · 2017/09/18(月) 23:27:29.49

>>623
言語レベルではそうだね。

だけど大規模プログラムを保守しやすくするなら
オブジェクト指向にするだけじゃなくて
単純に規模を小さくすればいい
それがマイクロサービスでもある

**デフォルトの名無しさん** · 2017/09/18(月) 23:27:57.21

>>619
ひょっとして、手続き型おじいちゃんの土人の方ですか？
屁臭いペチプァの方ですか？

**デフォルトの名無しさん** · 2017/09/18(月) 23:28:42.89

ID:IcOpWHLwが論点を挙げられないのは
テキトーに否定するだけだったからか

**デフォルトの名無しさん** · 2017/09/18(月) 23:28:45.85

>>619
日本語でおk

**デフォルトの名無しさん** · 2017/09/18(月) 23:30:22.06

>>623
どういう原理で？ｗ

そもそもなんででかくないと効果がないの？
機能10個作るのと機能20個作るので難易度変わるの？
変わるように組んでるの？

**デフォルトの名無しさん** · 2017/09/18(月) 23:31:42.19

>>626
お前は全くメリット挙げられないクズ

**デフォルトの名無しさん** · 2017/09/18(月) 23:32:46.81

>>627
そんなにオブジェクト指向のメリットが常識だって主張するなら
書いてあるサイト探してこいって言ってんだよ
嘘つき野郎

**デフォルトの名無しさん** · 2017/09/18(月) 23:34:05.63

>>629
説明損になるとこだったよ

**デフォルトの名無しさん** · 2017/09/18(月) 23:35:05.51

>>631
消えろ邪魔

**デフォルトの名無しさん** · 2017/09/18(月) 23:36:35.21

メリットなんてケースによるんだから否定するのは容易い
俺は大規模開発なんてしないもん!とかな

自分の開発対象にあった開発方法をとって、
その上での議論だろ

**デフォルトの名無しさん** · 2017/09/18(月) 23:37:27.40

>>632
論点を挙げられないこと指摘されて邪魔か
さすがクズ

**デフォルトの名無しさん** · 2017/09/18(月) 23:37:50.84

>>633
速く死ねよ
あぼーんで見えねぇよ

**デフォルトの名無しさん** · 2017/09/18(月) 23:39:45.83

なんで見えないのにわかるんだ
口からでまかせばかりだな

**デフォルトの名無しさん** · 2017/09/18(月) 23:44:08.97

>>624
ちなみに俺はそれもありだと思ってるよ。

具体的に言えばJavaScriptの連中が壮絶に酷くて、OOPどころかそれ以前なんだけど、
実際はそれでも結構動いてしまう。
理由は簡単で、サーバー/クライアント構成でデータ管理は完全に分離されてて、
データクエリはhttpでフォーマットもJSONとお決まりで、何も考える必要なく、
JavaScriptは単にGUIの装飾だけやればいい感じだから。
抽象度もそれなりだから50行位で一機能出来てしまって、
5個くらい(=250行)あればまあまあ見栄えしてしまう。
ああこれでは成長せんなーとは思ったね。
この規模なら毎回コピペ＋書き捨ての方が生産性高いし。

ただ、従来はデータ管理等も全部自前でやるから肥大化するのであって、
正直OOPでがんばって自前でやりくりするより、
既製品のDBとか使ってマッシュアップするJavaScript的開発の方が楽だから、
今後はそうなる気もする。

**デフォルトの名無しさん** · 2017/09/18(月) 23:48:22.36

>>630
> そんなにオブジェクト指向のメリットが常識だって主張するなら
> 書いてあるサイト探してこいって言ってんだよ
これを主張した奴はこのスレ内にはいない。
つまり、日本語でおｋ
俺が言ったのは「プログラミング言語C++」で、これは本だ。

お前が知りたいのなら、おまえ自身が探してきて、
ここにこんなこと書いてますが合ってますか？と訪ねればいいだろ。

**デフォルトの名無しさん** · 2017/09/18(月) 23:52:37.86

>>637
今どきはJavaScriptでもwebpackとかあるんだし
使い捨てせずにモジュール化して使いまわすよ普通は
OOPかどうかは別として

**デフォルトの名無しさん** · 2017/09/18(月) 23:55:59.34

>>637
ああそういう所はあるよな

Web（アプリ）って単体のコードは
壮絶に汚くなりがちだし
OOPも退化してる

だがフロントエンドとバックエンドを分けるとか
Webの仕組みが上手くできてるんで
それでも何とかなっちゃうんだよな

**デフォルトの名無しさん** · 2017/09/18(月) 23:56:19.32

張り切ってるヤツは
俺の考えにそぐわない物は間違いである
って主張なの？

**デフォルトの名無しさん** · 2017/09/18(月) 23:59:55.60

オブジェクト指向は、それ以前から存在する技術も
オブジェクト指向に取り入れた＝オブジェクト指向の技術
と言うつもりなんだあろうか？

保守性とか拡張性とか、そんなもんオブジェクト指向以前から有るだろ

例えば金融業界、COBOLなんかの世界で使われてる
全銀フォーマット規格
http://www.kitashin-bank.co.jp/pdf/f-manual/99-02-00_WEB-FB.pdf

こういうのまでオブジェクト指向だって言うつもりなんだろう？
マイクロサービス化におけるAPIは、この全銀フォーマット規格となんもかわらん。
こういうフォーマットでデータ投げれば処理してくれますよーなんだから

**デフォルトの名無しさん** · 2017/09/19(火) 00:04:25.20

結局こういう論理なんだよな

オブジェクト指向を使うと従来よりも保守性や拡張性が向上する場面が有る
↓
オブジェクト指向は保守性や拡張性をもたらすものである
↓
保守性や拡張性をもたらすにはオブジェクト指向を使ったほうが良い
↓
保守性や拡張性がある＝オブジェクト指向である
↓
マイクロサービスとかクラウドとか保守性や拡張性が有るやろ？
それらは全部オブジェクト指向なんやで？

オブジェクト指向とは一体何なのか？

**デフォルトの名無しさん** · 2017/09/19(火) 00:06:29.46

>>641
っていうか
この技術は効果無しの似非技術で
間違いなくね？

そんなに当たり前の技術なら
メリットなんてググったら
その仕組みから明確なものが出てきていいだろｗ

こんなに勿体ぶる必要もないし
仕組みがわかれば大きいプロジェクトでないと効果がないも
わかるけどそもそも
正しいオブジェクト指向が反映されたソース自体よくわからんし

**デフォルトの名無しさん** · 2017/09/19(火) 00:13:23.26

そもそもなぜここまでメリットの説明できないものを
効果がありそうに言うの？
お前らは
これ役に立たないだろ
だから説明できないじゃん

お前らがアホなんじゃなくて
どの資料にもサイトにも
具体的なメリットおよびその効果をもたらす仕組みの記述がねぇんだよ
だから誰も具体的な話がよくわからないが正解だろこれ

んでオブジェクト単位で分けたところで
書く必要のある処理を書かなくて良くなることはないし
保守だの拡張だのなんてあるわけないし
なんで騙されてるって気が付かないんだ？

**デフォルトの名無しさん** · 2017/09/19(火) 00:16:43.07

>>639
使いまわせればそれに越したことはないんだけど、
チョイ変更が必要なときどうするかだよ。
そこを共通モジュール側に変更として取り込むか、使い捨てと割り切ってコピペ+改変で乗り切ってしまうか。

やってみて分かったんだが、GUIって実際に使ってみないと使い勝手が分からないことも多くて、
張り切って作ってもゴミだとか、
或いは一時凌ぎで適当に作ったら意外に使いやすくて拡張していき、おかげで酷いことになるとか結構あって、
どれを取り込むべきか最初には分からないんだよ。
（俺にGUIのセンスが無いといえばそうだが）
だからとりあえずコピペ+改変で組んでしまって、
後で本当に使える場合はもう一度共通側に取り込むほうがましだと俺は判定している。
二度手間ではあるが、変に最初に取り込んで除去する方が死ねるから。

>>640
イエス。

**デフォルトの名無しさん** · 2017/09/19(火) 00:18:34.87

>>644
じゃあ他の手法でやってりゃいいじゃん
自分でどういう設計するか自分じゃ決められないのか

**デフォルトの名無しさん** · 2017/09/19(火) 00:20:28.09

>>645
騙されてるって、誰がなんのためにプログラマを騙すんだよ
なんらかの陰謀論のせいにして思考停止ですかw

**デフォルトの名無しさん** · 2017/09/19(火) 00:22:36.67

>>648
c言語が完璧過ぎたから
オブジェクト指向言語って名目で売り出したかったんだろ？
販売戦略の一環だろこれ

**デフォルトの名無しさん** · 2017/09/19(火) 00:24:26.80

そろそろitproとか日ソフに
オブジェクト指向役に立ちませんでしたって記事書いてほしいけどね

**デフォルトの名無しさん** · 2017/09/19(火) 00:24:32.28

まともに作ったオブジェクト指向プログラムでは
ユーザーの既知の言葉とクラスが対応している
クラスに関わる情報が集約されてる
よって仕様変更に対応しやすい

もっともメリットを享受してるのはここだな

**デフォルトの名無しさん** · 2017/09/19(火) 00:26:06.13

>>651
意味がわかんない
どう仕様変更されるかもわからないのにそんな言葉出しちゃう時点で
テメーはクソだから発言しなくていいよ

**デフォルトの名無しさん** · 2017/09/19(火) 00:27:06.08

>>639
ああすまん、俺が言っているのは「スニペット」と言うのかもしれん。
（俺自身はあの機能は嫌いだから使ってないが、たぶん意味的にはこれ）

モジュールというよりは「お約束的コード」の塊を持っておき、
それをベースにその都度必要なら改変して使う、って奴。
それで使えると判明したら「お約束的コード」に新しい機能を取り込む。
JavaScriptはGUIの装飾が主だから、割とこんな感じのほうが上手く行く気がする。

**デフォルトの名無しさん** · 2017/09/19(火) 00:27:42.18

>>649
関数型も完璧すぎるC言語に対抗するためのマーケティングと捉えてる？

**デフォルトの名無しさん** · 2017/09/19(火) 00:29:49.11

>>654
名前なんかなんでもいいんだろ
言語と必要であれば設計手法も付けて売り出せれば本当になんでもいいんだと思うよ

**デフォルトの名無しさん** · 2017/09/19(火) 00:30:54.19

>>652
え、どう仕様変更されるかわからないからって仕様変更への対応しやすさはまったくの度外視でシステム作っちゃうのお前

**デフォルトの名無しさん** · 2017/09/19(火) 00:32:11.91

>>655
構造化もマーケティング、手続きもマーケティング、さあどこまで遡ればマーケティングと無縁の世界、お前の桃源郷に辿り着くんでしょうかw

**デフォルトの名無しさん** · 2017/09/19(火) 00:34:11.72

>>645
> そもそもなぜここまでメリットの説明できないものを
> 効果がありそうに言うの？

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

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

なんかその道のプロは、オブジェクト指向の真のメリットは
継承やカプセル化や多態性とか言ってるけど、
それはオブジェクト指向の応用でできることであって、
オブジェクト指向はわかりやすいっていうのが
（メリットではなく）特徴

**デフォルトの名無しさん** · 2017/09/19(火) 00:35:21.48

>>657
ちゃんと見定めればいいんじゃないかな？
役に立つものと立たないものを

**デフォルトの名無しさん** · 2017/09/19(火) 00:38:39.43

>>656
> え、どう仕様変更されるかわからないからって仕様変更への対応しやすさはまったくの度外視でシステム作っちゃうのお前

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

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

最初に作り込むのをやめて、最低限動くコードを書くのが良い。
これもオブジェクト指向とは関係ない話

**デフォルトの名無しさん** · 2017/09/19(火) 00:40:09.40

プロトタイプ開発

**デフォルトの名無しさん** · 2017/09/19(火) 00:40:23.37

>>652
仕様変更はユーザーの既知の言葉でなされる

**デフォルトの名無しさん** · 2017/09/19(火) 00:41:58.60

ユーザーの既知の言葉はオブジェクト指向ではない

**デフォルトの名無しさん** · 2017/09/19(火) 00:47:42.06

>>659
オブジェクト指向は役に立つね

**デフォルトの名無しさん** · 2017/09/19(火) 00:48:50.65

>>664
お前、ミソが腐ってるからな

**デフォルトの名無しさん** · 2017/09/19(火) 00:53:31.47

>>665
お前、性根が腐ってるからな

**デフォルトの名無しさん** · 2017/09/19(火) 00:54:13.00

>>660
オブジェクト指向と関係ないか
じゃあどんな設計手法となら関係ある？手続き型も関数型も、再利用のしやすさ、仕様変更への対応のしやすさとはまったくの無関係？
どんな設計手法を取ろうと、仕様変更への対応はまったく同じだけのコストがかかる？

**デフォルトの名無しさん** · 2017/09/19(火) 01:00:45.76

>>663
ユーザーの既知の言葉をクラス化したと言ったはずだが
お前には何もできないね

**デフォルトの名無しさん** · 2017/09/19(火) 01:03:40.84

>>667
> じゃあどんな設計手法となら関係ある

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

そういうレベルの話

> どんな設計手法を取ろうと、仕様変更への対応はまったく同じだけのコストがかかる？
場合による。どれが最高とかはない。銀の弾丸はないのだよ君

**デフォルトの名無しさん** · 2017/09/19(火) 01:05:01.44

>>668
ユーザーの既知の言葉には
動詞もあるはずだが、それもクラスにしたのか？

**デフォルトの名無しさん** · 2017/09/19(火) 01:08:32.48

>>670
動詞はクラスのメソッドだろ
基本くらい勉強してこい

**デフォルトの名無しさん** · 2017/09/19(火) 01:09:31.94

ユーザーの既知の言葉をクラス化したというが
じゃあオブジェクト指向以外ではできないと思うのか？

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

違うな。C言語で作られたLinuxでも見ればわかるだろう。
他の手法ではモジュール（またはファイル）になるんだよ

**デフォルトの名無しさん** · 2017/09/19(火) 01:23:49.02

まあバトるのはいいと思うけど、結局のところsmalltalkの話と似たような事になっていて、

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

だからメリットが見えないのなら使わなければいいだけ。
JavaScriptとかの状況だと、OOPで書いてもあまりメリットないのは事実だし。

**デフォルトの名無しさん** · 2017/09/19(火) 01:32:29.64

ID:H6eyWyRr

完全なるガイジ
こういうのが現場に一匹でも紛れ込んでいたら
さぞ迷惑だろうな

**デフォルトの名無しさん** · 2017/09/19(火) 01:35:21.15

>>672
それはオブジェクト指向言語でないとできないかという話か?
設計の話をしてんだよ
できるしgtkとかC言語でオブジェクト指向設計で組んだプログラムもある
オブジェクト単位で分けたならオブジェクト指向設計だし、そうでないなら他の設計だろ

モジュールはオブジェクトだったり機能分割だったりより包括的な言葉だ
お前の言っていることは間違えてる

**デフォルトの名無しさん** · 2017/09/19(火) 01:49:41.82

結局さ、オブジェクト指向が生きるのは実装の話なんだよね。
言語より外に出ないでほしい。

**デフォルトの名無しさん** · 2017/09/19(火) 02:07:01.99

オブジェクト指向言語で実装しやすいように設計したり
オブジェクト指向言語で実装した場合に後でメンテナンスが楽になるように設計するのが
オブジェクト指向設計じゃろ？

**デフォルトの名無しさん** · 2017/09/19(火) 02:07:22.02

弁解せずに話し飛ばして逃げたか
ID:9ArzpmiBが恥を晒すだけのスレになってしまったな

**デフォルトの名無しさん** · 2017/09/19(火) 02:13:40.15

「オブジェクト指向」って言葉自体、色んな意味で使われて混乱の元になっていたのは事実だわな。
最近の本では
「オブジェクト指向でなぜつくるのか」
がそのあたりの状況も含めてすっきり整理して分かりやすかった。

とりあえず
「オブジェクト指向プログラミング」
「オブジェクト指向設計」
「オブジェクト指向分析」
はきっちり分けて会話しないとますます混乱するな。

**デフォルトの名無しさん** · 2017/09/19(火) 02:38:22.83

>>678
それについて弁解しろと？

**デフォルトの名無しさん** · 2017/09/19(火) 02:45:40.97

>>678
横レスだが君のレスのほうが普通におかしいよ

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

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

ユーザーの既知の言葉にどの程度対応付けできるかは
実装言語で扱える抽象化の方法にもよるけど
対応付けができるのはオブジェクト指向言語に特有のことではないよ

**デフォルトの名無しさん** · 2017/09/19(火) 02:46:40.11

>>679
一時期オブジェクト指向が目的になってる感があったよね

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

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

またサーバー設計とかデータベース設計（オブジェクト指向データベースは除く）は
そもそもオブジェクト指向とは関係ない

**デフォルトの名無しさん** · 2017/09/19(火) 03:07:31.07

>>681
だから言語の話はしてないって
ガイジかよ

**デフォルトの名無しさん** · 2017/09/19(火) 04:43:07.90

>>651
その通り
DDDの発想だね

>>667
そんな訳ないよな
仕様変更しやすいのはOOのメリット

**デフォルトの名無しさん** · 2017/09/19(火) 04:52:13.36

>>681
＞対応付けができるのは
＞オブジェクト指向言語に特有のことではない

横レスに横レスだが……

OOPじゃないと「できない」わけじゃないが
OOPの方が「やりやすい」

**デフォルトの名無しさん** · 2017/09/19(火) 05:09:27.48

・「オブジェクト指向」には「抽象データ型をクラス等でやる（カプセル化・継承・多態性）」と「遅延結合を（メッセージを送ってとかを方便にして）徹底する」という２種類あり混ぜると危険

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

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

ついでにこのスレには「遅延システムを言語仕様に持ち込むな」とかいう宗教のSmalltalkアンチ＆他人の話は読み飛ばすくせに自分の意見は押し付けるガイジがいて、話がエンドレスエイト

**デフォルトの名無しさん** · 2017/09/19(火) 07:09:47.56

>>686
で？
それってどこの資料に書いてあるの？
テメーの意見だろ
死ねよ

**デフォルトの名無しさん** · 2017/09/19(火) 07:52:39.18

>>686
もうSmalltalkはゴミだから存在価値なしって結論出たろ
その時に反論できなかったくせにシレッと復活させんな

**デフォルトの名無しさん** · 2017/09/19(火) 09:41:53.11

>>687
オブジェクト指向プログラミング（のひとつ）が、抽象データ型（簡単に言うとユーザー定義のデータ型のこと）を
クラスなどで実装するアイデアだというのは、ビャーン・ストラウストラップが次で提唱（厳密には整理）しています
http://www.stroustrup.com/whatis.pdf

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

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

まずここまでよろしいでしょうか？

**デフォルトの名無しさん** · 2017/09/19(火) 09:49:26.36

>>689
え？どこに仕組みが書いてあるの？ｗ
そもそもそいつの理論自体クソなんじゃねコレ

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

はぁ？
これが本当にメリットになっているか
こんな曖昧な表現で誰も検証してねぇのがそもそもの間違いなんだよ

**デフォルトの名無しさん** · 2017/09/19(火) 09:59:43.63

俺はオブジェクト指向言語でプログラミングを覚えたから、やっぱり設計するときもベースになるのはオブジェクト指向だな
なんかやたらとオブジェクト指向に噛みついてる人がいるけど、勝手に自分がいいと思う方法論でやればいいじゃんっていうw

**デフォルトの名無しさん** · 2017/09/19(火) 11:47:50.43

>>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.13

>>692
そいつらもなんも説明してないよな
そいつらの説明する文書にメリットの具体的な仕組みがない
曖昧な表現で溢れてて
本当にメリットなのか誰にもわかなくなってしまった

**デフォルトの名無しさん** · 2017/09/19(火) 12:26:34.99

>>691
自分が初めてちゃんとやったプログラミングがVisualWorksでの開発だったから，
今後他の言語でプログラム組むようになったら大変だろうなと思う

**デフォルトの名無しさん** · 2017/09/19(火) 12:45:28.49

>>694
最初の本格的プログラミングが商用Smalltalkというのは羨ましいですね

**デフォルトの名無しさん** · 2017/09/19(火) 14:50:14.42

>>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.92

>>692
抽象データ型はOOPじゃなくても
現在に使われてる言語の大半で実現できることなのでそのメリットを長々と語っても意味がない
抽象データ型を”クラス”を使って実現することがOOPの特徴だと言うなら
“クラス”を使うことのメリットを説明しないと

**デフォルトの名無しさん** · 2017/09/19(火) 15:19:08.58

設計の話で言語がー言いだす
ガイジは言語スレ行けよ

**デフォルトの名無しさん** · 2017/09/19(火) 16:11:27.59

>>696
F#はマルチパラダイムだけど、いったんそれは置いとくとして、オブジェクト指向言語と非オブジェクト指向言語ではどっちがDDDやりやすいの？
オブジェクト指向言語しか知らないから教えてほしいな

**デフォルトの名無しさん** · 2017/09/19(火) 16:31:00.62

>>697
おっしゃるとおりです
ただ ID:H6eyWyRr への説明だったのであえてデータ型まで掘り下げました

**デフォルトの名無しさん** · 2017/09/19(火) 17:08:27.00

>>692
C++やJavaは抽象データ型を重視するOOP

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

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

（抽象）型設計していくのが
C++やJavaのOOP

**デフォルトの名無しさん** · 2017/09/19(火) 17:13:43.45

>>696
別にPrologでDDDやってもいいんだよ

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

やっぱりOOPの方がDDDをやりやすい

**デフォルトの名無しさん** · 2017/09/19(火) 19:39:03.99

このスレなら信頼できるレスを期待できると信じて質問しますです。

<< 質問 >>

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

特に地方では、全くと言っていいほど使われていないのだろうか？

**デフォルトの名無しさん** · 2017/09/19(火) 19:55:22.09

>>703
よほどのことが無い限りOSS使って開発するのがほとんどだから意識しないうちに触ってるとかはよくある
Factoryパターンとかは頻繁につかうからデザインパターン勉強してないやつが設計しても出てくる
デザインパターンバリバリに意識して設計されてるのは見ない

**デフォルトの名無しさん** · 2017/09/19(火) 20:27:42.88

>>703
デザインパターンは良く使われてるデザイン、設計をパターン化したものだ
そのデザイン自体は無能でなければどこかしらで使っているだろうが、
パターンとして認識してるかは別だ

**デフォルトの名無しさん** · 2017/09/19(火) 20:32:55.48

フレームワークは、デザパタの集積だから、知らず知らず使ってる

フレームワーク製作者は、デザパタの勉強が欠かせないけど、
使う方は、知らなくても使える

**デフォルトの名無しさん** · 2017/09/19(火) 21:38:54.06

>>703
singletonはよく使われてる

**デフォルトの名無しさん** · 2017/09/19(火) 21:47:07.15

>>703
デザパタ自体はあるあるに名前を付けただけだから知ってても知らなくても使ってる。

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

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

まあそれ以前に、最近は継承はいらない子、委譲だけでよし、ってのも流行ってるみたいだが。Goとか。

**デフォルトの名無しさん** · 2017/09/19(火) 22:28:41.59

>>703
ストラテジーみたいに単純なものは
意識されなくても自然と使われてる
ビジターとか複雑なのはあまり使われてない

デザパタは意識して組まなくてもいいが
一通り学んだ方がいい
「これは○○パターンだな」って分かると
設計するときの土台になるから

**デフォルトの名無しさん** · 2017/09/19(火) 22:29:43.79

デザインパターンって打つのも億劫か

**デフォルトの名無しさん** · 2017/09/19(火) 22:56:50.66

デザパタは神話
カタログ化こそに異議があるという意見もあるが
それこそ噴飯物
読者のレベルにもよるのはわかってるが
だいたいガバガバ理解ですれ違ってるのを見る
GoFのことかと思えば
GoFのことではなくて独自用語ぶっこんできたりもする
(>>704に見られる「Factoryパターン」であったり)

設計のための勉強に使うと言い切ったほうがまだマシに思える現状

**デフォルトの名無しさん** · 2017/09/19(火) 22:57:09.49

×異議
○意義

**デフォルトの名無しさん** · 2017/09/19(火) 23:07:22.41

>>711
>>704は「Factory」だけで意味通じる

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

そこまで融通が利かなかったから
そりゃ使いにくいだろうけど

**デフォルトの名無しさん** · 2017/09/19(火) 23:15:17.03

断言していいと思うけど

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

この区別は>>704には無いし
後者二つについての理解は不十分だと思うｗ
デザパタデザパタ言ってみても
早速その辺で深い溝を感じる

**デフォルトの名無しさん** · 2017/09/19(火) 23:28:15.81

おい、デザパタ用語使わずに
デザパタの話しろよ

**デフォルトの名無しさん** · 2017/09/19(火) 23:42:04.65

つまり、方言が多くて意味無いって事か？

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

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

要するに直newせずにファクトリ呼べ、ってだけで全部同じだが。
俺はデザパタのこの手の無駄に組み合わせ数が爆発してる感が大嫌い。
OOPもそうだが、デザパタもここまできたらデザパタが目的になってる感がある。

**デフォルトの名無しさん** · 2017/09/19(火) 23:51:52.40

デザパタはパターンに名前を付けたことに
意義があるというが眉唾

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

できるだろ！

**デフォルトの名無しさん** · 2017/09/19(火) 23:53:38.39

>>716
一部にのみレス返す

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

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

・Abstract Factoryパターン
インスタンス群を作成するファクトリを抽象化する
ファクトリごと置き換えて、インスタンス群を丸ごと置き換えたい時使う
インスタンス群、ファクトリごと、が特徴
こーいうのはクラスライブラリを作って他人に提供しようとしたとき欲しくなるパターン