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

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

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

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

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

2getでオブジェクト指向消滅!

**デフォルトの名無しさん** · 2017/09/26(火) 14:21:52.30

デザパタ

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

このスレは結局デザパタの話題になっちゃうの？

**デフォルトの名無しさん** · 2017/09/26(火) 21:28:18.31

デザパタとSmalltalkと…

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

smalltalk信者：変化する環境に適応出来なかった絶滅種
デザパタ厨：煽ることしか出来ない無能

次の患者、どうぞ

**デフォルトの名無しさん** · 2017/09/26(火) 23:21:32.01

>>6
お前は何て病気?

**デフォルトの名無しさん** · 2017/09/26(火) 23:57:05.71

無能な煽りは逆効果だとも分からないほど無能なんだな。

デザパタなんてイラネな俺がいくら無能でも、
デザパタを勉強する価値がある事にはならんだろ。
肝心のデザパタ厨が無能なんだから。
お前ら当たり前の論理も組み立てられないのな。

結局はデザパタ厨もやりすぎて手段が目的になってる。
上級者の実装パターンを学び、実装時にそれを生かすのが目的なのに、
デザパタの暗記が目的になり、undoすら実装出来ないのでは意味無いだろ。
しかも自分がその程度だと気付けてないのも救えない。

全スレ>>945は訂正しておく
・933の実力>>>デザパタ厨＝自分がundoの実装すらマトモに出来ない事に気づけない

布教したいのなら、お前らがやるべき事は、
実装方式を悩んでいる初心者に対し、「そこは○○パターンで(ｷﾘｯ」と丁寧に教えることであって、
いくら俺を叩いても意味無いだろ。
まあお前らにはこれをやる実力すらないわけだが。

**デフォルトの名無しさん** · 2017/09/27(水) 00:29:39.71

全スレが泣いた

**デフォルトの名無しさん** · 2017/09/27(水) 00:46:50.85

心の中では「まえスレ」

**デフォルトの名無しさん** · 2017/09/27(水) 01:46:12.14

設計パターンなんていらない

**デフォルトの名無しさん** · 2017/09/27(水) 01:54:22.30

アーキテクチャパターンもいらない子

**デフォルトの名無しさん** · 2017/09/27(水) 01:56:12.89

>>8
で、なんでデザパタイラネなんだっけ？

**デフォルトの名無しさん** · 2017/09/27(水) 02:04:44.17

前スレ見てきた

> デザパタの暗記が目的になり、undoすら実装出来ないのでは意味無い

とか言ってる人がいたから、デザパタ厨とアンチデザパタ厨で実装対決してたのかと思ったら、誰もなにも実装してなかった
なるほど、undoすら実装できない人同士で設計論を争ってるのか

**デフォルトの名無しさん** · 2017/09/27(水) 02:10:07.97

デザパタの持つ意味も理解してなければ
デザパタとundoの関係も理解してない人が
デザパタイラネと言ってたのが前スレ

**デフォルトの名無しさん** · 2017/09/27(水) 03:32:14.99

undoするものがないのに何を実装するんだ
こいつundoさえわからないのか

**デフォルトの名無しさん** · 2017/09/27(水) 06:51:39.93

どんなコンテナ概念も全部「それは構造体だから～」にする
いつもの「自動車は馬なし馬車だから」さんが居たのは憶えてる。

**デフォルトの名無しさん** · 2017/09/27(水) 12:03:00.13

un, deux, trios

**デフォルトの名無しさん** · 2017/09/29(金) 01:04:50.43

「注文」っていう動詞があったときに、
「振る舞い」と「操作」って何が違うんかな。

**デフォルトの名無しさん** · 2017/09/29(金) 01:17:44.77

>>19
主体が違うし、それがOOPの基礎でもある。
詳しくは優秀なつもりのデザパタ厨が説明してくれるのを待て。

**デフォルトの名無しさん** · 2017/09/29(金) 02:19:10.82

order.cancel() -> 注文の振る舞い
cancel(order) -> 注文に対する操作

ただしメソッドのことを操作と呼ぶ場合もあるから文脈による

**デフォルトの名無しさん** · 2017/09/29(金) 09:01:57.77

>>19
注文のように振る舞うオブジェクトを他のオブジェクトが操作するんだよ

**デフォルトの名無しさん** · 2017/09/30(土) 01:29:46.30

だからデザパタってなんだよ
デザインパターンすら打つのが面倒くせえ奴はプログラミングなんかやめちまえ

**デフォルトの名無しさん** · 2017/09/30(土) 03:51:14.41

デザパタ

**デフォルトの名無しさん** · 2017/09/30(土) 06:58:20.29

面倒くさがりはプログラマに向いてるだろ

**デフォルトの名無しさん** · 2017/09/30(土) 07:00:21.91

オブジェクト指向ができなくて悩んでいるのですが、アドバイスお願いします
例として商品は10種類まで、今はつり銭の概念が入ってくるとややこしくて考えられないので投入金額 = 価格のみ購入可能というすごいシンプルな飲料自動販売機を想定しています
フローとしては購入する()内で飲料型の商品変数のメンバ価格と投入金額を比較し、イコールだった場合在庫数を減らす()を呼ぶというふうに考えているのですがどうなのでしょうか？
また自販機がわかりづらい場合、他の例を出して頂ければそちらで設計しますのでお願いします

クラス図を貼っておきます
https://i.imgur.com/0Sthq5O.png

**デフォルトの名無しさん** · 2017/09/30(土) 07:13:23.68

どうなのって、正解があるわけじゃないから好きに作れよ
複雑そうなところはクラスの数を増やす、そうでないなら無理にクラス化しない
そういうことでどこまで作るかにもよるし
ユースケース図でも書け

**デフォルトの名無しさん** · 2017/09/30(土) 09:03:57.67

>>26
お前が何がわからないのかわからない

**デフォルトの名無しさん** · 2017/09/30(土) 09:04:38.47

デザパタデザパタデザパタデザパタデザパタデザパタデザパタデザパタ
デザパタデザパタデザパタデザパタデザパタデザハタデザパタデザパタ
デザパタデザパタデザパタデザパタデザパタデザパタデザパタデザパタ

**デフォルトの名無しさん** · 2017/09/30(土) 10:19:36.24

デザパタ厨はこういう時こそ「○○パターンで！」とやるべきだろ。
そもそもデザパタ厨ですら全く使わない（＝見かけない）から最初の質問、
「本当に使われているのか？」が発生するのであって。

**デフォルトの名無しさん** · 2017/09/30(土) 10:25:41.46

ねーよ
デザパタは使おうとすると
適応根拠が説明しきれない

**デフォルトの名無しさん** · 2017/09/30(土) 10:37:51.13

StrategyとStateの違いって何よ

**デフォルトの名無しさん** · 2017/09/30(土) 10:43:09.58

>>31
それだとデザパタは使い物にならない＝ゴミ、ってことになるだろ。
てか君はどっち派よ？
まずはデザパタ厨に説明する機会を与え、様子見すべきだろ。

**デフォルトの名無しさん** · 2017/09/30(土) 10:43:56.11

>>32
rgy

**デフォルトの名無しさん** · 2017/09/30(土) 11:26:06.12

>>33
どっちとかじゃない
デザパタはどのくらいクソって議論しか取り合わない

**デフォルトの名無しさん** · 2017/09/30(土) 11:46:25.29

>>35
なら敢えて聞こう、どの位クソなのかと

**デフォルトの名無しさん** · 2017/09/30(土) 11:47:40.97

ところでリアルでデザパタって言ってるの？

**デフォルトの名無しさん** · 2017/09/30(土) 11:52:30.69

>>36
熱盛

**デフォルトの名無しさん** · 2017/09/30(土) 12:58:39.68

>>37
外国人にはデザインパターンじゃないと
通じなかったよ

**デフォルトの名無しさん** · 2017/09/30(土) 14:21:26.94

>>26
オブジェクト指向かどうかに関係ないが
内部構造を考える前にシステム境界の内側と外側のインタラクションをまず考えること
システム境界の内側と外側のインタラクションを定義するためには
各インタラクションを自然言語で明確に記述することからはじまる

それができれば一番外側のクラスのインターフェースを考える（慣れるまで内部状態は一緒に考えない）
次に一番外側のクラスのインターフェースをサポートするために必要な状態やクラスを考える
で新しく必要だと考えたクラスのインターフェースを考える
これを繰り返す

**デフォルトの名無しさん** · 2017/09/30(土) 14:26:12.80

>>26
- 「お金の投入」と「商品の購入」を別インタラクション？お金はどうやって投入するの？
- 「購入する()」は何も渡さず何も返さない？

↑こういう点が必要なインタラクションを把握できてないと感じるところ

**デフォルトの名無しさん** · 2017/09/30(土) 15:15:06.94

デザパタなんてまだマシだろ
外人なんてDPって書く奴ざらにいるぞ

**デフォルトの名無しさん** · 2017/09/30(土) 17:15:12.31

>>26
出庫(商品id, 出庫日, 個数)
入庫(商品id, 入庫日, 個数)

在庫管理 {
在庫数を取得する(p_商品id) {
a = (select sum(個数) from 入庫 where 商品id = p_商品id)
b = (select sum(個数) from 出庫 where 商品id = p_商品id)
return a - b
}
入庫する(商品id, 入庫日, 個数) {
insert into 入庫 (商品id, 入庫日, 個数)
}
出庫する(商品id, 出庫日, 個数) {
if (個数 > 在庫数を取得する()) throw 例外("在庫数が足りません")
insert into 出庫(商品id, 出庫日, 個数)
}
}

自販機 {
ボタンクリックイベント() {
商品id = 押されたボタンに紐付く商品idを取得する()
在庫管理.出庫(商品id, 現在時刻, 1)
押されたボタンに紐付く商品を取り出し口に落とす()
}
}

グローバル例外ハンドラ {
未処理例外イベント(例外) {
エラーログを出力する(例外)
}
}

**デフォルトの名無しさん** · 2017/09/30(土) 17:45:39.05

DAOさん

**デフォルトの名無しさん** · 2017/09/30(土) 18:37:38.64

>>43
- 無限に入庫できるの？
- ボタン押せばお金入れて無くても商品出してくれるの？
- 在庫数取得中にラスト1個の出庫が発生すると商品出てこないね

早まった詳細化はよくあるデスマーチパターン

**デフォルトの名無しさん** · 2017/09/30(土) 19:20:14.20

>>43
手続き型との違いが分からない

**デフォルトの名無しさん** · 2017/09/30(土) 19:22:12.04

>>45
要件に無いので無限に入庫できる
金銭の問題は質問者が別途考えることであり現在のコンテキストにはそぐわない
自販機において商品購入の並列処理は考慮しなくてよい

あまりにも馬鹿馬鹿しい指摘は今後スルーします

**デフォルトの名無しさん** · 2017/09/30(土) 19:27:44.53

結局デザパタは自販機クラスを構成する時の説明に使えないのか？
ならばデザパタは存在価値が無く、デザパタ厨はゴミだって事になるが。

俺の見立てでは、デザパタはセンスがない奴の勉強してますアピール時のアリバイ程度にしかならない。
肝心の構造実装を説明する時にも他の用語の方が適切だって時点でゴミ確定。
使い物にならないから誰も使わず、「本当に使われてるんですか？」という質問が発生する。
デザパタ厨は老害だよ。

デザパタが有用だと主張するなら、デザパタ用語でより分かりやすい説明を提供できないといけない。
そもそも俺はデザパタ厨は実装能力が全くなく、非デザパタ用語での説明すら出来ないと見ているが。

ついでに言うとsmalltalk信者もこういう時こそメッセージング指向(ｷﾘｯで
素晴らしい実装を披露するべきであるんだがな。

>>43
ところでそれは何言語で何指向なんだ？
(なお俺も>>45は揚げ足取りで、現段階で必要な議論ではないと思う)

**デフォルトの名無しさん** · 2017/09/30(土) 19:38:34.22

>>48
自販機クラスの構成の説明に使えないものはゴミなら、プログラミングの世界ってゴミばかりだねw

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

>>49
そもそもお前らデザパタ厨は「『何に役立つから』デザパタを学ぶべきだ」という主張なんだ？
当然だが俺は、何にも役に立たないからゴミだ、という主張だ。
実際ここで使わないで、いつ使うんだ？という状況だろ。

> プログラミングの世界ってゴミばかりだねw
他に何がゴミだと思っている？

**デフォルトの名無しさん** · 2017/09/30(土) 20:32:54.68

>>47
え、じゃ>>43を書いた意味というか目的はなんなの？

**デフォルトの名無しさん** · 2017/09/30(土) 20:34:28.53

>>39
だろうな

>>42
マシならいいという風潮

**デフォルトの名無しさん** · 2017/09/30(土) 20:47:17.95

>>50
> そもそもお前らデザパタ厨は「『何に役立つから』デザパタを学ぶべきだ」という主張なんだ？

デザパタ本を最初に読んだ時、
俺がそれまで悩んでいたり自分で考えた設計が
紹介されていたから、やっぱりちゃんとした
本で勉強したほうが時間の節約になると
実感したから学ぶべきだって主張

あんたの世界が狭いんだろ？
フレームワークを使って、その中身だけを書いてる人は使わないだろうさ
自分の作ったアプリにプラグインの仕組みを取り入れようとしたり
テキストエディタなんかを作ろうと考えたら、必ずと行っていいほど使うよ。

**デフォルトの名無しさん** · 2017/09/30(土) 20:58:31.09

>>51
そりゃ>>26への回答だろ。
つか、俺は君の>>40-41よりも>>43の方が直接的で分かりやすいと思うが。
全部実装する必要もないし。

>>43
俺は48で何指向かと聞いたがこれは間違いだった。
これはOOPだね。見落とした。すまん。

**デフォルトの名無しさん** · 2017/09/30(土) 21:05:07.39

>>53
> 自分の作ったアプリにプラグインの仕組みを取り入れようとしたり
> テキストエディタなんかを作ろうと考えたら、必ずと行っていいほど使うよ。
ほう。何パターンを使うんだ？
前者は「DLL」、後者は前回も言ったがundoなら｢逆方向履歴｣等で、デザパタ用語は不要だろ。
これ以上に明快な説明をデザパタ用語でやってみろよ。

**デフォルトの名無しさん** · 2017/09/30(土) 21:26:28.25

要件定義をきちんとすれば自然に辿り着くことだけど
自動販売機をモデル化する場合に核になるのはステートマシン
それを理解せず設計したりコードを書いたりすれば
>>45で指摘したような問題が後から後から出てくる

設計時もコーディング時も
事前/事後/不変条件を常に意識することが大事

**デフォルトの名無しさん** · 2017/09/30(土) 21:49:36.71

>>55
「デザパタ」が必要ないんじゃなくて
「デザパタ用語」が必要ないって
お前書いてるよね？ｗ

**デフォルトの名無しさん** · 2017/09/30(土) 21:53:10.48

デザインパターンな..

**デフォルトの名無しさん** · 2017/09/30(土) 22:04:28.64

逆方向履歴という機能を実装するのに
デザインパターンが使われている

**デフォルトの名無しさん** · 2017/09/30(土) 22:23:39.23

>>57
それは当たり前。
デザパタは登場時の時点で「既に頻出」な物に名前を付けただけ。
何も新しい物はない。普通にコード書けば使っている。
だから俺は「デザパタを別に勉強する意味はない」という立場。

>>59
> 逆方向履歴という機能を実装するのに
何パターン？
これにはパターンは無いはずだが。
（ただし俺は全て押さえているわけではないが）

**デフォルトの名無しさん** · 2017/09/30(土) 22:25:15.02

デザインパターンだっつってんだろ
馬鹿なの死ぬの？

**デフォルトの名無しさん** · 2017/09/30(土) 22:26:30.68

>>56
> 自動販売機をモデル化する場合に核になるのはステートマシン
これは多分違うぞ。
どのレベルからステートマシンと称するかにもよるが。

**デフォルトの名無しさん** · 2017/09/30(土) 22:26:30.88

> デザパタは登場時の時点で「既に頻出」な物に名前を付けただけ。

たしかに世界にとっては頻出だろう？
だが勉強中の人にとっては知らない知識だ

だからその人が世界に追いつくために
勉強しなければいけないってことだ

なぜ頻出なものを自分で考え出さないといけないのか
それこそ時間の無駄だ

**デフォルトの名無しさん** · 2017/09/30(土) 22:27:41.01

>>62
そこはステマシじゃねぇのかよ
中途半端な野郎だな

**デフォルトの名無しさん** · 2017/09/30(土) 22:31:39.91

結局デザパタを認めないやつは
自分で考えだしたものが
実は教科書に乗っているようなものと
認めたくないんだろうな。

**デフォルトの名無しさん** · 2017/09/30(土) 22:38:00.59

>>63
> なぜ頻出なものを自分で考え出さないといけないのか
> それこそ時間の無駄だ
使える物は全て言語機能に採り入れられてるから、言語を学べば「使い方」は理解出来る。
そしてせっかく覚えた「デザパタ用語」は使い道がない。
中途半端に抽象化した結果、「ストラテジーバターン」＝動的に対象関数を切り替える
とした場合、実装は「継承/委譲/関数ポインタ」等になり、実装時にはこれらの区別も重要な為、
「継承/委譲/関数ポインタ」が使われ、「ストラテジーバターン」が使われることはない。
だったら最初から言語機能をきっちり押さえた方がいい、というのが俺の立場。
(ただしJavaみたいな制限がきつい言語だと、言語だけ学んでも駄目だが)

**デフォルトの名無しさん** · 2017/09/30(土) 22:39:39.55

>>66
ストパタじゃねぇのかよ
馬鹿なの？

**デフォルトの名無しさん** · 2017/09/30(土) 22:40:17.60

> 使える物は全て言語機能に採り入れられてるから、言語を学べば「使い方」は理解出来る。

言語を学ぶの中にデザパタを学ぶが含まれているんだが？
なにを言ってるのだろうこいつは

**デフォルトの名無しさん** · 2017/09/30(土) 22:41:49.90

ストラテジーバターンは継承/委譲/関数ポインタを応用して
作り出すパターン

単体の道具（継承/委譲/関数ポインタ）を
複数組み合わせて構造を作るのがパターン

やっぱりデザパタ分かってないんだなｗ

**デフォルトの名無しさん** · 2017/09/30(土) 22:42:49.94

>>69
ストバタにしろやカス

**デフォルトの名無しさん** · 2017/09/30(土) 22:43:01.60

>>68
> 言語を学ぶの中にデザパタを学ぶが含まれているんだが？
これは初耳だが、どの言語のことだ？

**デフォルトの名無しさん** · 2017/09/30(土) 22:46:06.66

>>71
どの言語でも

継承ってなんですか？
→ 親クラスの機能をサブクラスが受け継ぐことです

継承を使うと何ができるんですか？
→ 応用例はいくつもあります。例えば～のような使い方が出来ます。
このような使い方を○○パターンといいます。

っていうように道具を使った応用例として
デザパタがでてくるだろ

お前は継承という道具を勉強するだけで
その継承のいろんな応用例まで勉強中のやつが思いつくと思ってんのか？

**デフォルトの名無しさん** · 2017/09/30(土) 22:49:13.24

>>69
> 単体の道具（継承/委譲/関数ポインタ）を
> 複数組み合わせて構造を作るのがパターン
これは俺は無駄なバリエーションで名前の数を増やしているだけという立場。
お前らはテンプレートメソッド＝継承という立場だったはずだが、
その場合、テンプレートメソッド、ストラテジー、コンポジットを別々にする意味はあるのか？
そして、この程度の差異で無駄に名前を増産する意味があるのか？
何の為にストラテジーパターンを抽象化したんだ？

**デフォルトの名無しさん** · 2017/09/30(土) 22:51:54.36

>>72
> → 応用例はいくつもあります。例えば～のような使い方が出来ます。
> このような使い方を○○パターンといいます。
ねーよアホ。
デザパタが書かれる前から継承はあったし、使われてる。
継承は継承としか書いてない。
お前はデザパタ洗脳用の教科書を掴まされたんじゃないのか？

**デフォルトの名無しさん** · 2017/09/30(土) 22:54:20.26

> その場合、テンプレートメソッド、ストラテジー、コンポジットを別々にする意味はあるのか？
使い方が違うからな。

第一な、無駄なリエーションで名前を増やしているというのなら、
言語なんて実は

・順次実行
・メモリ（I/O)読み書き機能
・演算機能
・（条件付き）ジャンプ機能

これだけの用語で十分。関数とか例外とかそんなものすらいない。
実際機械語はこのぐらいしか機能がない。
それ以外の機能は、これらの基本的な機能の応用例でしか無い。

だが、それだけじゃあまりにも基本的な機能すぎて
他の人と知識を共有できないから名前を増やすことで
短い単語で言いたいことを表現してるんだろうが

**デフォルトの名無しさん** · 2017/09/30(土) 22:54:51.73

>>73
テンメソだろ
なめてんのかてめぇ

**デフォルトの名無しさん** · 2017/09/30(土) 22:55:19.24

>>74
> デザパタが書かれる前から継承はあったし、使われてる。

だからなんだ。

使われてるその応用例をカタログ化したのが
デザインパターンなんだろ

プロが長年かけて最適なパターンを教科書に乗せて
初学者がすぐに追いつけるようにしたんだよ。

**デフォルトの名無しさん** · 2017/09/30(土) 22:57:54.56

> 継承は継承としか書いてない。

当たり前過ぎ・・・
基本と応用の違いも理解できんのか。

初学者に継承を教えるだけで、
すぐに応用例が思いつくわけ無いだろ

基本（継承）を教えてから、基本機能を組み合わせて
応用（パターン）を学ぶんだよ。

継承とパターンが違うんだから、
継承のストラテジーパターンって書くわけ無いだろｗ

継承＝ストラテジーパターンではない。
色んなパターンの中で継承が使われてる
ストラテジーパターン以外でも継承が使われている。
この２つの単語は同一ではない

**デフォルトの名無しさん** · 2017/09/30(土) 22:59:02.15

>>75
> 短い単語で言いたいことを表現してるんだろうが
おう、だからやってみろと>>55で俺は言ったはずだが、
お前も不都合なことは見えなくなる病気なんだな。

デザパタ用語は抽象度が中途半端すぎて、何にも使えない、というのが俺の立場。
まあ、>>55の回答を待つ。

**デフォルトの名無しさん** · 2017/09/30(土) 23:00:35.25

>>69
> 単体の道具（継承/委譲/関数ポインタ）を
> 複数組み合わせて構造を作るのがパタ
これは俺は無駄なバリで名前の数を増やしているだけという立場。
お前らはテンメソ＝継承という立場だったはずだが、
その場合、テンメソ、スト、コンポジを別々にする意味はあるのか？
そして、この程度の差異で無駄に名前を増産する意味があるのか？
何の為にストパタを抽象化したんだ？

**デフォルトの名無しさん** · 2017/09/30(土) 23:01:38.79

>>77
俺は>>72の
> どの言語でも　（中略）
> っていうように道具を使った応用例として
> デザパタがでてくるだろ
についてダウト！と言ってるんだよ。
理由は「継承」は「デザパタ」よりも古いから。

これに対する回答は？

**デフォルトの名無しさん** · 2017/09/30(土) 23:15:32.07

>>79
> おう、だからやってみろと>>55で俺は言ったはずだが、

そこがお前ずれてるんだよ。

デザパタは「やること」ではない
（誰かが）やったことの知識だ

すでに「やってる」ことに過ぎない
何をやれと言ってるのかさっぱりわからない。

**デフォルトの名無しさん** · 2017/09/30(土) 23:17:34.98

>>81
> 理由は「継承」は「デザパタ」よりも古いから。

古いから何なんだよ・・・

最初に継承が生まれ、それを使って
いろんなパターンが生み出された。

継承はパタ－ンよりも古くて当然だよ。

で「継承」は「デザパタ」よりも古いからなに？

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

>>78
> 初学者に継承を教えるだけで、
> すぐに応用例が思いつくわけ無いだろ
いやストラテジーパターンは応用例ですらない。使用例だ。
誰でも思いつくというか、この使い方をする為に設計された言語機能が継承だ。
そして使い方なら言語の説明で一通り為されて居るものだ。

> 継承＝ストラテジーパターンではない。
(意見としては)違うね。
継承を使った場合、ストラテジーパターンに該当しない物を作れない。
抽象度が異なる為、これらは確かに単語としては同じではないが、しかし、
「ストラテジーパターン」という単語を使って説明する適切な場合がない。
要らない単語をいたずらに増やしただけだ。

**デフォルトの名無しさん** · 2017/09/30(土) 23:20:26.38

>>80
> その場合、テンメソ、スト、コンポジを別々にする意味はあるのか？

応用例の説明見れば分かる通り
使い方が違うんだから意味あるだろうな。

シチューとカレーなんてどちらもほとんど同じ材料が使われてるが
別々の料理になってるだろ。

お前が言ってるのはそういうこと
いろんなパターンで継承が使われてるが、その継承の
使い方の違いでパターンの違いになるんだよ。

どっちも同じ材料が入ってるから、
「にんじん＋たまねぎ＋じゃがいも料理」だ！
じゃないの

**デフォルトの名無しさん** · 2017/09/30(土) 23:21:33.84

>>82
> 何をやれと言ってるのかさっぱりわからない。
お前は本当に馬鹿なのか？
日本語が通じないようならこの辺で打ちきりにするが。

俺は、
> 他の人と知識を共有できないから名前を増やすことで
> 短い単語で言いたいことを表現してるんだろうが (>>75)
について、>>55で求めた、
> 前者は「DLL」、後者は前回も言ったがundoなら｢逆方向履歴｣等
よりも簡単な説明をデザパタ用語でやれ、と言ってるんだが。

**デフォルトの名無しさん** · 2017/09/30(土) 23:21:47.75

>>84
> 誰でも思いつくというか、この使い方をする為に設計された言語機能が継承だ。

最初にストラテジーパターンというパターンがあって
継承が生まれただと？

ハハハ

逆

なぜなら

> 理由は「継承」は「デザパタ」よりも古いから。

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

>>83
なるほどお前は池沼なんだな。

> で「継承」は「デザパタ」よりも古いからなに？
デザパタ(1995)以前の「継承」を実装していた言語の仕様書、
例えば「プログラミング言語C++」(1983)において、
> どの言語でも　（中略）
> っていうように道具を使った応用例として
> デザパタがでてくるだろ (>>72)
があり得ない、と言ってるんだが。

**デフォルトの名無しさん** · 2017/09/30(土) 23:24:28.98

>>86

> 前者は「DLL」、後者は前回も言ったがundoなら｢逆方向履歴｣等
DLLはダイナミックリンクライブラリ
動的にリンクするライブラリと言うだけで、
それだけではどんなものかがわからない。

> undoなら｢逆方向履歴｣
逆方向履歴という機能を実現するにはいろんなやり方がある。
それだけではどんな設計を使うのかが決まっていない

その設計にどんなパターンを使うのが良いのか？
そこでデザインパターンの中から適切なものを探そう

**デフォルトの名無しさん** · 2017/09/30(土) 23:26:32.68

>>88
あ、お前今が2017年だってわかってなのか？ｗ

そりゃデザインパターンとしてカタログ化されてない
昔(1995)以前では、言語の勉強の中で
デザパタが登場するわけ無いだろｗｗｗ
昔（お前の時代）にはデザパタ出てこないの当たり前だよーーーーｗ

今は言語の勉強の中で基本の応用として
デザパタを学習するんだよ。

**デフォルトの名無しさん** · 2017/09/30(土) 23:27:35.90

いや、まかさ

俺の子供の時代にはそんなこと習わなかった

が根拠になっていたとはなｗｗｗ
草ｗｗｗ

**デフォルトの名無しさん** · 2017/09/30(土) 23:29:01.75

>>87
> 最初にストラテジーパターンというパターンがあって
> 継承が生まれただと？
お前は本当に馬鹿だな。

継承の典型的な使用例に「ストラテジーパターン」という名前を付けただけだ。
だけど実際は「継承」で全く問題なくて、しかも無駄に抽象化したから使いどころもなくなった。

というかどうやらデザパタ厨はマジで馬鹿で議論が出来ないのは分かった。
他の言葉が通じる連中が出て来たら再開する。

**デフォルトの名無しさん** · 2017/09/30(土) 23:31:17.52

>>87
> 最初にストラテジーパターンというパターンがあって
> 継承が生まれただと？
お前は本当に馬鹿だな。

継承の典型的な使用例に「ストパタ」という名前を付けただけだ。
だけど実際は「継承」で全く問題なくて、しかも無駄に抽象化したから使いどころもなくなった。

というかどうやらデザパタ厨はマジで馬鹿で議論が出来ないのは分かった。
他の言葉が通じる連中が出て来たら再開する。

**デフォルトの名無しさん** · 2017/09/30(土) 23:31:34.77

> 継承の典型的な使用例に「ストラテジーパターン」という名前を付けただけだ。

継承の応用例の一つとして「ストラテジーパターン」がある
応用例の一つであるということからもわかるように
継承を使った応用例はいくつも有るから

継承と言っただけで「ストラテジーパターン」を意味することにはならない。
だから「使い方」を言いたいときには「ストラテジーパターン」という必要がある。

継承はベースとなる機能
その継承の使い方がパターンなのである

**デフォルトの名無しさん** · 2017/09/30(土) 23:32:35.29

>>89
> その設計にどんなパターンを使うのが良いのか？
> そこでデザインパターンの中から適切なものを探そう
それも俺は要求済みだ。早く答えろ。

> > 逆方向履歴という機能を実装するのに
> 何パターン？ (>>60)

お前は典型的な「都合が悪い物は見えない病気」だな。
まあこの議論を見れば、デザパタ厨がどれだけゴミか分かるだろうから、お前らの布教も捗るだろうよ。

**デフォルトの名無しさん** · 2017/09/30(土) 23:33:05.80

> 継承の典型的な使用例に「ストパタ」という名前を付けただけだ。

継承の典型的な使用例と何度も言っていることからわかるように

ストラテジーパターンは継承の使用例の一つでしか無い
だから継承といっても使用例が定まるわけではない。

何度も言うぞ

継承の「典型的な使用例」がストラテジーパターンである

**デフォルトの名無しさん** · 2017/09/30(土) 23:35:25.33

>>94
だから
・継承を使っているがストラテジーパターンには非該当
の例を出せるか？多分無理なんだよ。だから、
> だから「使い方」を言いたいときには「ストラテジーパターン」という必要がある。
この分離は必要ないんだよ。
この言い方では通じないとは思うが。

**デフォルトの名無しさん** · 2017/09/30(土) 23:36:17.57

何度も言うぞ

継承の「典型的な使用例」がストラテジーパターンである

継承の使用例の一つがストラテジーパターンであるが
継承の利用例は他にも有る。

では聞こう

継承とは何パターンか？
答えるわけがない。

継承の使用例の一つがストラテジーパターンであるが
継承の他の利用例は別のパターン名がついているからである。

継承は道具。使用例がパターン。
使用例であるパターン名を言わないと、
どんな使用例かは答えられない

何度も言うぞ

継承の「典型的な使用例」がストラテジーパターンである 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

**デフォルトの名無しさん** · 2017/09/30(土) 23:37:23.69

もうそろそろ、継承の「典型的な使用例」がストラテジーパターンである
という言葉の意味が理解できたことだろうか？

そう使用例がパターンなのである

**デフォルトの名無しさん** · 2017/09/30(土) 23:37:53.05

>>94
だから
・継承を使っているがストパタには非該当
の例を出せるか？多分無理なんだよ。だから、
> だから「使い方」を言いたいときには「ストラテジーパターン」という必要がある。
この分離は必要ないんだよ。
この言い方では通じないとは思うが。

**デフォルトの名無しさん** · 2017/09/30(土) 23:38:34.58

>>94,96,98,99
>>97読め、そして以下の例よろしく
・継承を使っているがストラテジーパターンには非該当

**デフォルトの名無しさん** · 2017/09/30(土) 23:39:35.12

>>94,96,98,99
>>97読め、そして以下の例よろしく
・継承を使っているがストパタには非該当

**デフォルトの名無しさん** · 2017/09/30(土) 23:40:59.93

>>100

> ・継承を使っているがストパタには非該当
> の例を出せるか？

だせるが？

継承を使っている他のパターンはいくつも有るだろ？
だが、そのほかのパターンまで必要ない
継承の「使用例」がストラテジーパターンだ。

**デフォルトの名無しさん** · 2017/09/30(土) 23:49:17.59

一つのクラスが複数のパターンを使っているってことは有るが
有るパターンが有るパターンを内包しているってのはない。

継承を使ってる他のパターンがストラテジーパターンを内包していること無い。

なぜそんな愚かな勘違いをするのか？

それはストラテジーパターンという使用例を
基本機能である継承と同一視しているからだ。

継承を使っているパターンはあるが
それはストラテジーパターンとして使っているわけではない。

継承とストラテジーパターンを同一視しているから、
そんな馬鹿な結論に至る。

これこそが、継承（基本機能）と応用（使用例）を
別々にしておくべきだという回答の一つでも有る

**デフォルトの名無しさん** · 2017/09/30(土) 23:51:38.51

> Strategy パターンは、コンピュータープログラミングの領域において、アルゴリズムを実行時に選択することができるデザインパターンである。

と説明してあるように

アルゴリズムを実行時に選択しないのであれば
それはストラテジーパターンではない

継承を使っているからと言って実行時に選択するとは限らないからな

アルゴリズムを実行時に選択したい（使用例）ときに使うのが
ストラテジーパターンである

**デフォルトの名無しさん** · 2017/09/30(土) 23:55:48.04

>>105
だから、継承を使っていて、
> アルゴリズムを実行時に選択しない
例を挙げてみろ、と言ってるんだよ。

**デフォルトの名無しさん** · 2017/10/01(日) 00:01:15.13

例えばRailsアプリだと一般的にモデルはActiveRecordクラスを継承して作るが
実行時にアルゴリズムを変えたりはしない

**デフォルトの名無しさん** · 2017/10/01(日) 00:03:26.64

>>107
ではそれは何の為に継承しているんだ？

**デフォルトの名無しさん** · 2017/10/01(日) 00:07:41.09

ActiveRecordクラスで実装されている
機能を利用するために決まってるだろｗ

蛇足だが

ActiveRecordクラスを使わないモデルもあって
その場合は例えばActiveModelを使う。

だが面白いことに、ActiveRecordクラスは継承するが
ActiveModelは継承ではなくinclude（MixIn）する

実際の所コードを再利用することが目的なので
継承以外にもやり方はあるということだ。

そう考えるとActiveRecordも継承するのは必須ではないということになるな。

まあ蛇足だがｗ

**デフォルトの名無しさん** · 2017/10/01(日) 00:12:57.26

>>109
> そう考えるとActiveRecordも継承するのは必須ではないということになるな。
当たり前だ。
virtualに対して全くoverrideしないのなら継承の意味はない。
それはある意味、典型的な間違った使い方だ。
そしてお前はそれも分からない馬鹿だということ。

**デフォルトの名無しさん** · 2017/10/01(日) 00:13:18.18

トーンが明らかに下がってきたなｗ

ようやくこのバカも理解出来あってことか。
デザインパターンは使用例（応用例）であって

そこで継承を使っているからって
継承が使用例（応用例）になるわけじゃない

ストラテジーパターンはアルゴリズムを実行時に
選択することができるようにするためのデザインパターン
そこで継承が使われていることは重要ではない。

継承を使うパターンは他にも有る。
使用例（応用例）が論点なのであって、何を使っているかは
デザインパターンとして考えるときには重要な事ではない。

**デフォルトの名無しさん** · 2017/10/01(日) 00:16:02.84

>>110
> virtualに対して全くoverrideしないのなら継承の意味はない。
（そこからかーｗ）

**デフォルトの名無しさん** · 2017/10/01(日) 00:16:29.39

>>111
は？下がってないぞ。
俺はデザパタ＝ゴミ、デザパタ厨＝ゴミ、で変わりない。
ただしお前が馬鹿すぎて議論は無理だからフェードアウト気味なだけ。

**デフォルトの名無しさん** · 2017/10/01(日) 00:17:15.28

自分だけはバカじゃないという前提

**デフォルトの名無しさん** · 2017/10/01(日) 00:21:43.29

>>113
でも、継承の「典型的な使用例」がストラテジーパターンである
という言葉に反論できてないじゃないですかーｗ

所詮、継承は使用例の一つなんですよ。
ストラテジーパターンを継承と言ってしまうと

他の継承を使っているパターンは、すべてストラテジーパターン
アルゴリズムを実行時に選択することができることが重要
だってことになるじゃないですかーｗ

意味不明ですよね

これはデザパタがゴミなんじゃなくて、
すべてはあんたのストラテジーパターンを継承と呼ぶから
こういう意味不明な結論にいなるわけですよ。

そうならないように、基本機能（継承）とその応用例（パターン）
きっちり分けて考えましょうって話なるわけ

何度も言いますよ？
継承の「典型的な使用例」がストラテジーパターンである
「典型的な使用例」です。

**デフォルトの名無しさん** · 2017/10/01(日) 00:29:59.36

>>115
間違った使い方はいくらでも出来るんだよ。言い換えれば、
・継承の正しい使用例は常にストラテジーパターンになる
でいいか？

overrideしないで継承するってのは典型的な「便利関数置き場」であって、
駄目だろこれは。
というか、これがありならパターンにあるべきだが、無いだろさすがに。

**デフォルトの名無しさん** · 2017/10/01(日) 00:31:39.13

>>115
間違った使い方はいくらでも出来るんだよ。言い換えれば、
・継承の正しい使用例は常にストパタになる
でいいか？

overrideしないで継承するってのは典型的な「便利関数置き場」であって、
駄目だろこれは。
というか、これがありならパタにあるべきだが、無いだろさすがに。

**デフォルトの名無しさん** · 2017/10/01(日) 00:32:27.29

> ・継承の正しい使用例は常にストラテジーパターンになる
> でいいか？

継承の正しい使用例は常に「アルゴリズムを実行時に選択することができる」
ためのも。

うん。明らかに間違いだなｗ
実行時に選択できる必要ないし

**デフォルトの名無しさん** · 2017/10/01(日) 00:33:52.13

>>117
> overrideしないで継承するってのは典型的な「便利関数置き場」であって、
> 駄目だろこれは。

だめでもなんでもない。

有るクラスが、有るクラスを踏まえているならば
（is-a関係）それを表現するために継承を使うべき

継承っていうのは「便利関数置き場」じゃないのよ？
それらの関数を使わなかったとしても
継承関係にあれば継承を使うんだよ。

**デフォルトの名無しさん** · 2017/10/01(日) 00:35:47.35

overrideしない使い方として例えばRuntimeErrorみたいなのがあるな
その他の実行時エラークラスはRuntimeErrorを継承して作る。

そうすることで、全ての実行時エラークラスをRuntimeErrorとして
みなすことができるし、一部のクラスだけは例外的に
その他の情報をエラークラスに格納することができる。

**デフォルトの名無しさん** · 2017/10/01(日) 00:46:34.86

>>119
それはまた違う話だ。
1本道で複数継承している場合は、将来的に分岐したり交換される可能性等を踏まえているだけ。
絶対に分岐しないと分かり切っている場合に継承する意味はないだろ。

例えば、メソッド一つ一つ全部バラして継承させて、メソッド20個で継承20階層も出来るが、無駄だろ。
将来的にも絶対にoverrideされないのなら最初から継承構造なんて必要ないんだよ。
ベタにクラス作って終わりだ。

>>120
それはoverrideと同じ、というか、メソッドではなくメンバのoverrideになる。

**デフォルトの名無しさん** · 2017/10/01(日) 00:49:35.69

これのどこがメンバのオーバーライドをしているのか説明してほしいもんなんだがｗ

http://blog.toshimaru.net/ruby-standard-error/

# `Exception`ではなく
class MyError1 < Exception; end
# `StandardError`.
class MyError2 < StandardError; end

**デフォルトの名無しさん** · 2017/10/01(日) 00:51:22.19

>>121
お前さ、基本

1. 自分が○○にたいして馬鹿なことを言う
2. 自分が言った馬鹿なことの対して馬鹿だと自分でツッコむ
3. そのツッコミを根拠に、○○はダメだという

というやり方やってるよね？

○○がだめなんじゃなくて
お前がダメなんだよｗ

**デフォルトの名無しさん** · 2017/10/01(日) 00:53:40.85

が、まあ、これらは通常は区別されているから、以下としよう。
・メソッドの継承の正しい使用例は常にストラテジーパターンになる
・メソッド/フィールド等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない
これでいいか？

**デフォルトの名無しさん** · 2017/10/01(日) 00:54:50.31

何かよくわからんけどおもしろいなそれ

**デフォルトの名無しさん** · 2017/10/01(日) 00:57:27.86

> ・メソッドの継承の正しい使用例は常にストラテジーパターンになる

ならないって何度も言ってるんだがｗ

> ・メソッド/フィールド等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない

意味はある。その例も出した。

結局さぁ、お前、実装のことしか考えられてないんだよ。
設計能力が圧倒的に不足している。

どんな設計を見た所で、その実装が継承使っていれば、
これは継承と呼ぶべきだーって叫ぶつもりだろ？

**デフォルトの名無しさん** · 2017/10/01(日) 00:59:36.43

設計とはかならず「何のために」そういう設計をするのかという
目的が有る。それがデザパタの使用例や応用例なんだよ。

継承は「何のために」ではなく実現技術

だから継承といっただけでは何をしたいのか全くわからない。
だからデザインパターンで定義されている名前が必要

**デフォルトの名無しさん** · 2017/10/01(日) 01:01:17.79

が、まあ、これらは通常は区別されているから、以下としよう。
・メソの継承の正しい使用例は常にストパタになる
・メソ/フィー等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない
これでいいか？

**デフォルトの名無しさん** · 2017/10/01(日) 01:02:05.70

> ・メソッドの継承の正しい使用例は常にストラテジーパターンになる

ならないって何度も言ってるんだがｗ

> ・メソッド/フィールド等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない

意味はある。その例も出した。

**デフォルトの名無しさん** · 2017/10/01(日) 01:03:39.76

>>122
おれはRuby使いではないからチラ見ではよく分からんが、
見る限りrescueの仕様によるものであって、
Exceptionは派生しまくってるし、特に変だとも思わないが。

**デフォルトの名無しさん** · 2017/10/01(日) 01:05:28.40

>>130
メソッド/フィールド等全てについて（将来的にも)全くoverrideしない
継承の正しい使い方だって言ってる

**デフォルトの名無しさん** · 2017/10/01(日) 01:05:32.81

>>129
とりあえずID見る癖付けろ。
俺のレスは粘着により複製されてるから。

**デフォルトの名無しさん** · 2017/10/01(日) 01:07:40.92

>>126
> どんな設計を見た所で、その実装が継承使っていれば、
> これは継承と呼ぶべきだーって叫ぶつもりだろ？
そりゃそうだろ。
お前は継承使ってても「これは継承ではない！」というのか？

**デフォルトの名無しさん** · 2017/10/01(日) 01:09:09.45

>>131
いや派生しまくってんだから、既にoverrideされまくっているはずだが。

**デフォルトの名無しさん** · 2017/10/01(日) 01:10:27.50

>>133
> お前は継承使ってても「これは継承ではない！」というのか？

いや？継承使っていてもストラテジーバターンでなければ
ストラテジーパターンではないと言うつもりだよ？

お前はストラテジーバターン＝継承と呼ぶべきだって言ってるんだから、
お前はストラテジーパターンでないパターンを見ても、
ストラテジーバターン（＝継承）だって言うんでしょ？

っていう話をしてるんだが？

**デフォルトの名無しさん** · 2017/10/01(日) 01:11:52.96

>>132
あんたが表現のロジックを統一しないから代弁してやってんだよ

**デフォルトの名無しさん** · 2017/10/01(日) 01:12:07.31

>>134
え？なに？

世界中の何処かで誰かがオーバーライドしていれば
それは継承使っていいって言ってるわけ？

その理屈だと継承が適切じゃないものなんてないだろうな。
世界中の何処かで誰かはオーバーライドしてるだろうさ
たとえそれが便利関数であったとしても

**デフォルトの名無しさん** · 2017/10/01(日) 01:14:01.94

>>135
> お前はストラテジーバターン＝継承と呼ぶべきだって言ってるんだから、
そうとは言ってない。俺は、
・（正しい用法で）メソッドを継承した場合、ストラテジーパターンは自動的に適用されるから、
わざわざ「ストラテジーパターン(ｷﾘｯﾂ」なんて言う機会も意味もない
という立場だ。
抽象度は違うが、分離不可能だし、分離する意味もないから通常は「継承」という言葉が使われる、ということ。

**デフォルトの名無しさん** · 2017/10/01(日) 01:15:16.80

>>135
> お前はストラテジーバターン＝継承と呼ぶべきだって言ってるんだから、
そうとは言ってない。俺は、
・（正しい用法で）メソを継承した場合、ストパタは自動的に適用されるから、
わざわざ「ストパタ(ｷﾘｯﾂ」なんて言う機会も意味もない
という立場だ。
抽象度は違うが、分離不可能だし、分離する意味もないから通常は「継承」という言葉が使われる、ということ。

**デフォルトの名無しさん** · 2017/10/01(日) 01:18:01.30

>>137
意味不明。

RubyのExceptionは派生しまくっている＝メソッド/フィールド等が既に追加/上書きされているはずであり、
これは正しい継承の使い方である、ということ。

**デフォルトの名無しさん** · 2017/10/01(日) 01:19:25.82

>>138
> ・（正しい用法で）メソッドを継承した場合、ストラテジーパターンは自動的に適用されるから、
されない。

されると思っているのはお前がストラテジーバターン（設計用語）を
勝手に継承（実装用語）と読んでいるから、

何度も言うが設計は使用例（応用例）、つまり目的が有る
「アルゴリズムを実行時に選択することができる」
という目的があってこそストラテジーバターンと呼ぶことができるのであって
この目的がなければ、継承を使っていたからと言ってストラテジーバターンにはならない

設計用語を使わないからお前は「継承を使っているものはすべて継承だー！」という
意味不明なことをいうつもりだろって言ってんの。

設計用語を使っていれば「継承を使っているものはすべてストラテジーバターンだー！」
という事になって言葉的には意味不明なことにはならない。
もちろんこれが間違っているのは先に言ったとおり。

設計能力が足りないよ？

**デフォルトの名無しさん** · 2017/10/01(日) 01:20:27.48

>>140
> RubyのExceptionは派生しまくっている＝メソッド/フィールド等が既に追加/上書きされているはずであり、
いや上書きされてない。
上書きする必要ようもないしな。

**デフォルトの名無しさん** · 2017/10/01(日) 01:25:04.92

>>142
メンバは追加されてるだろ。（多分）
全く同じで階層だけ与えてエントリポイントをずらしているのか？
走だとしたらかなり奇妙な使い方だとは思うが。

**デフォルトの名無しさん** · 2017/10/01(日) 01:26:45.20

>>142
メンバは追加されてるだろ。（多分）
全く同じで階層だけ与えてエンポイをずらしているのか？
走だとしたらかなり奇妙な使い方だとは思うが。

**デフォルトの名無しさん** · 2017/10/01(日) 01:30:18.31

>>143
> メンバは追加されてるだろ。（多分）
オーバーライドの話だっただろ。アホめｗ

例外クラスは、クラスの階層構造を表現するのに
継承が適切だから継承を使ってる。
すべてのErrorはExceptioであり、実行時に発生するのは
StandardErrorであり、ファイルIOに関するエラーはIOErrorである
という風にだ。

これは設計として正しい。

オーバーライドするかどうかは些細な問題にすぎない。
重要なのは各クラスにどういう関係があって（これが設計）
それをどう言語で表現するか（これが実装）だ

お前がずっとやってるのは、実装だけしか見てないってことだよ。

**デフォルトの名無しさん** · 2017/10/01(日) 01:30:53.56

>>141
言いたいことは分かるが、平行線だな。

**デフォルトの名無しさん** · 2017/10/01(日) 01:32:35.82

>>146
お前は言いたいことがわかる（俺が言ってることを理解した）
俺はお前が言いたいことがわからない

平行線ではない

**デフォルトの名無しさん** · 2017/10/01(日) 01:34:40.94

>>145
それも既に書いたけどね。
>>124読め。

とはいえ平行線ならそれでいい。

**デフォルトの名無しさん** · 2017/10/01(日) 01:36:17.23

>>146
すべてはお前が

ストラテジーバターンは継承を使ってるから
設計用語ではなく実装用語の継承と呼びましょう

そうするとストラテジーバターンなんて用語はいらないですよね？
ってことはデザパタ用語は全ていらないんじゃないですか？

使う目的なんか気にせず、実装に継承を使っていれば
全部継承と呼びましょうよ

だからデザパタは意味がない。ゴミ

というばーかな。理屈を言い出したのが悪い。

**デフォルトの名無しさん** · 2017/10/01(日) 01:36:22.99

>>147
> 俺はお前が言いたいことがわからない
じゃあ全部読み直せ。
それで分からないのなら、俺かお前の日本語が駄目駄目なだけであり、
どちらにしてもこれ以上は無理だ。

**デフォルトの名無しさん** · 2017/10/01(日) 01:36:32.17

>>145
それも既に書いたけどね。
>>128読め。

とはいえ平行線ならそれでいい。

**デフォルトの名無しさん** · 2017/10/01(日) 01:38:16.54

>>150
お前の日本語がダメダメだってことだろｗ

お前はコンテキストを理解してない。
設計の話をしている時に実装の話をすんな

**デフォルトの名無しさん** · 2017/10/01(日) 01:40:22.72

使う目的が違うのに、実装に継承が使われているだけで
全部継承と呼ぶな。それは実装用語だ

ストラテジーバターンの目的として使ってない時に

ストラテジーバターンは継承♪
継承を使っていればストラテジーバターン♪
だから全部ストラテジーバターン♪

とか言い出すなボケ

ストラテジーとは別のバターンとして使っているときは
実装に継承が含まれていようが別のパターンだ

**デフォルトの名無しさん** · 2017/10/01(日) 01:42:14.15

>>149
>>66,79,84読め
現実的に使えないから使われてないのだと思うぞ。
これも平行線ならそれでいいが。

>>153
そんなことは言ってないんだが、そう読めたのならそれでいい。

**デフォルトの名無しさん** · 2017/10/01(日) 01:43:39.80

> 現実的に使えないから使われてないのだと思うぞ。

現実的に使われてるから、使われてるとしか言いようがない

**デフォルトの名無しさん** · 2017/10/01(日) 01:44:39.83

>>154
ストラテジーパターンって何？
ストパタのこと？

**デフォルトの名無しさん** · 2017/10/01(日) 01:45:19.08

例えば、Railsのモデルに使われているActiveRecordというのは
もともとPoEAAのActiveRecordパターンという
パターンを実装したものだ

あまりにもRailsが有名になりすぎてRailsのものだと
勘違いしている人がいるぐらいにな。

これだけでも有名で大規模な利用例と言えよう

**デフォルトの名無しさん** · 2017/10/01(日) 01:46:37.91

>>155
> 現実的に使われてるから、使われてるとしか言いようがない
これって前から聞いてるけど、お前のリアルなの？

**デフォルトの名無しさん** · 2017/10/01(日) 01:49:44.09

>>158
あぁ、レスが遅かったな。
すでにデザインパターンが使われてる例を一つ出したところだ

デザインパターンが使われていない証拠を出せ
デザインパターンが使われている証拠を出せ

これは

幽霊がいないという証拠を出せ
幽霊がいるという証拠を出せ

という話と似ている。幽霊がいないことを証明するのは難しいが
幽霊がいるという証明をするのは簡単
一匹でも幽霊を見つけてくればいい。

だから俺はデザインパターンが使われてる例を一つ出した。
お前は難しい方から攻めてくれ。デザインパターンが使われていないという証明をしろ。

**デフォルトの名無しさん** · 2017/10/01(日) 01:52:23.50

>>157,159
そうだとしてさ、その場合、
「AcriveRecordオブジェクトを継承しといてね」とは言うけど、
「AcriveRecordパターン使ってね」とは言わないだろ、普通。

**デフォルトの名無しさん** · 2017/10/01(日) 01:56:02.10

#define パターンパタ
#define デザインパターンデザパタ
#define ストラテジーパターンストパタ
#define メソッドメソ
#define フィールドフィー
これでだいぶコード量が小さくできる

他に入れとくべきものある？

**デフォルトの名無しさん** · 2017/10/01(日) 01:56:44.56

>>160
だからお前は実装のことしか見れてないっていってんだよｗｗ
視野が狭すぎ

「AcriveRecordオブジェクトを継承しといてね」は実装の話だ

「AcriveRecordパターン使ってね」は設計の話だ。
（実際には誰かに頼まれて使ったのではなくRailsの生みの親のDHHが
考慮した結果AcriveRecordパターンを使っわけだが）

お前は設計がすんだあとの立場からしか見えてないんだよ。
お前の書き込み自体が「○○しといてね」と指示を出される側から見てるのがその証拠
お前は誰かがやった設計の通りに、実装することしかしたことがないんだろ？

**デフォルトの名無しさん** · 2017/10/01(日) 02:01:22.65

実装は思想やモデル、指針を定義するパターンを実現する手法のひとつにすぎない
それだけのことだよね

**デフォルトの名無しさん** · 2017/10/01(日) 02:03:57.54

>>162
いや、指示を出す立場でも同じ言葉だと思うが。

よく知らないが、
> ActiveRecordのようなO/Rマッパーを使うと、
> オブジェクト指向プログラミングができるのはもちろん、
> モデル層の永続化のコードを基本的にライブラリ任せにできるので、
> SQLを記述する煩わしさを避けることができます。
> http://www.atmarkit.co.jp/ait/articles/1104/12/news135.html
つまり俺なら普通に「O/Rマッパー」って言うぞ。
それを厨二に「ActiveRecord(ｷﾘｯ」と名付けるのは勝手だが、
何故俺がいちいち名前を覚えないといけないのだ？

**デフォルトの名無しさん** · 2017/10/01(日) 02:05:21.68

>>164
ソフトウェア設計者ならパターンくらい覚えるものだろう
仕様書を元に実装するコーダーなら別だが

**デフォルトの名無しさん** · 2017/10/01(日) 02:08:23.29

>>165
むしろ覚えるべきは「O/Rマッパー」（一般用語）であって、
「ActiveRecord」（Rails方言）ではないだろ。

**デフォルトの名無しさん** · 2017/10/01(日) 02:08:24.39

普通、設計は「○○パターンを使ってね」なんて言わないからなぁ。

言うとしたら「○○パターンを使いましょう」だ
なにもない所から使うパターンを考えることが設計作業なんだから。

設計者が実装者に指示を出すとしたら
「○○パターンを使いますから、必要なクラスを実装してください」か
もしくは「○○パターンを使います。そのために必要なクラスの一部を作りましたから、
あなたは○○オブジェクトを継承しといてね」になるだろう。

そう実装の話。実装の立場からしか物事を見れてないから
設計をすることの意味すらもわからず
設計に実装と同じような指示が存在すると墓穴をほってしまう。

**デフォルトの名無しさん** · 2017/10/01(日) 02:09:16.78

>>166
O/RマッパーとActiveRecordは同じ意味ではない。
まずそこから勉強することが大事だよな？

**デフォルトの名無しさん** · 2017/10/01(日) 02:11:38.94

>>166
Active Recordというワードで鬼の首取るしかなくなってるように見える
議論の本質はそこではないともうひと方は言っていることがはたから見てても汲み取れる

**デフォルトの名無しさん** · 2017/10/01(日) 02:12:56.51

まあ、ご教授してさしあげると（笑）

O/Rマッパーは設計を意味する用語ではない
なにかのオブジェクトとデータベースをマッピングする
という目的のためにライブラリ・フレムワークの種類のことだ。

O/Rマッパーと言ってもそこにどんな設計が使われているかはわからない。
ActiveRecordパターンを使ってるかもしれないし
Table Data Gatewayパターンを使ってるかもしれないし
Row Data Gatewayパターンを使ってるかもしれないし
Data Mapperパターンを使ってるかもしれない

**デフォルトの名無しさん** · 2017/10/01(日) 02:14:56.98

RailsのActiveRecordは
その名前の通りPoEAAのActiveRecordパターンを
実装したO/Rマッパーである

別にO/Rマッパー全てがActiveRecordパターンというわけではない

**デフォルトの名無しさん** · 2017/10/01(日) 02:15:32.16

>>168
はいはい、「O/Rマッパー」と「ActiveRecord『パターン』」な。
つかこの辺は普通に脳内補完しろよマジで。

>>167
それ前から疑問で何度も聞いているのだが、お前のリアルでは
> 「○○パターンを使いましょう」
と言っているのか？

これも何度も言っているが、ストラテジーパターンに該当するとして、
その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
現実的に「ストラテジーパターンで行きましょう」なんて議論は無理で、
「ここは委譲にしとく？」みたいなことにならないか？

**デフォルトの名無しさん** · 2017/10/01(日) 02:16:17.79

まとめると、基本設計(パターン)とそれを実現するために使う道具(ライブラリ等の具体的な実装)の区別をちゃんとつけて設計しましょう
ってことでFA？

**デフォルトの名無しさん** · 2017/10/01(日) 02:17:03.31

Java の Hibernate という O/Rマッパーが
Data Mapperパターンを使っている

http://d.hatena.ne.jp/naoya/20051024/1130146687

> テーブルの構造とクラスの設計に乖離がある場合、
> その乖離を埋めるためのマッピングを用意してやる必要がある、
> これが Data Mapper パターン。Java の Hibernate とかが
> Data Mapper による O/R マッピング実装。

**デフォルトの名無しさん** · 2017/10/01(日) 02:18:34.76

>>172
O/Rマッパーの実装として

ActiveRecordパターンを使ったRailsのActiveRecordと
DataMapperパターンを使ったJavaのHibernateを紹介した

ここからもO/Rマッパーという用語では
設計がわからんという話に納得できただろ？ｗ

**デフォルトの名無しさん** · 2017/10/01(日) 02:18:59.84

>>170,171
それくらいは分かるが、と言うより、

・O/Rマッパー＝OとRをマッピングするもの

であって、それ以上でも以下でもないんだよ。
ただし、中身の実装を知らなくていいというのがOOPであって、それで終わり。

**デフォルトの名無しさん** · 2017/10/01(日) 02:20:16.08

> ただし、中身の実装を知らなくていいというのがOOPであって、それで終わり。

ア、ハイ、実装者側の立場からしか見えてないんですよね？ｗ

中身の設計ぐらい知らなきゃｗ

**デフォルトの名無しさん** · 2017/10/01(日) 02:21:21.14

少しずつ主張を変えていって最初からそう言ってるんだがってことにする論法って俗に何て言うの？

**デフォルトの名無しさん** · 2017/10/01(日) 02:21:59.93

ちょっとまてｗ
終わった話を蒸し返す論法も使ってるぞｗ

**デフォルトの名無しさん** · 2017/10/01(日) 02:26:02.99

>>174
そのURL読んだけど、それって多分単純にその実装をそう呼んだだけであって、
いわゆるデザパタ(GoF)とはだいぶ主旨が異なるぞ。
まあそれを有り難がるのも自由だが。

**デフォルトの名無しさん** · 2017/10/01(日) 02:28:09.18

実装者は使うライブラリ・フレームワークの設計をしらないと
めちゃくちゃになるからな。

例えば昔、トランザクションスクリプトパターンと
単なるSQLライブラリばかり使ってきた人が
別プロジェクトでPythonのDjango（これもActiveRecordパターン）を
使ったんだが散々な結果だったよ。

フレームワークとしてActiveRecordパターンを要求されるが
そこにActiveRecordパターンではやらないようなコード
（SQLを実行するだけのようなメソッド）をクラスに生やしたりして。

Djangoフレームワークの実装の中身は見なくてもいいけど
そこで使われている設計はちゃんと理解していなければダメだ。

**デフォルトの名無しさん** · 2017/10/01(日) 02:28:25.53

あるOOPベースのライブラリを使うことで結果的にあるデザインパターンに沿うことになるライブラリと、いろんなデザインパターンを実現するのに使えるより純粋な道具としてのライブラリがあると思うの
そこはちゃんと分離して話をしないとダメだと思うの

**デフォルトの名無しさん** · 2017/10/01(日) 02:28:51.27

>>180
お前（今までの流れから明らかに力不足）の
感想なんていらんがなｗ

**デフォルトの名無しさん** · 2017/10/01(日) 02:30:10.95

一応俺のスタンスは最初から変わってないつもりだぞ。
・デザパタはゴミ
・デザパタ厨もゴミ
・デザパタ用語は使い道がないからゴミ

**デフォルトの名無しさん** · 2017/10/01(日) 02:31:34.05

>>184
そうだろうね
そしてそれはソフトウェア設計者としては二流以下だというのがこれまでの話の流れだと思うの

**デフォルトの名無しさん** · 2017/10/01(日) 02:31:45.57

>>184
もう一つ。

・俺は無能なバカ

これも加えとけｗ
今までの流れで明らかになったしな

**デフォルトの名無しさん** · 2017/10/01(日) 02:32:31.62

>>181
それはある。
しかしそれは「フレームワークの中身を知っておけ」であって、「デザパタを知っておけ」ではない。

**デフォルトの名無しさん** · 2017/10/01(日) 02:34:18.00

>>186
というより
・俺はデザインパターンとかめんどくさいから勉強したくないの
だと思う

**デフォルトの名無しさん** · 2017/10/01(日) 02:35:51.52

>>182
一応それは世間的には区別されているらしいぞ。(wikiだと思ったが、今探したがない)
・自分が思うように使うのがライブラリ
・フレームワークの場合は、自分が合わせる

**デフォルトの名無しさん** · 2017/10/01(日) 02:36:36.93

>>187
> しかしそれは「フレームワークの中身を知っておけ」であって、「デザパタを知っておけ」ではない。

「フレームワークで使われてるデザパタを知っておけ」だ

俺はDjangoは当時知らなかったがActiveRecordパターンを知っていたから
使い方が間違っていることにすぐに気づいたぞ
特定のフレームワークに縛られない知識が重要という話だ。

あくまで実装者として立場からしか見れないお前は
今使ってるフレームワークの使い方で精一杯なんだろうけどな。

そしてフレームワークから呼び出されるコードしか書かないから
お前の世界にはデザパタがでてこないわけだよ。

全て理屈が通ったなｗ

**デフォルトの名無しさん** · 2017/10/01(日) 02:40:26.75

>>190
だからそれは「フレームワークがActiveRecord前提で組まれている」からであり、
それを「ActiveRecordパターン」と呼ぶのは自由だが、GoFの言う「デザパタ」とは違うって。
まあ平行線ならそれでいいが。

**デフォルトの名無しさん** · 2017/10/01(日) 02:44:03.92

> GoFの言う「デザパタ」とは違うって。

そりゃそうだ。ActiveRecordパターンは

エンタープライズアプリケーションアーキテクチャパターン
https://www.amazon.co.jp/dp/B01B5MX2O2/
にのってるマーチン・ファウラーのデザインパターンなんだから

**デフォルトの名無しさん** · 2017/10/01(日) 02:46:05.25

>>184
そうだな
デザインパターンをデザパタと呼称する奴はゴミな場合が多い

**デフォルトの名無しさん** · 2017/10/01(日) 02:50:38.64

>>192
>>180読め

**デフォルトの名無しさん** · 2017/10/01(日) 02:51:22.94

ちなみにJava の Hibernate という O/Rマッパーは
ActiveRecordパターンとともに紹介されている
Data Mapperパターンを使っているが

Hibernate はフレームワークではない。ライブラリである。

**デフォルトの名無しさん** · 2017/10/01(日) 02:53:02.16

むしろお前らが何故そこまで必死なのか分からん。再度言うが、>>172の後半、

>>167
それ前から疑問で何度も聞いているのだが、お前のリアルでは
> 「○○パターンを使いましょう」
と言っているのか？

これも何度も言っているが、ストラテジーパターンに該当するとして、
その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
現実的に「ストラテジーパターンで行きましょう」なんて議論は無理で、
「ここは委譲にしとく？」みたいなことにならないか？

デザパタ厨の皆様、これに答えてくれよ。

**デフォルトの名無しさん** · 2017/10/01(日) 02:55:34.72

デザインパターンは不要の長物といってる人はデザインパターンを理解してないと思われる
何かしらのソフトウェアをゼロから作り上げるにあたっては必ず何かしらの大枠となる基本設計思想や基本構造を構想して行われる
それがGoFのデザインパターンに一致するかもしれないし、新しい独自のデザインパターンかもしれない
デザインパターンという言葉は両者含めての言葉である
つまり、デザインパターンを持たないソフトウェアなど本来は存在しない

**デフォルトの名無しさん** · 2017/10/01(日) 02:55:40.17

>>196
お前がなんでそんなことに必死になってるのか？
みんなそう思ってるよｗ

ストラテジーバターンでしか
お前はデザインパターンを否定できないってね。

**デフォルトの名無しさん** · 2017/10/01(日) 02:57:01.13

>>196

> これも何度も言っているが、ストラテジーパターンに該当するとして、
> その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
> 現実的に「ストラテジーパターンで行きましょう」なんて議論は無理で、

ここはいろんなアルゴリズムを実行時に切り替えられるようにしよう
であればストラテジーバターンで行きましょう。という議論になる。

アルゴリズムを実行時に切り替えられるようにしようという設計の話で
委譲にしておく？なんて実装の話は出てこない。

**デフォルトの名無しさん** · 2017/10/01(日) 02:57:04.47

むしろお前らが何故そこまで必死なのか分からん。再度言うが、>>172の後半、

>>167
それ前から疑問で何度も聞いているのだが、お前のリアルでは
> 「○○パターンを使いましょう」
と言っているのか？

これも何度も言っているが、ストパタに該当するとして、
その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
現実的に「ストパタで行きましょう」なんて議論は無理で、
「ここは委譲にしとく？」みたいなことにならないか？

デザパタ厨の皆様、これに答えてくれよ。