前スレ >>996
> 関数型はそれが出来るというより
> 意図的に排除する仕組みが言語仕様で用意されているといったほうがいいな
ほう
では、「発送済みなら注文キャンセルできない」コードを示してみて >>1
クソスレをさも当然のように張るなゴミ屑
PHPでも使って死んでろゴミ屑
死ねゴミ屑 >>2
違う話に移る前に
> 関数型はそれが出来るというより
> 意図的に排除する仕組みが言語仕様で用意されているといったほうがいいな
ということには納得したの？ 別のスレからだけど丁度よいタイミングだったから転載するわ
413 名前：デフォルトの名無しさん[sage] 投稿日：2017/07/23(日) 00:54:24.08 ID:4pTb5xvQ [2/2]
┌─マシン語
│
言語のレベル─┼─低級言語
│ ┌─コンパイラ型
└─高級言語─┤
└─インタプリタ型
┌─手続き型
│
│ ┌─宣言型
│ │
文法──┤ ├─関数型
│ │
└ 非手続き型─┼─論理型
│
├─グラフィック型
│
└─問い合わせ
パラダイム──オブジェクト指向
http://webrylabo.blogspot.jp/2009/11/blog-post_28.html
2009年11月28日土曜日 それは俺も思った
手続き型のカテゴリにでも入れとけばよいんじゃないですかね
オブジェクト指向はレシーバーにメッセージをディスパッチするってだけの事だから
特にどこに属するってものでも無いのが良くわかるな
>>5
> 違う話に移る前に
違う話って何？
もともとの話なんだけど
> ということには納得したの？
納得するかどうかは、コード見てからだね 話がずれないように軽くまとめとくと、注文のキャンセル問題には三つの着眼点がある
1. キャンセルすることを禁止されているため呼べない（権限による制限など）
2. キャンセルは許可されているが、すでにキャンセル不可の状態になっている
（キャンセル可否チェックの時点で、既に発送済みだった場合）
3. キャンセルは許可されていてキャンセル可能状態だが、実行してみたらキャンセルできなかった
（トランザクションの一貫性の問題）
権限なし
権限あり
アクティブ
非アクティブ
問い合わせ中
済み
うんこ中
リザルト
うんこ
非うんこ
>>9
じゃあこの話に戻ろうかね
> 関数型はそれが出来るというより
> 意図的に排除する仕組みが言語仕様で用意されているといったほうがいいな 関数型に言語仕様で用意されている
"意図的に排除する仕組み"とはなに？
そんなの自分で勉強しろよ
何でも教えてもらえると思うな
手続き型言語は副作用があるのが前提で
その場合、結果が処理順に影響するけど
関数型言語は意図的にそれを排除する仕組みがある
それだけ
>>16の説明に納得してから
次の話題に入りましょう 意図的に副作用を排除するって大雑把すぎるな
そんなん言ったらどの言語でも同じ
片っ端からImmutableにしとけば副作用なんて簡単に排除できるわな
>>23
その意味の「副作用」って薬とかのそれじゃないの？ 副作用の定義からかよ
ロジックや計算という作用と、出力等の副作用を分けましょうね
って指針じゃないの
この業界ってなんでも状況次第だろう
状況無視して単語と意味を1:1で紐付けるのは素人の考え方
副作用の無い、と聞くと、永続化しないもので、リエントラント可能で、入力と出力が常に一定、とイメージしてしまうな。
そういう意味ではDB保存するデータを作る部分が副作用無い関数で、実際に保存する部分がデータを作る部分に対する副作用と言うか作用そのものなのか。
物理的に見ればどんな処理だろうと副作用を避けることはできない
なので、どこまでを副作用とみなすか? という定義の話になる
そしてそれはコンテキストに依存した問題だ
とりあえずJava、C++、C#などのOOPは手続き型のOOPだから
それで問題ない
プログラミングにおける副作用（ふくさよう）とは
ある機能がコンピュータの(論理的な)状態を変化させ
それ以降で得られる結果に影響を与えることをいう
代表的な例は変数への値の代入である
>>30
微妙に賛同しかねるな。
クエリ言語系は、純粋なものと純粋ではないものを別けて考えてると思う。
オブジェクト指向でもなんでも。
SQLのSelectとか、XQueryでの検索とか、色々。
couchdbなんかは、純粋でないものがホントに更新系みたいな書き方できるし、純粋でない操作をされたらその段で他の純粋な操作の結果を先に作りに行くから、問い合わせ滅茶苦茶早いし。
避ける事は出来ないが、コンテキスト依存ならしっかり決めた方が幸せでは？ 現在の日時を取得するDate.now()は
副作用がある関数でしょうか？
>>36
ないでしょ
関数を呼び出すことによって時間が変化してるわけじゃないんだから ではランダムな値を返してくれる関数は
副作用があるのでしょうか？
Date.now()を使った関数は参照透過性を満たさないだろうけど
副作用がないならば参照透過性を満たす は偽ってことですな
>>38
疑似乱数であれば内部に状態を保持してるはずよ
なので副作用はある >>40
外から見えない内部状態の変化でも
副作用ってことになるの？
じゃあSQLのselect実行して実行ログ記録された場合は
副作用になるの？ >>41
| 副作用（ふくさよう）とは
| ある機能がコンピュータの(論理的な)状態を変化させ
| それ以降で得られる結果に影響を与えること
擬似乱数の場合は内部の状態を変化させてその後の結果に影響を与えるから副作用だよ
ファイルの入出力が副作用だからログの記録も副作用なんじゃないかな
実行ログを結果と見るのだろうね >>36
副作用と呼ぶかどうかは置いといても
テストしやすいようにラップしとくとこだな
乱数も int unkoHash(int x) {
Random r = new Random(x);
int n = r.nextInt();
for (int i = 0; i < 10; ++i) n ^= r.nextInt();
return n;
}
乱数を使ってるが副作用は全くないぞ
何度も言ってるけどこの業界は何もかもが状況次第でしかないんだよ
乱数なら副作用だとかそういった固定観念はくその役にも立たない
>>45
何それ？
乱数テーブルどうなってんの?
毎回同じテーブルになるんだろうな? >>45
状況次第なのはIT業界にかぎらず全部そうだと思うんだよ
状況次第と言うことに意味があるとは思えないなあ
そんなの当たり前じゃん
人間はいつか死ぬんだよと言ってるようなものじゃん >>47
誰が何と言っても全ては状況次第という真実からは逃れられない
全て状況次第と言うことが意味がないのと同じくらい
状況を無視して議論することもまた意味がない >>48
いやいや、副作用がないと言ってるんだから
副作用がないという仮定のもとでは毎回同じテーブルになるっしょ
こういう状況ではこうなりますみたいに論理展開しないと
>>49
状況次第と言ってるだけで状況を無視してるのはそっちだと思うけど >>50
unkoHashが毎回同じ値を返すとしても
必ずしも毎回同じ乱数テーブルである必要はないんだよ
たまたま同じ結果を返す乱数テーブルを動的に切り替えてもいいししなくてもいいでしょ
つまり乱数テーブルが固定かどうかは状況次第ってわけ >>51
たまたまだったら副作用がないことが保証されなくない？
たまたまうまくいくものを副作用が全くないと言うのはなんか怪しくない？ 状況次第だ(状況を分析できるとは言ってない)みたいな
何を聞いてもケースバイケースとしか言わない人って
ちょっと怪しいよね
>>54
どう言い繕っても何事も状況次第であるってのは避けようがないんだよ
怪しいだのなんだのと人を貶めるような発言をしてもその事実は変わらない >>55
自分の言説がどういう状況で成り立つのが説明することから
逃げるために一般的すぎて何の情報も持たない状況次第と
いう言葉を使っておられるのかなって思うんだよね >>56
状況次第であることを認めず分析や定義を怠る事
これがもっとも愚かな行いである >>57
状況次第なのは当たり前じゃん
こういう状況ではこうなりますという選択肢が自分の中にあって
今の話の状況はこれに該当するからこうなるよって示すのが
状況を分析して示すってことなのかなと
単に状況次第だと言うのはその分析して示すっていう過程が抜けてるかなと
それを愚かな行いだと言うのならちゃんとやってよって思う >>45
そもそもこのクソコード乱数テーブルの初期化が考慮されてねぇ
副作用以前の欠陥コードだろうが
でも状況次第（周りも全員馬鹿）でいいコードポジなんだろうな >>58
取り組むべき問題があればやってるが、
今はそうじゃなく、何事も状況次第ということがわからない人たちに啓蒙してるんだよ >>60
そいつらの態度も状況次第だろうが
黙って見てろよチンカス >>60
当たり前すぎて言わないだけで状況次第がわからない人っていないと思うんだよ
各々が状況を分析してこうなんじゃないかと述べてると思うんだよ
ケース・バイ・ケースは便利な言葉だけれどもちょっと議論には向かないかなと >>60
状況次第（お前が嫌われてる）の判断の結果としてそうなってんじゃねーの?（笑） >>62
ちょっと待ってくれ、周回遅れは別に悪いことじゃないだろ
掲示板での議論ってそういう時間的な差を埋められるから良いと思うんだよな >>64
いやこのスレにはわかってない奴が結構いるぜ
匿名だから人数はわからんが
まあ過去ログ見てきなよ俺の言ってること実感できるから >>65
すまんもう少しわかりやすく
母国語でいいから >>66
それも状況次第だな
非リアルタイムな対話のツールとして有用性はある
でもトンチンカンな意見で過ぎ去った話題を掘り起こそうとする変なのも呼び寄せてしまうデメリットもある >>68
それってただのバイアスじゃない？
議論って各々がそれぞれの仮定をおいて意見を出し合うものだから
この人の意見はこういう仮定だなーというふうに理解しなきゃいけなくて
他の状況が考えられるから状況次第だとわかってないみたいに結論するのは拙いかなと >>73
議論が広まるのは良いことじゃん
トンチンカンというのはちょっと感情的かなと >>75
問題はその仮定を共有しないことな
ある程度、話を進めた後で、酷いコードや前提条件を出してきて
あ、こいつこんな世界観で議論してたんだ、アホくさ〜
とか、よくあるじゃん
酷いのになると、自分が業務で扱ってるシステムを前提に(当然他の人はそんなもん知らん)話を進めたりする >>77
広がる状況ならいいけどな
この状況では明後日の方向に進むだけだろう >>77
それも状況次第だよね〜
って散々小学生のときにやったぜ
状況次第って言ってもビジネスでは
事象が滅茶苦茶多くて把握するのも手に負えないのか
少なくとも１０パターン程度で他の人間の手を借りれば把握できるのか
規模の目算ぐらいは立ててから相談しねーと無能の烙印を押されるけどな >>78
ネットで検索すればわかるようなことより自分の経験で語る人の意見って貴重だと思うよ
そういう世界があるだなとかそういうシステムを保守することになったら参考にしようとかさ
他人の世界を自分の世界に取り込むことこそ議論の醍醐味だよ
セルが人造人間18号を吸収したときとか興奮したでしょ？ 完全体目指してるんでしょ？ 丸ごと吸収したらいいよ！ >>79
議論の方向性って別に気にする必要なくない？
こっちじゃなきゃ嫌なの！みたいな思いを持ち込む必要なくない？ >>84
有意義な方がいいと思うが
仮にそれをAとする >>82
相手も何を説明すれば良いのかわからないのじゃないかな
なかなか難しいからね、面と向かって話してても誤解することもあるし
ほんと会話って難しい >>86
(*ﾟ∀ﾟ)じゃあ、お互い何話してるかわからないんだよｗ >>87
そういうこともあるよ、会話が上手なベテランの人でさえあるよ
自分の理解をこまめに示して確認しながらすすめるしかないんじゃないかな 状況次第ではないように、何故定義できないのか？
俺は事実、「副作用の無いもの」が、参照透過であるはずだと思ってしまってたし。
有意義だと思うんだけどな。
>>88
ねーよ
テメーのまわりに比較的キチガイが集中してんだろ そもそもまともな上司は状況次第なんて報告は許さない
社会に出てからは聞き慣れない言葉だよね
クソ報告したやつは終電まですべてのケースを記述する始末書でも出してろ
>>96
まともな上司が状況次第を許さないから状況次第は許されないんだというわけだろ
上司のまともさが状況次第だとするなら状況次第が許されないことも状況次第になるわけだから
状況次第が許される可能性が存在することが否定されないわけだから
ゆえに状況次第なのは状況次第ってことになるから結局お前状況次第って言いたいだけなんじゃないの？
状況次第ってそんなに言いたいかねその感覚わからんわ 「あ」とかいう次世代言語議論スレにもいる手帳持ちの糞コテここにもいたのかよ
>>101
そんなスレ全く興味無いが
仮にそれをAとする 372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円 平凡な稼働時間の80万円の案件もある。
ユー子が求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ
それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト
自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む
473非決定性名無しさん2017/08/03(木) 15:21:30.71
JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の
間でやらしている。
状態が受注のレコード持ってきて更新かけるだけなんじゃないのかな
2,3は楽観同時実行制御でいいし1は権限テーブル用意すれば良い
>>109
いやいや、オブジェクト指向スレでオブジェクト指向だったらどうしましょうねって場に、
関数型ならできるよって切り込んできたんだから、じゃコード示してみてってなるでしょ いちいち念押ししながらじゃないと話が発散してしまうのがうざいんだが、
> 関数型はそれが出来るというより
> 意図的に排除する仕組みが言語仕様で用意されているといったほうがいいな
これを示してくれってことね
>>115
経緯を一から全部まとめた方がいんじゃないかな
オブジェクト指向ではこう書くけどと示されていたら
答えやすいんじゃない？ そういうとこちゃんとやろうよ >>116
オブジェクト指向でどうやるかは、前スレでさんざん話でたでしょ
また繰り返したいの？ >>117
このスレで問うならそれくらいやるべきだと思うよ
自分でコード書いてオブジェクト指向ならこうやるって
示して関数型ならどうやる？って聞くんだよ
答えやすい状況を作るのが君の仕事だろ >>118
君の好奇心を満たすために俺がいるわけじゃない
まとめたいなら君がすれば？
で、前スレ >>996が俺の質問をさらに無視するもよし
別に誰も困らないよ 結局、掲示板でオブジェクト指向の話するとこうだからなぁ
>>121
それは、
・オブジェクト指向を好む者は、一般に言ってまともな会話ができない
・オブジェクト指向の話をすると、他パラダイム信奉者が必ず邪魔に入る
のどっち？ せめて模範になるソースとか落ちてないのかね?
誰でもダウンロードできるところに
できれば動くのがいいっていうか動くの必須だな
>>120
それは無茶でしょ
このスレに持ち込むのなら改めて流れをまとめて
提示しないと無責任だよ はぁ？
ドアなんちゃら問題みたいな話じゃなくて、>>10の話だぞ
なんで湖畔となるコードなんぞいるんだ？ >>122
ソースを元にああだこうだって議論ができないのよ
githubにうｐって上げるでもあればいいけどね
そもそもオブジェクト指向派は理想ばっかり掲げて
君らが素晴らしいとするソースの一枚でも俺に見せてみろという感じはある >>124
> このスレに持ち込むのなら改めて流れをまとめて
> 提示しないと無責任だよ
前スレ終了直前で話をぶっこんできて、何の説明もないまま>>5みたいなことを言い出すのは無責任じゃないのか？ >>10 の話がただの覚書みたいになってるから
みんな答えにくいんじゃないかな
仕様とコードをまとめてできれば経緯もまとめて欲しいけど
そうやってきちんとした形で提示した方が良いと思うよ >>126
なんだ、「他パラダイム」の人だったか
オブジェクト指向スレ荒らすのやめるか、自説を展開するならコードで説明してくれないかな >>128
> みんな答えにくいんじゃないかな
前スレ>>996に質問してるだけなんですが
話に割り込むなら、前スレの流れ読んでからにしてくれよ
いちいち相手するの面倒 きちんとまとめてないからこうやっていちいち聞かなきゃいけないでしょ？
だからちゃんとまとめなよ
他人にコードで示して欲しいならきちんと仕様をまとめて
オブジェクト指向ではこう実装しますって参照実装も示さないと
何を書けばいいのかわからないよね
相手の立場に立って考えて欲しい
>>135
このスレに書き込んだ時点で俺を始めこのスレを見てる人は
すべてを知る必要があるだから聞いているんだ
>>136
違うよ、まったくの別人だよ >>996からのみ返信欲しいならダイレクトメールを送るべき
このスレに書き込んだ時点で他の大勢に見てもらいたいという
思いがあるわけだから、その責任を果たさなければいけない >>139
> すべてを知る必要があるだから聞いているんだ
じゃ、前スレ読めば？
なんで君のために前スレのダイジェスト作んなきゃならないの？
>>140
違うなら説明する必要するないよね
俺の質問相手は、前スレ>>996なんだから スレに書き込むならスレを読む人全員にわかるように書きなさいよ
2017年にもなって2ch初心者かよ
んじゃ、NGね
>>142
俺だけじゃないスレを読む人全員のためにまとめるべき
なぜならば君はこのスレに書き込んでいるからだ
このスレが君だけのものだったらそんなことしなくていいよ
だけど違うよね？このスレは俺のものであり、みんなのものだよ
君のプライベートなやり取りを書き込むスレじゃない >>144
掲示板っていうのは皆のものなんだよ
君だけのものじゃないんだよ
俺とみんなのものなんだよ
逃げるのみっともないよ 僕の発言はすべて>>996に宛てたものですっていうのなら
アンカーを付けるべきなんだよね
それをやってないのは邪な思いがあるからだよね
まるでこのスレでみんながそれを議論していたかのように思わせたい
甚だ汚い思いがあったからそうしたんだよ
話詰めたら>>996との個人的なやり取りだから干渉しないで欲しいと言うわけだろ
姑息、ただただ姑息 ときどきNG解除して書き込み覗いてるんだろうな
_,,..r'''""~~`''ー-.、
,,.r,:-‐'''"""~~`ヽ、:;:;:＼
r"r ゝ、:;:ヽ
r‐-、 ,...,, |;;;;| ,,.-‐-:、 ヾ;:;ゝ
:i! i! |: : i! ヾ| r'"~~` :;: ::;",,-‐‐- `r'^!
! i!. | ;| l| ''"~~ 、 i' |
i! ヽ | | | ,.:'" 、ヽ、 !,ノ
ゝ `-! :| i! .:;: '~~ー~~'" ゛ヾ : : ::| イェーイ、みてるぅ〜？
r'"~`ヾ、 i! i! ,,-ェェI二エフフ : : :::ノ~|`T
,.ゝ、 r'""`ヽ、i! `:、 ー - '" :: : :／ ,/
!、 `ヽ、ー、 ヽ‐''"`ヾ、.....,,,,＿,,,,.-‐'",..-'"
| ＼ i:" ） | ~`'''ー---―''"~
ヽ `'" ノ
そうは言っても、俺も少しは親切心があるからな
前スレで
class Order {
private bool isCancelable() {}
public void cancel() {
if (!isCancelable()) {
// エラー処理（例えば例外をthrow）
}
// 実際のキャンセル処理
}
}
というコードに対して、「闇が深い」という判定が下り、そこから話が紛糾したりした
前スレ>>996ならどんなコードにするんですかね >>150
えぇ!! >>10 がこれになるんすか!?
権限の制限も発送済みの状態も全然盛り込まれてないじゃない
これは闇が深いと言われても致し方ないかと 三つの着眼点をまったく無視したコードじゃないっすか！？
マジっすか？ これでホントにダイジョブなんすか？
発注・受注・納品・キャンセルは
業務アプリではよくあるものなので
SIer戦士は得意なんじゃないかな
>>153
なんすかそれ？ 俺のこと煽ってんすか？ 煽ることで >>150 のコードを引き出した僕の力量を認めて欲しい >>158
なるほどな、ところでイザナミって何だ？ コーディングよりはデータモデリングの方が
重要になってくるかなと
ユーザ -> ロール -> 権限
受注 -> 受注明細
受注 -> ユーザ
エンティティを分けるとしたらこうかな
イミュータブルデータモデル(入門編)
https://www.slideshare.net/kawasima/ss-40471672
関数型に適したデータの持ち方はこれとか
updateを行わずにinsert/deleteでやりくりするのだけれども
数百万のデータ扱うときにそういうやり方ってio的に厳しくないかな
SIer戦士の知見を伺いたいね >>159
つgoogle「イザナミだ ナルト」
読むとこのスレが丁度術にかかってるみたいで笑えるぞ! >>160
IOっていってもほとんど読み取りだからな
キャッシュすりゃいいわけよ
キャッシングはイミュータブルな構造との相性もいい イザナミすらしらんゴミがイキってて笑える
夏休みの宿題済ませてこいよカース
>>6
それ宣言型、関数型、論理型が並列に並んでるのおかしいね。 なんか一人か二人荒らしまわってる連続投稿君がいるみたいだけど
>>115
は元々
Java、C++、C#などは副作用を前提にプログラムを書くスタイルを基調としているから
手続き型言語のグループに入るけど
関数型はそれを意図的に排除する仕組みが言語仕様で用意されている
ってことまでしか言ってないからね
排除された結果、自分が思ったコードが書けなかったとしても、それは関係ない
だから類似コードを示す必要性は全くない
例えば論理型言語のPrologで注文受注のコード書いてたらバカだろ
もしくはGPUのシェーダー用のプログラミング言語(HLSLとか)で
注文受注のコード書いてたらバカだろ
あえてバカみたいなことはする必要ないんじゃないかな ID:A4v2+zpKが如何にキチガイか理解していただけただろうか
まぁ18も連投している時点で明らかなわけだが
付き合いきれまい
最近jsでデータの整理整頓をしない環境にいたので覗きに来ました
本題は、JavaやC++やC#は手続き型言語のグループに入るって部分であって
関数型は〜の部分は、少なくともこれらの言語は関数型では無い
っていう例で挙げているだけにすぎず
関数型言語で受注プログラムを解くとか解かないとか
そういう話は一切してないし
関数型だとキレイに書けるとも一言も言ってないし、全く言及してない
文章を勝手に改変して「こうなってるけどな」と言われても
>関数型はそれが出来るというより
>意図的に排除する仕組みが言語仕様で用意されているといったほうがいいな
ってしっかり書いてあるだろ
そしてこれは本題ではなく
JavaやC++やC#は手続き型言語のグループに入る
ってことを説明する、そうじゃないものを例に挙げたまでだ
関数型言語で受注プログラムを書くとか書かないとか
まったく言及してない
手続き型に構造型にしやすくするための構文を追加したのが構造型言語
その構造型言語にオブジェクト指向しやすくするための構文を
追加したのがオブジェクト指向言語
そしてオブジェクト指向言語に内包される手続き型と構造型部分に
関数型言語の特徴を組み込むのが今のトレンド
構造「型」言語とか言ってる時点で
何の信ぴょう性もないもんだな
なんだよ関数型崇拝者はまだ全く説明できないで同じこと繰り返しているのかよ
>>180
で
> 手続き型言語の欠点である順番やタイミングに依存する方式を
> 意図的に排除する仕組みが言語仕様で用意されているといったほうがいいな
ってなんだよ
エアプか？ >>182
前スレのID:m8GLf68Fがそう言ってるってことなんだがな そんな仕組みないです
参りました
ごめんなさい勢いで言っただけなんです
許してください🙇🙇♀
>>10は
1. 権限管理
2. キャンセル可否のビジネスルール
3. 同時実行制御
っていうレイヤーの異なる3つをごちゃまぜにしてるからダメなんだろ
データモデルの良し悪しとは全く別次元の話だわ 常識的に考えるとそれらは別のレイヤーでやるよな
ただあの人みたいにいずれも検証だから同じレイヤーでやるみたいな派閥もあるみたいだね
>>187
cancelメソッドとそれが不可能だって例外ですべてハンドリングするのも同じ次元だけどな。
>>188
検証としては同じレイヤでやるが、実際の処理を同じものが持つかどうかは別だぞ。
検証処理を行うのは一人がやるべきだし、それぞれのステートにおいて適切なロジックがやるべき。
そのロジックの結果同士の和とか積になるよね、って。
そうしないと優先順位が生まれたときに、あとから定義したりしていなかった優先順位の解釈を、既に散在してしまったチェックロジックに入れて行くことになってしまう。
データが一人でやるべきものではなくて、ビジネスロジックが検証してやるべきものだ、って話だよ。 >>>187
権限がなければキャンセル処理を実行できないようにしたいのであれば、例えばキャンセルボタンをグレーアウトさせればいい
その場合、権限ないにも関わらずにcancelメソッドが呼び出された場合は業務エラーじゃなくシステムエラーだから扱いが異なる
最終的な実装はどうあれ同じ次元として扱ってるとまともな設計にはならないよ アンカ間違えてた
>>187じゃなく>>189ね
下の3つを「検証」って言葉で一括りにしてるとプログラムの大半はなんらかの検証処理になっちゃう可能性がある
検証って言葉をどういう意味で使ってるのかとか、何に対する検証なのかを考えたほうがいい気がする
ロジックの散在とか優先順位の解釈とか言いたいことは分からなくはないけどね
1. 注文がキャンセル可能かどうか
2. ユーザーがキャンセルの実行権限があるかどうか
3. キャンセル実行時にデータ整合性が保証できるかどうか >>190
それは、キャンセルボタンが押せるかどうかの判定で、キャンセルができるかどうかの判定と似てるが違うものだよ。
キャンセルボタンではキャンセルできないけど、電話してオペレーターにキャンセルしたい、と頼めばやってくれる、とか。
>>191
そうだな。言葉が悪いか。
状態検証
権限検証
整合性検証
は、すべて「検証」ロジックが呼び出すべき処理、って感じかな。 >>192
引っ込みつかなくなったのはもうわかったから implements ICancelable
でいいだろこれでコンパイルも通る
おまえら、たったこの1行のコードもひねり出せない無能のチンカスガイジ低級プログラマ土方ジャップランド土人だったのか？
100歩譲って無能のチンカスガイジは認めるわ
土方プログラマっていうのもまあ分かる
しかしジャップランド土人というのもそのとおりだ
>>192
>すべて「検証」ロジックが呼び出すべき処理、って感じかな。
そのすべてを呼び出す「検証」ロジックって何ぞな？ >>197
あー、確かに。それは微妙か。
データフローとか、ジョブの検証フェーズになるだろうね。 話は変わるが
私はユーザーオペレーションのミスも例外で処理する(例外シナリオ)
これは一番やりたいことを最も早く簡潔に書くためだ(メインシナリオ)
やりたいことが出来ないのはシステムにとって致命的だが、ミスは回避できる特に開発段階では
ミスかどうか早めに自発的に判断するのはやぶさかではないが、そこでも例外を投げて例外シナリオであることを明示する
システムにとって必要不可避なユースケースを最小で実現するためだ
問題があれば聞かせてほしい
>>200
前にそれやったらロジックが複雑になったことある >>201
うちではロジック変わらない
設計者の技量の問題かな >>202
エラーによっては別の方法を促さなきゃいけない仕様になっているのに
まとめて処理しようとしててmain関数がお化けになってた
エラーメッセージってちゃんと表示しようとするとその時の色んなもんが必要になるんだけど
それも上手く引っ張ってやらないといけない
その場でやったほうが楽だったよ
エラーメッセージ用の必要なデータの抽出ってのも結構骨が折れる
しかも頂点でしかやってねーからある時mainが全部using持ってないと動かなくなちゃった >>203
それは代替シナリオで例外シナリオではない
記述場所の問題なら例外に乗せて投げればいい
そもそもmain関数とかオブジェクト指向じゃないだろそれ もともとプログラムってのは確認して実行しても良さそうなら実行っていう戦略とは根本的に相性が悪い
確実に実行できることを保証するって深く考えると実はかなり難しいのでまず間違いなく何処かで漏れる
どうせ漏れがあるなら最初から確認せずにとりあえず実行してしまえばいい
実行してみて何事もなければそれで良し
ダメなら適切な例外をなげろって設計が実は最も自然な設計
これだけでも完全なシステムを作れる
まあそれだけだとUXが悪いからクライアント側で書式チェックぐらいはしてもバチは当たらんだろうね
>>204
例外じゃん
少なくとも一瞬は例外だったじゃん
そこから例外→代替シナリオのルートがねーと
コード上では
お前の処理が全部食っちゃってて手の入れようがない >>206
いや代替シナリオは別途設計書く
コードの例外と例外シナリオは同じではないぞ しかも頂点まで戻って来ててしまって
代替シナリオで以降の処理を続行的な選択をすると
例外発生処理まで来たルートをフラグを見てお通しする
見事なクソコードなのだ!
パオーン!って俺も叫んだ!
プログラム全体で作ったインスタンスを消すともう動かねぇよ
どーすんだコイツ的な衝撃
>>207
代替があるかどうか？って
ハイ、イイエ
をその処理に対して誰かがちょっとでも浮かぶかどうかじゃん?
ここまとめて例外で弾き飛ばすと
あ、ここは例外でいいよ
メッセージ出して欲しいなぁ
って客の気分やから
融通が効かないクソコードになんで >>210
(´・ω・`)俺の言ってることあんま理解できない? >>207
サービスで代替？があるやつだけ教えてやったけど
これだけだと思ってるの?
まだまだあるぜ
バーカ
検討を祈る! うん、俺がアホだったね
死ぬわ(´・ω・`)
環境特有の状況だね
代替シナリオと代替サービスを一緒くたにしてるのかな
○次受けが多いほど退場率が早くなる。高くなる
直受けの50万 客：いつまでもうちにいていいよ
3次受けの50万（客は90万払ってる) 客：短期延長していい？
5次受けの50万（客は150万払ってる) 客：作り終わったらとっと出てけ できなかったら即退場だ
長時間労働 高稼働 高スキル要求が多い
零細フリーランスサイトは5次受けから誰もできない難易度の高い仕事 余り物の仕事を紹介してくる。40万円代でやってくれと
これならJIETから3次でいったほうがいいな
446非決定性名無しさん2017/08/02(水) 22:12:48.95
JIETに毎月5千円払えば３次から入場できるだろ？
高額をうたうフリーランスのサイトはだいたい５次から４５万円
JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした
高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした
JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の
間でやらしている。
372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円 平凡な稼働時間の80万円の案件もある。
ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ
それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト
自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む
オブジェクト指向に造詣の深い諸兄は、DTOとかPOCOとか、クラス図に書いてます?
>>221
データベースのdtoは書かない
ViewModelは書く >>222
一般的にはそういう認識で良いんですね
プログラムできない上司と二人きりの社内IT便利屋なので世間様の動向が解らず
ありがとうございます いつの間にかWikipediaのオブジェクト指向のページがいい感じになってるな
>Eclipseを開発したDave Thomasや、オブジェクト指向という言葉の生みの親であるAlan Kay博士は
>オブジェクト指向という言葉は失敗だったと語っている。
>[1] これは、本来オブジェクト指向が重視すべきは「オブジェクト」ではなく
>「メッセージング」であるにもかかわらず「メッセージング」がおろそかにされているためである。
>特に言語の進歩において「オブジェクト」や「クラス」の側面ばかり強調される傾向にあり、
>Alan Kay博士は「Smalltalkが最高に好きという訳ではないが、他の言語に比べればマシである。」と述べている。
昔はこんな記述なかったように思うが、これが今の空気感なんだよな
俺もそういうことを言ったことがあるし、そう思う人もいくらか居て
だんだん発展して、そういう空気になってるんだな
オブジェクト指向は本当に名前が悪くて、メッセージング指向とでもしておくべきだったと思う
名前に引っ張られるってのは少なからずあるからな
メッセージング、メッセージのやり取り、というのは手続き型言語においては手続きそのものであるが
やはり手続きの部分が読みやすい方が良い、処理の順番が見たまんま一目瞭然な方が良い
何がどの順で実行されているか明瞭、といった古典的な要素を見直そうというそういう流れ
処理の順番に結果が依存する手続き型言語において、処理の順番が把握しづらいのは本来恐ろしいことだからね
なるべくオブジェクト同士の相互作用たる手続きの部分が簡潔になるようにクラス設計しなければならないんだけど
そのことを忘れて、クラスとは何ぞや、オブジェクトとは何ぞや、といったオブジェクト原理主義みたいな病気に
かかってしまう、まぁ、麻疹みたいなものではあるけど、名前が「オブジェクト指向」になってるからどうにも助長する
だからメッセージング指向の方が良かっただろうね
> だからメッセージング指向の方が良かっただろうね
メッセージング指向の何が良いの？
メッセージのやり取りが需要！
そいで何が重要なの？
メッセージのやり取りが需要なんだ
名前がまずかった。
メッセージのやり取りがー
メッセージのやり取りこそがー
で何が重要なの
メッセージのやり取りが需要だって言ってるだろ！
オブジェクト指向という言葉の生みの親であるAlan Kay博士は
名前がまずかったことにこだわり、その中身の重要性を語ることはなかった
メッセージは大事だが本質ではないよ
メッセージ指向が目指したのは「可能な限りの決定の遅延」
設計時、実装時、実行時、運用時（保守、メンテ時を含む）などすべての局面での徹底の試み
「遅延結合」ともいえるけど、実行時に限定してしまう人がいるからこっちの表現の方がいい
メッセージというのは「決定の遅延」の重要性やどうやればいいのかわからない人のための方便でありお題目
だからメッセージが大事、メッセージが大事と繰り返す割に説明ができる人が少ないのはまあある意味必定かと
http://metatoys.org/oxymoron/oxymoron.html > メッセージ指向が目指したのは「可能な限りの決定の遅延」
決定の遅延は、問題の先送りと考えればよい。
結局あとから問題が発覚するだけにすぎない。
「最適化や解決を急ぎすぎない」といった方が適切かな
対象とするシステムやそこで解決すべき問題についての理解が深まるまで、
あるいはハードウエアなどの状況が改善し解決してくれるまで、とりあえず運用可能な実装ができ
しかもよい解決法が出てきたらそれで容易かつ安全に置き換えられるようなそんな感じ
たとえば参照先の文書をきちんと読まずに反射的にしたレスをうまく取り繕えるようなメタシステム作りを目指すのがメッセージ指向
> 対象とするシステムやそこで解決すべき問題についての理解が深まるまで、
それでは、ずっと理解は深まらないのか？って問題が有るな。
例えば一回作ったことがあるシステムならば理解は深まっていると考えられる。
では理解が深まってる状態で、何の決定を遅延させるのか
遅延させることに意味があるのか？
> しかもよい解決法が出てきたらそれで容易かつ安全に置き換えられるようなそんな感じ
今は容易かつ安全に置き換えられるようになっている。ただしOSの力によって。
アプリケーションは一旦終了してから入れ替えて起動しなおせばシステムを
停止すること無く、アプリを更新することができる。
そこが昔と今の違いなんだろう。昔買ったMSXは起動するとBASICが起動した。
OSではなくてBASIC。OSが存在せず言語の開発環境がOSそのものだった。
そういう時代においては、言語自身にプログラムを入れ替える方法
つまりアプリケーションの再起動というOSの仕事までやる必要があった。
だから「決定を遅延させる」なんて話が出てくる。
それがOSの力で解決して今は言語に「決定の遅延」をもたせる必要がなくなっている。
決定の遅延の重要性が理解できないのは、時代にあっていないからに過ぎない。
先送りして後で問題になるではなく
先送りして後で解決してもいいように作る
ってことでしょ
容易かつ安全に置き換えられるのはアプリだけで
OSの更新はOSを停止せずにできないように思うかもしれないが。
そこでクラウドというものがでてくる。
システムをサービス化して、ネットワークで通信させることにより
システムを疎結合にして無停止でシステムを容易かつ安全に置き換えることが
できるようになってる。
説明するまでもないと思うが、古いシステムを使いながら
裏で新しいシステムを準備し、新しいシステムが有効になったら
ネットワーク経路を切り替える。
OSもネットワークもろくにない時代に言語だけで問題を
解決する方法を模索していたってだけで現代には合わないのさ。
すでに現代はシステム全体で見れば、決定の遅延を行っており
容易かつ安全に置き換えられるシステムができあがってる。
それは言語に求めることじゃない
あと昔と今の違いは今は素人が使っているという点があるな。
別の言い方をすれば、プログラムを作った人と使う人が違う。
言語レベルで対応してモジュールや関数単位で、
容易かつ安全に置き換えられるようになったとしよう。
でもそれはあくまで言語レベルであり、メッセージの送り側と
受け取り側の両方がメッセージの内容を正しく理解できなければ
バグなく動くことはできない。
しかしその点は無視されている。バグであってもシステムが停止せずに
動き続けていればOK。バグによってデータがおかしくなっても
停止しないシステム上で修正すればいい。バグによって処理が停止しても
デバッガが起動してシステムを直して再開できればOK
当時の「容易かつ安全に置き換えられる」っていうのは
停止しないシステム上で人間がトラブルに対処して再開できればいいというレベル
コンピュータを使ってる人＝プログラマ（素人ではない）なので
自分（もしくは担当技術者に依頼）して対応するという前提になってる
完全に早期結合の考え方なんだよね
どこから指摘してよいものかちょっと迷う
とりあえず、参照元読んでもらうことはできる？
それについての疑問に答える方が効率的かなと思う
参照元なんて無いから、
俺に反論してくれればそれでいい
>>237
今はシステム全体が、物理マシンレベル、仮想マシンレベル、OSレベル、
コンテナレベル、プロセスレベルといった単位で
疎結合になっているから言語自身は早期結合で十分という時代 >>236
当時っていつの話？
参照先読んでもらえばわかるけど、もう君が言うような「今」の当たり前は70年代に出来ていて
その先を目指すにはって話なのだけど… 早期結合でできる部分はそれで済ませればいいと思うよ
>>241
> もう君が言うような「今」の当たり前は70年代に出来ていて
70年代のどこにクラウドがあったの？
あんたの言う70年代に出来ていては
原始時代にも石炭はできていて〜っていうのと変わらん。
それをうまく使いこなせるようになったのが今だ 結局、早期結合信奉者の問題は「神の視点」から離れられないことなんだってよくわかる主張だと感じるよ
>>243
もちろんクラウドなんかはないけど
しかし君が想定しているよりはずっとネット環境は整っていたよ
少なくともアラン・ケイがメッセージ指向を考えたり実験したりしていた場ではね だがそんな彼でも、ネットワークの向こう側のコンピュータを
何台も用意して、接続先を切り替えながら無停止で
システムを運用するという発想は生まれなかったわけで
>>249
20〜30年前にはすごいと言われたかもしれないけど、
今だとスマホゲームでさえバージョンアップしていくよ
Googleとかいつメンテナンスしてるんだ？ってレベル。
動かしているシステムの仕様を動的に変更するのは難しいことではない あとそのデモも良くないね。
「やりたいこと」は何か
「それが実現できるか」であれば
今のWindowsだってプラグイン入れれば
メニューが動的に増えるじゃんっていう話で終わりだから。
> あと昔と今の違いは今は素人が使っているという点があるな。
> 別の言い方をすれば、プログラムを作った人と使う人が違う。
あとこの話。動的に仕様が変わってるのはそのとおりだが、
使ってる人が自分で仕様を変えるのか？って話。
デモはいつだってドヤ顔で ”自分が" 仕様を変えている。
違うんだよ。普通は誰か他の人が変えるんだよ。
そして一人のために作業することはないんだよ。
変えたシステムの配布方法（アップデート方法）が必要になるし、
今変えてますから使わないでくださいなんて言えないし、
変えるタイミングは人それぞれにしたいかもしれないし。
使ってる最中に変わったら困るかもしれないし
で、今はシステムの仕様を動的に変えられるかどうか？ではなくて
変えられるの言うのは当たり前の前提で、それをどうやるかって所に進んでる。
言語？なんだって仕様を動的に変えられるよ。コード修正して再コンパイルすればいいだけ
使ってる人がプログラマで自分のために自分が書き換えるなら
「今まさに書き換えていっています！」って状態になるだろうけど、
今まさに書き換えてたりしたら、じゃあテストはどうするんだって話。
普通は書き換えたものをすぐ実用したりしない。
現実には「書き換え後のシステムがすでに用意されています」だからな。
リアルタイムで書き換えることはせずに用意されている。
だから、動的にコードを書き換える機能は実は必須ではなくて
動的にシステムを入れ替える方法があればいい。
それがアプリの再インストールであったり、ネットワーク
越しであればサービスの切り替えだったりする。
シーケンス図みたいにオブジェクトが独立して存在してメッセージをやり取りするってのが本来じゃないの
でも多くの人がここからここを呼び出してこう通ってこっちに戻ってと見てる
いっそ全てのメソッドがブロックしなかったり
オブジェクトがサービスだったらいいんじゃないか
アランケイよりズルムケイなワイの方が頭いいと思うけど何か問題ある？
さっきからダラダラとくっちゃべってるけどランタイムの話じゃねえだろバカ
できる・できないの話ではなく必要となる労力の違いの話というのを理解していない
さらに不確実性やunknown unknownsがもたらす影響も理解していない
だから意思決定を遅らせることが出来るメリットについても理解できない
結局、早期結合の「神の視点」から離れられないわけで
時間の無駄だと思った
部下「Blobの管理どうします？
ファイルシステムかDBかクラウドストレージもありですね。
何を選ぶにせよ顧客との調整が必要なので確定までには時間がかかります。
メッセージ指向的にインフラをインターフェースで隠蔽しておけば今の段階ではとりあえずなんでも良いでしょう。
後で意思決定に合わせて変更できるように作れば安全です。」
x3x「ファイルシステムに決め打ちでハードコードしろ。
俺は賢いから知ってるけどな。
今どきそういうのは言語で対応する必要はないんだ。」
部下「理由を聞いてもよろしいですか」
x3x「今は技術が進歩してるんだ。
システム全体から見ればクラウドとか使って動的に安全に置き換えられるんだよ｡
だから言語での対応は必要ないってわけだ。」ﾄﾞﾔｯ
部下「何を言ってんだこの白痴(意味不明ですが承知しました。責任は取ってくださいよ)」
>>259
何か思うところがあるのなら、ごたくを並べるのではなくて、
君がそれを使って素晴らしいOSSを書けばいいだけだよ。
新しもの好きや天の邪鬼は世の中に一定割合でいる。
彼等が特に無能でもない。（有能/無能と性格は相関がほぼ無い）
だから現時点でろくな物がない≒使えない、ってこと。
君が自分ではOSSを書けない程無能なら、
せめてOSSでそのメッセージ指向(ｷﾘｯしてる物を探してくればいい。
使えそうなら、誰かしら試しているはず。
そしてそれが本当に使えるのなら、自然と広まるよ。
大昔からあって、未だに広まってないのなら、ゴミ確定だよ。
それ以前に君はプログラミングしてないだろ。
何故その程度の馬鹿がこの手の議論をしたがるのか俺にはさっぱり分からないが。
> ファイルシステムに決め打ちでハードコードしろ
「ハードコード」の使い方が間違っているし、
それ以前に普通のプログラミングモデルではファイルシステムは隠蔽されてる。
（むしろファイルシステムが直に見える方が珍しい）
> インターフェースで隠蔽
これはOOPで、と言うかそれ以前にAPIで隠蔽されているから、
メッセージ云々関係ないだろ。 >>259
早期結合とは関係ないが
これは部下の方にも十分責任があるだろ
聞き方・聞くタイミング・上司の扱い方など ぐたぐた意味不明な長文書くやつって
srcもプェチピィみたいな屁臭いゴミ使ってぐだぐだバグ仕込むんだろうな
な？ （暗黒藁半紙）
自分が理解してないから「どんな問題を解決するか」を語れない。
>>259が意味不明すぎてワロタｗ
部下「Blobの管理どうします？ファイルシステムかDBかクラウドストレージもありですね」
上司「とりあえずファイルシステムを使ってあとで修正すればいいよ」
部下「ういっす」
これだけで終わりだろｗ
部下「所で修正はプログラムを実行を停止せずに動的に修正するんですかい？」
上司「普通に停止して再起動すればいいだろ。アクロバティックなことやる必要はない」
部下「ですよねーｗｗｗｗ」 >>267
ズレてるねえ
論点そこじゃないって半日以上経ってなんで気が付かないの 客「開発するシステムは何があってもサービスは許さん！24時間365日何があっても動かし続けろ
バージョンアップの際もサービスは停止せずに行うんだ」
部下「これは言語の選定から始めないといけないですね」
上司「なんで？」
部下「○○言語を使わないと動的に仕様変更できないじゃないですかー」
上司「ん？その言語使えば、それだけでハードウェア障害起きてもサービス停止せずに運用できるの？」
部下「え？故障はハードウェアの責任でしょ。関係ないよ。故障するハードウェアが悪んだ」
上司「馬鹿か、故障するのは大前提だ。その上でシステムを作れって話だ」
部下「そんなの無茶だ！ハードウェアが故障したらプログラムも停止するしか無い！」
上司「一台ならな」
部下「なんだと？」
上司「何台、いや何十台とマシンを用意して一台停止してもサービスを停止しないシステムにするんだ」
部下「そんな非現実的なこと・・・コストが馬鹿にならないじゃないか」
上司「クラウドというものを知らないのかね？ マシンは必要な台数を必要なタイミングで
わずか数分で用意できる。そしてシステムに動的に追加削除が可能。使用している分しかコストはかからない」
部下「そんなことが・・・」
上司「そしてシステムの更新にはローリングアップデートを使用する」
部下「なんだそれは？」
上司「多数のマシンを動的に追加削除できる仕組みを利用して、一台ずつ段階的に
アップデートを行う。サービスの停止することなく、部分的に更新していくことが可能」
部下「そんなことが実現できるのか・・・」
上司「さて言語はどうするかね？ サービスを停止せずに仕様変更はもちろんのこと
マシンの動的な追加削除、再起動だって可能だが？ 」
部下「くっ、再起動できるなら、言語にこだわる理由がない。それがクラウドってやつの力なのか・・・」
>>268
> 論点そこじゃないって半日以上経ってなんで気が付かないの
だから論点を明確にしろって言ってんの。
それが言えないのはあんたに「解決できる問題」が見えてない証拠 解決できる問題として、動的に仕様を変更できるというが、
言語のレベルで動的に仕様したいなんて誰も思ってないんだわ
仕様の変更は再起動すれば反映できるんだから
仕様は静的に変更すんだよ
変更を局所的にして他の部分を保護するためにオブジェクト指向だのメッセージ指向だのを使おうぜというだけの話
動的にデプロイできるなんてのはそれのただの副産物であって今はお前以外は誰も論点にしてないの
> 変更を局所的にして他の部分を保護するためにオブジェクト指向だのメッセージ指向だのを使おうぜというだけの話
その部分を今はネットワーク通信でやろうぜって事になってる。
システム全体がオブジェクト指向になったと言えば理解できるか？
「変更を局所的」＝マシン単位 に時代は変わったんだよ。
あ、もちろんマシン単位といっても物理マシン単位という意味じゃなくて
仮想マシン単位だったりコンテナ単位だったりするからな。
変更が局所的にすんでるだろう？ｗ
それに動的に仕様変更できたとしても突発的なハードウェア障害には対応できない。
それは別の話だと思うかもしれないが、仕様変更であれば別に動的に
やる必要はなく再起動すれば十分。再起動が許されないから動的に仕様変更するのが
要件になっているのだと思うが、再起動が許されないようなシステムは
どちらにしろハードウェア障害にも対応できるのが要件の一つとなるはず。
ハードウェア障害にも耐えられるようなシステムにすると副次的に
動的な仕様変更にも対応できるようになるんだよ。
言語レベルでやることじゃない。
で、それ以外に論点が有るというのなら
「解決できる問題」とやらを明確に書けって話
設計、実装、運用を対象に「メッセージ」を方便に「決定の遅延」を徹底するアイデアがありました
仕様策定、言語、マシン単位で今では当たり前の考え方として普及しました
めでたしめでたし でいい話をなにを長々と
>>278
たぶんその結果、アプリを起動したまま
デバッガなどで動的に変更できることの意味が
なくなったかのようにみえるのが悔しいんだと思うｗ >>276
なんで「決定の遅延」が可能とする例のひとつに挙がっただけの動的な仕様変更にそこまで拘るのか謎
コンプレックスでもあるのか？ >>280
だから、それ以外の「解決できる問題」がでてないから。
例が一つしか出てないんだから、それにこだわるしか無いわなｗ
さっさと他の例だせよ なんとな
頭の悪いID:x3xo3AHAがキチガイみたいに26もレスしてすっかり流れてしまったが
メッセージングとは「手続き」のこと
相互作用とは「手続き」のこと
それから>>254の考え方
> いっそ全てのメソッドがブロックしなかったり
> オブジェクトがサービスだったらいいんじゃないか
は非常にまずい、うまくない
オブジェクトを沢山作ったらなんか勝手に互いにコミュニケーション初めて
結果、自分の求めていた機能が得られました！
はマズい、そんな遠回りなことしたいやつはいない
俺らは生態系のシミュレーションプログラムを書いているわけじゃないし
シミュレーションの結果として目的が達成される、とはしたくない
あくまでオブジェクトは道具であり、こちらが主導権をもって手続きから制御して使う
そのためにも手続きが簡潔、何がどの順番で実行されるか一目瞭然に
なるよう念頭に置いて、逆算してクラスを設計する つーか>>259のアホらしいネタにつきあれば
「決定の遅延」だけなら、あとで
ソースコード修正すればすむだけの話なんだよ。
難しいことはにもない。どんな方法でも実現できる
>>267で書いたようにこの方法でも「決定の遅延」ｗ行ってる。
> 部下「Blobの管理どうします？ファイルシステムかDBかクラウドストレージもありですね」
> 上司「とりあえずファイルシステムを使ってあとで修正すればいいよ」
> 部下「ういっす」
だからあんたの言う「決定の遅延」は本質ではないってことなんだよ。
そこに隠された本当の条件があるだろ？ >>254のような変なことを考えてしまうやつが出てくるのが
オブジェクト指向という名前のまずさだろうな
もしメッセージング指向って名前ならこんな勘違いするはずなかった
メッセージング指向とは：
メッセージのやり取りを実行順に順番に並べて定義する(←プログラム、手続き)ことで
プログラミングする方式
っていう感じの定義になってただろうからな >>285
メッセージング指向言語なら、勘違いしたかもしれないが、
メッセージング指向システムなら、勘違いしなかったかもねｗ
「システム」であれば単一の言語でやることじゃなくて
どんな言語であるかは関係なく、システムを小さなプロセスに分離して
そのプロセス間通信（ネットワーク通信）でシステムを構成するという
言語にとらわれない発想につながる
ようは「オブジェクト指向言語」や「メッセージング指向言語」の
「オブジェクト指向」や「メッセージング指向」部分が勘違いの原因ではなく
そのあとにくっつけてる「言語」が勘違いの原因だよ。
「決定の遅延」とやらは言語レベルでやることじゃぁないって話 あ、もちろん
> 「決定の遅延」とやらは言語レベルでやることじゃぁないって話
は、今だから言えること。
昔のOSがなくて、言語環境がOSそのものである時代に
そんな発想ができなかったのは仕方ない話。
素直にNGが正解だったか
このスレではよくあることだが
キチガイを隔離できないと議論の場にもならないな
いや反論もなくて、ただ単に書き込み数が多いだけで
キチガイと判断されても困るんですけどーｗ
つーかNGにするならさっさとしてくれ。
そうすりゃ俺の書き込みが見えなくなって
「俺の書き込みに反論ができない」から
俺としては好都合
>>286
- もしもシステムの基礎に基本的に新しい方法を採用しようとすれば
かなり最初からやり直さなくてはならない。
- ソフトウェアシステムにおいて全コストの85% は成功裏に導入された後で必要になる。
コストのおおまかな内容は、新しい要求に応える為の変更、後で発見されるバグ等
- 遅延結合を使う事で、プロジェクト開発の遅い時期に得られた知見を
指数関数的に少ない工数でプロジェクトに適用出来る
- プロジェクトを一年以上続けていて、沢山の大切な物が出来上がっているとする。
システムを破壊せずに、何万もの動いているオブジェクトがあるクラスに
いくつかのインスタンス変数を追加して、動的にそれらを再構成する事は出来るだろうか?
- 開発システムをそれ自体のモデルにさせて、開発中に新しいアイデアとして進化させる事
- インスタンスそのものはどのように作られるだろうか? 変数は実のところどうか?
簡単に様々な継承構造の記法を実現出来るか? プロトタイプがクラスよりも上手く働くかどうか決定して、
プロトタイプベースの設計に移動する事が出来るだろうか?
きりがないからやめるけど、どうしてこんな程度が読み取れない？ 失読症？ >>292
永久NGしたいんでコテハン付けてくれ
好都合なら今日だけと言わずずっとそうしようぜ >>280
それは完全に「メッセージ指向派」が悪い。
これ関しては、ID:x3xo3AHAが100%正しい。
プログラミングは結果ではなく手段でしかない。
「○○指向」するのは何らかの目的があっての事だ。
「決定の遅延」によって何を得たいのか、それを明示出来ない時点で
「決定の遅延」なんて使い物にならない、と言っているのと同じ。
ID:x3xo3AHAは、「決定の遅延」によって得たい物が「仕様変更」なら、
それは既に他の方法で十分に達成されているから要らない、と繰り返し述べているだけ。
これ自体は全くその通りだし、
議論を進める為に「他の目的を明示しろ」というのも至極まっとうな意見だよ。
そして>>284にはそれが書いてないのも確かだよ。
>>284内でグダグダ言われていることは、
Evalを持っている言語なら普通に出来ることでしかない。
しかしEvalは普通は要らんというのも事実だし、
メジャーなEval使える言語(JavaScript)もあるんだし、欲しければそれ使え、でしかない。
>>293
それが今対応出来てなくて、「決定の遅延」で対応出来るとでも思ってるの？ >>293
お前さんずれてるなぁｗ
それは単にオブジェクト指向の利点でしか無いだろｗ
俺はずっと>>229の話をしているというのに
> 229 名前：デフォルトの名無しさん[sage] 投稿日：2017/09/02(土) 11:48:07.70 ID:x3xo3AHA [3/34]
> > メッセージ指向が目指したのは「可能な限りの決定の遅延」
>
> 決定の遅延は、問題の先送りと考えればよい。
> 結局あとから問題が発覚するだけにすぎない。
じゃあ、メッセージ指向が目指したのは「可能な限りの決定の遅延」は
大した意味はなく、メッセージ指向と言い換えなくても、
「オブジェクト指向の利点」として今よく知られているものだけで十分ってことだね？
人々は何も誤解していないってことになる。 でもまあこのくだらない会話でも少しは意味があったな。
それは俺が、「決定を遅延させるだけ」ならば、
あとからソースコードを修正してシステムを再起動すれば
実現可能だってちゃんと認識できたってことだ。
つまり決定の遅延と誰かが言ってる時、その「決定の遅延」は本質ではなく、
本質は「プロセスを停止しなくてすむ（サービスの停止時間が短くてすむ）」と
言ってるにすぎないということ
>>296
だからメッセージは方便、唱えていればそれなりに実践はできるお題目だって >>228 でいってるじゃん
本質である「決定の遅延」の徹底の意味の理解ができていれば、メッセージなんて無用ですらあるよ
君の「メッセージ指向」批判もどきはいちいち的を外しているし、端から見れば >>278 に尽きる >>297
> 「決定を遅延させるだけ」ならば、
> あとからソースコードを修正してシステムを再起動すれば
> 実現可能
その再起動で失われる物がなにもなければ別にいいと思うよ では、メッセージ指向なんて言わずに
決定の遅延指向っていえばいいんじゃないですかねぇ？
メッセージに決定の遅延という意味はない
なんで言い換えるの？
オブジェクト指向と言い換えたことで勘違いさせたのと同じ問題を
メッセージ指向でも発生させている。
>>299
> その再起動で失われる物がなにもなければ別にいいと思うよ
どんなものを使っても
ハードウェア障害などでいきなり電源プッチンすれば、
永続化していないなにかが失われると思うが？
そんなもん言語レベルで解決する方法存在すんの？
ハードウェアの冗長化などしてシステムレベルで担保するもんでしょ そうだなー俺だったら「疎結合システム」って名前にするかな
「指向」っていうのもおそらく勘違いの原因になってる。
指向というより、システムだからね
んで、別にそこに言語は問わない。
Smalltalkだの動的な仕様変更だのを目の敵にしすぎでまともな議論ができんよ
>>300
いちいち的を外すね
そもそも「メッセージ指向」が、アラン・ケイは自らのオブジェクト指向をこう呼ぶべきだったって話だろう
「決定の遅延指向」でも「疎結合システム試行」なんでもいいけど
よく理解できない人がいるから方便・お題目としてメッセージってメタファを使ってるんだよ
話を堂々巡りさせるなよ 下手なメタファは混乱のものと
「メッセージ」で何も理解出来ない。
そもそもメッセージは手段であって
実現したいことじゃない。
実現したいことを語らず手段から入るから
だめなんだよ。
>>301
なんでこの期に及んまだ「言語レベル」に拘るの？ バカなの？ >>306
疎結合システムは言語レベルで実現するものではない
というのが主張だから。 伸ばしてるヤツが居るときは読まなくていい
コテハン案は賛成
本質ではないこと（書き込み数が多いぞ）という
指摘が多いからIPアドレス変えるわｗ
>>311
してくれ頼む
そっちにとっても都合がいいんだろ
さっきそう言ってたじゃないか なお、変えた所でレス内容見れば誰かわかるから
問題ないだろ？というスタンス
単に同じIDがたくさんあることに対して
ストレスを感じる人への救済策ｗ
特徴的な長文だからid変えたって無駄だよ
何度でもNGされる
でもそれじゃ不便だろう？
だからコテハンをつけてくれ
毎日NGする手間のせいでみんなが迷惑してるんだよ
>>314
ほらよ。してやったぞ。
なお他の誰かとかぶっていても俺は知らん わかりきった単純作業はしたくないの
みんなプログラマだから
お前が少し協力的になるだけでみんなが喜ぶ
なんでそうしない
他人に迷惑をかけたいのか？
>>316
その理屈だとコテハン付けても
俺は何もメリット無いじゃん？ｗ >>317
良し
死ぬまで絶対にコテハン変えるなよ >>319
お前は反論を受けて反論し返す労力がなくなって楽になるだろ
Win-Winの関係だ
じゃあなバイバイ >>323
> お前は反論を受けて反論し返す労力がなくなって楽になるだろ
いや、別に？
なんのために匿名掲示板に
書き込んでると思ってるんだｗ 固定ハンドルネームの意味は少なくとも
NGにしたい人に対してお願いして
付けてもらうものじゃなかったと思うが
>>330
NGならIDでできるだろ？
それなら俺には手間はかからない
やるなら今ある情報で勝手にやってくれって話
俺は自由にやりたいようにやる >>331
おまえ自身が実践してるようにIDは変化するんだよ 「あ」はその点、潔かったな
それと比べてこいつは言うことも馬鹿馬鹿しいが性格が姑息だ
>>332
変化しても見つけたらそばから
NGすりゃいいだけじゃん？
レスするぐらならNGにすればいい >>282
まったく読めてないな
誰がうまく行くなんて言ってるんだ
お前のやりたいことは上から下に流れる行番号プログラムが一番お似合いなんじゃないか? 未だにコテハンに拘るやつって・・・
何歳？ガイジ？痴呆老人？
日本人エンジニアとしては優秀
何度でもリピートユアセルフが日本人エンジニアの信念だからね
オブジェクト思考の設計とRDBMSの理論って
多分似たような考え方が多いんと思うんだけど、
それぞれ別々の用語で語られるから整合性をとるのが
大変。
>>339
>> 多分似たような考え方が多いんと思うんだけど、
似たような考え方はない
>>それぞれ別々の用語で語られるから整合性をとるのが大変。
お前のアタマの出来の問題 久しぶりにスレ読んだが
>>224
＞何がどの順で実行されているか明瞭
それは手続き型の逐次性であって
アランケイの言うメッセージングとは関係ない
>>228
＞メッセージ指向が目指したのは
＞「可能な限りの決定の遅延」
こっちの方が元祖に忠実な解釈 >>282
＞メッセージングとは「手続き」のこと
＞相互作用とは「手続き」のこと
違う
＞何がどの順番で実行されるか一目瞭然に
＞なるよう念頭に置いて、逆算してクラスを設計する
それはオブジェクト指向設計ではない >>285
＞メッセージング指向とは：
＞メッセージのやり取りを実行順に順番に並べて
＞定義する(←プログラム、手続き)ことでプログラミングする方式
違う
むしろ手続き型の逐次性に縛られない
実行時に自由な順序で処理できる
のがメッセージング指向 実装は関数型か手続き
パッケージングはオブジェクト指向
システム相互作用はメッセージ指向
今のところこれが最も楽だね
システムの隅々までオブジェクト指向に執着する意味はない
>>342
アランケイの言うことなどあてにならないから
斜めからとらえてるんだよ
オブジェクトの外が重要→相互作用の手続きが重要
という風に お前の妄想とアランケイの発想とどっちがあてになるかっていったらアランケイだろｊｋ
>>347
そうそう
オブジェクト指向の元祖だからね
別に盲信する必要もないが
このスレの批判は単に的外れだな >>349
アクターモデルとメッセージモデルは近い
というか影響を受けたものだから
別に似ててもおかしくないよ カール・ヒューイットのアクター理論はアラン・ケイのSmalltalk-72の方便・お題目であった「メッセージ」を
問題領域を並列処理に限定して真面目に定式化し実装（PLANNERの拡張）を試したものだよ
ケイも後出しでアルトにもっとマシンパワーがあれば似たようなこと（ただし定式化には興味がなく実装の方）は考えてた
みたいなことは言ってる
アクターモデルほど並列化しなくても
OOには手続き的な逐次に囚われない要素がある
IF文と違って継承や多態したメソッドは
コード記述の順番通りでなく
クラス階層に基づいて呼ばれるし
>>357
まとめるとそれってつまりアクターじゃん！！ >>358
こんなふうにメッセージングやその先の遅延結合を実装や実行中のことだけに限定しがちだから
「決定の遅延」って言い換えた方がいいって>>228で書いてるとおりの展開だな
「決定の遅延」にフォーカスできていれば、ケイのメッセージ指向はアクター理論と
そもそも問題領域が違うんだから混同しようがないよ 神のごとき傲慢さで何でも事前に決めてしまわないことだよ
OSや言語処理系はもちろん、成果物にすらそうした態度をサポートするしくみが期待される
というのがケイのメッセージ指向のオブジェクト指向のキモ
モンキーパッチでベタベタ
後付け修正をかけてイミフにすることだよ
違うよ
モンキーパッチのような姑息な手を使うような局面の話ではなく、もっと根本的な問題も後から変えられるように
作る and/or それを言語処理系・OS等にサポートさせよう という話だよ
http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeringAnOxymoron.pdf
に挙げられている例としては
- How are instances themselves made? インスタンス変数はどのように作られるべきか？
- What is a variable really? そもそも変数というものはどうあるべきか？
- Can we easily install a very different notion of inheritance? まったく別の継承機構を思いついたらそれを試せるか？
- Can we decide that prototypes are going to work better for us than classes, and move to a prototype-based design?
クラスベースよりプロトタイプベースの方が使いやすいと判断したら、途中から移行できるか？ >>367
いかん ×インスタンス変数 ○インスタンス（＝オブジェクト） >>367は素晴らしい
これ読んだら、意味ない、必要とされてない、ってことが良くわかって良いでしょ
世迷言の類だよ -デザインパターンとともに学ぶ-
オブジェクト指向のこころ
-デザインパターンとともに滅ぶ-
オブジェクト指向のこころ
>>362
>>358は
＞実装や実行中のことだけに限定
したつもりはないが
そこまでの流れで
アクターとの違いが疑問になってたから
典型的なOOの挙動を例に挙げたんだよ >>370
デザパタは古くないよ
たとえばイテレータが標準で使えるとか
新しい言語が直接サポートするようになったから
自力で実装する必要がない場合も増えたけど
アルゴリズムと同じで知ってて損はない
ただたんにOOの新しい流行って意味なら
今はDDDとか DDDはもう古い
当たり前のように使われる枯れたデザパタと似たようなポジション
逆に言うと使いこなせていない場合は初心者の烙印を押される
DDDはオブジェクト指向もレイヤーが上
関数型のほうが相性がいい面もある
DDDのサービスとDCIのコンテキストの違いを語れるくらいにはなりたい
> モンキーパッチのような姑息な手を使うような局面の話ではなく、もっと根本的な問題も後から変えられるように
> 作る and/or それを言語処理系・OS等にサポートさせよう という話だよ
つまりアプリケーションの再インストール
ただしOSは再起動しないことが条件
それってWindowsは実現できてるじゃん？
もしかしたらOSの再起動をしても良いかもしれないな。
根本的な問題を変える時、OSを再インストールすることで実現できる。
きっとそれは違う！というのだろうけど、
それって「根本的な問題を後から変えられる」が本当に求めているものではなくて
「システムの停止時間がほぼ0に近いこと」が本当に求めているものではないのかね？
>>384
アルトで動いていた暫定ダイナブック環境から40余年
![オブジェクト指向システムの設計 173 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>1枚](https://upload.wikimedia.org/wikipedia/commons/9/91/Smalltalk-76.png)
そこらのパソコンもだいぶケイの考えるオブジェクト指向（メッセージ指向）をサポートできるようになったってことか
できたらアップデートするアプリケーションも再起動しないで済む仕組みだとなおいいね >>387
> できたらアップデートするアプリケーションも再起動しないで済む仕組みだとなおいいね
結局それはトレードオフの問題だからね。
アプリを修正したら即反映できるかっていったらそうとは限らない。
メモリ内のデータ構造の変更が必要になることが有る。
だから単純にオブジェクトを入れ替えるだけではなく
データ構造的に互換性がある形にするか
新旧両方のデータ構造に対応させるか
データ構造の変換機能（マイグレーション）が必要になる。
で、それが面倒だから本当に永続化しなければいけないものを限定して保存することで
再起動してそれ以外の重要ではない部分を破棄させる。
だからOSや言語だけで対応できることじゃないんだよ。
今でもやろうと思えばできるが、コストがかかるからやらないってこと またオブジェクトの入れ替え（コードの修正）と言っても
通常は一箇所だけやればいいってもんじゃないからね。
ある機能を実現するために、複数のオブジェクトを修正しなければいけない
それを一括で適用する方法はないだろう？
だからアクロバティックなことをしなければいけなくなる。
つまりコードを修正しても、無効フラグなどで新しいコードが
使われないようにして、互換性を保ちながらコードを修正していって
あるとき一気に切り替え。そして徐々に古いコードを削除していく。
ってなことをやるぐらいなら、夜間にバージョンアップのメンテで
数時間停止します。の方がマシだったりする。
もちろん無停止システムもあるだろう。その場合は
サーバー複数用意して切り替えるとかね
結局はコストと時間を無制限に使えるというのであれば
アランケイの理想は実現できますよ（＝不可能という意味）という話でしか無い
サービスの利用が中断されないならアプリケーションを再起動したって何の問題もない。アップデートされるアプリケーション自体にその機能を持たせる価値がどれ程あるのか？
>>388
> メモリ内のデータ構造の変更が必要
まあそれを必要としないのがケイの主張する「決定の遅延」の徹底（と言語やOSによるサポート）のミソなわけなんだが
長々と書いている内容を読んだかんじ、まったくイメージがつかめてないんだろうな… >>391
いや「ミソ」とか言ってごまかすなよ。
今度はお前が説明する番だろ
（やっぱり理解してないのかな？） 変更するのはデータ構造だけじゃなくて
データの意味が変わったりもするからね。
そういう場合に変更機能はどうしても避けられない
OSの定期的な再起動は
現実的に仕様がないと思うけどね
現代のOSは複雑だから
Smalltalkの遅延結合の思想は
理論的には良いけど
現段階で本当に実現できるかは不明
Smalltalkで動かしながらデバッグできるっていうのと
現代のOSとではシステムの複雑さが違い過ぎるから
再起動は必要ない代わりに不具合が出たりするかもしれない
>>392
イメージできてない人に説明するのはかなり難しいよ
まして当事者の協力が望めないこの状況ではほぼ不可能だと思う >>396
じゃあイメージしている人に対して説明すればいいだろ？
お前が説明しないのが問題だって言ってるんだから 前から疑問だったんだけど「あらゆる意思決定の遅延」の話がなんで「無停止デプロイ」の話にすり替わってんの？
全く別の話だよねこれって
>>395
> 現代のOSは複雑だから
結局そこなんだよな
システムが巨大でインターネットを介して世界中にの複数台の
サーバーで一つのシステムを構成してるっていうのは
昔の一台の構成のコンピュータでアプリを動かすのとは訳が違う
せめて遅延結合とかメッセージとかじゃなくて、
処理の非同期実行と呼んでいれば、ウェブサービス＝クラス
サービスを実行してる仮想マシン＝インスタンスと無理やり
結びつけることも出来たかもしれないね。言葉は重要だｗ
でも非同期実行だと、サーバーが再起動したとしても最終的に処理できればいいわけで
アランケイが本当に目指していたことである、プロセスを再起動せずに更新反映は
必要ないってことになっちゃうかｗ
まあすべてを非同期にする必要はないだろうけど、要所要所で
非同期で処理しておけば、システムの更新もしやすくなるんやで >>398
> 全く別の話だよねこれって
結局のところ、意思決定の遅延が何をもたらすのかを
説明できてないのが原因だろうねｗ
あらゆる意思決定の遅延
→それがあると何ができるか？
→プロセスを停止せずに変更が可能 （ここが一番重要）
→停止して変更すればよくね？ （これにうまく反論ができない）
→停止するとつかえなくなる時間がー （苦し紛れの理由）
→それらはデプロイ技術で解決できること わからないことは何も無いが、俺が勘違いしている可能性はある。
だが勘違いしている俺には、その事実がわかるはずもない。
だから他人から見て間違っているというのであれば
それを説明しろって言ってるだけなんですがーｗ
>>400
→それがあると何ができるのか
→プロセス停止しないで変更可能(ここは全然重要じゃない。無停止デプロイは副次的な効果のうちの1つでしかない)
正しくはこうだろう
ここから間違えてるから議論が明後日の方向に突き進んでる いや、だから副次的な効果ではなくそれ以外の真の効果（なにそれ？）が
言えないのが問題だって言ってるんだが。
間違ってる場所を指摘するだけじゃなくて正しい効果とやらを言えよ
だからいつもデプロイ技術で解決できちまうんだよ。
ちなみにさっきも言っているが「変更」自体はプロセスを停止して
リセットすることで、行うことができる。
そのリセットにかかる時間はデプロイ技術で短くなってきており
リセットしないまま慎重に時間をかけて変更するよりも、
変更してリセットしてセーブポイントから再開した方が早い
アランケイはリセットしたほうが早いというのを
計算に入れることができなかったんだろうね
正しい効果なんてとっくに明確になってるだろ「意思決定を遅延させることができる」
そのまんまだよ
データベーススキーマが完成するまでアプリケーションの開発チームは何もせず待機するのか？
そうじゃないだろう
普通はモックやスタブを使ってアプリケーションを開発する
これはデータベーススキーマに関する意思決定を遅延したということだ
そしてこういった意思決定の遅延を普遍的なモデルとして再考してあらゆる問題に適用しようぜというのがメッセージ指向の本質
無停止デプロイの話なんてどこにも出てこないんだよ
無停止デプロイはメッセージ指向を応用すれば簡単に実現できるね程度の枝葉の話だ
「意思決定を遅延させることができる」
→それがあると何ができるか？
→プロセスを停止せずに変更が可能 （ここが一番重要）
ほらまた同じ流れｗ
>>407
> データベーススキーマが完成するまでアプリケーションの開発チームは何もせず待機するのか？
> そうじゃないだろう
> 普通はモックやスタブを使ってアプリケーションを開発する
> これはデータベーススキーマに関する意思決定を遅延したということだ
データベーススキーマに関する "本物の実装" を遅延させただけ
データベーススキーマに関する "意思決定はなされた" からこそ
モックやスタブという "偽物の実装" を遅延させずに早期に開発することが可能なった
これが正しい解釈だからねｗ > 無停止デプロイの話なんてどこにも出てこないんだよ
それがでてくるんだよなぁ。
停止して良いのならば、静的型付け言語でコンパイルして完全に型が
決定していようとも、再コンパイルすることで変更することができる。
停止していいならばね。
だからプロセスを停止するかしないかだけが焦点となってしまう。
世界改変のためには一度世界を滅ぼす必要があるのか！
安心しろ。世界を滅ぼさなくても一部だけを修正すればいいだけだ。
そしてソフトウェアは世界じゃない。
止めてリセットして同じところまで再開することが可能なのに、
わざわざ止めずに修正する必要なんて無いんだよ。
だめだこりゃ
話を聞かない人間に物事を理解させることほど難しいことはない
そりゃお前が「物事を他人に理解させるための説明」を
何一つしないからだな。
「話を聞かない」の前に、お前の話はどれだよ？ちゃんと反論してるだろ
その俺の反論した話を聞かないのはお前だろ
この議論はID:FAEJW2nXのほうがまともだね。
優越コンプレックス餓ひどい奴がいるな
かわいそうに
>>407
意思決定が遅延できることには価値があるけど、それにはトレードオフが伴う
それを理解せずに普遍的なモデルとしてあらゆる問題に適用しようぜって言ってるうちは
世迷いごとと言われて当然
まずアラン・ケイの主張に対して自分たちのスタンスを明確にしたら？
困ったら「アラン・ケイの主張なんだから」じゃ議論にならんよね もう一つ言っとくと無停止デプロイの類は
入れ替え可能なコンポーネントについて事前に意思決定してるからできる事なんだよ
遅延可能な意思決定の範囲ついて事前に意思決定をしてる
アラン・ケイがトレードオフについて理解できてないとは俺は思わないけどね
全てがオブジェクトが入れ替え可能というふうに
事前に意思決定をしているアラン系（笑）
開発プロセスを止めて意思決定を待つ必要が無いってことなら大きいな
運用中のシステムを一時停止する話とは全然違う
>>421
もう一回言っておくね。
例えばC言語で、完成してないモジュールを勝手に定義して
自分の担当のモジュールを作ることは出来ます。
止めれば良いのだから、モジュールが完成してから
再コンパイルして変更することも出来ます。
これがあなたが言ってる「意思決定を待つ必要がない」と
いうことそのものです。 これからは開発プロセスを止めて意思決定を待つ必要が無いという開発を
>423のことと定義しましょう。実際その通りなのですからね。
なんかこいつ>>307っぽいな
端から理解する気なんかないくせに難癖付けて絡んでくるの
相手するだけ時間の無駄 そもそも立ち位置がアンチ「アラン・ケイ」＆「Smalltalk」だから
それらに関係しそうな主張はいっさい聞く耳もたないし
もしかしたら思考も意識的に停止させてるっぽいから
説明尽くしても届かない
>>426
少なくとも俺はアラン・ケイを尊敬してるよ。
アスキーのアラン・ケイ本を何度も読み返すくらいにはね。
以前の議論はともかくとして今日の議論は
ID:0nrSN7bk や ID:hF16Uo8A より
ID:FAEJW2nX のほうが言ってることがまとも
議論から逃げて個人攻撃するしかできないのなら
端から難癖つけて絡むやつと同レベルだよ >>425
お前のそのレスは、難癖つけてるだけか？
それとも議論か？よく考えたほうが良いよ >>418
別に困ったからじゃない
アラン・ケイの主張なんだからアラン・ケイの主張を読み解くところから始めようというだけ >>430
教祖様の主張なんだから教祖様の主張を読み解くことから始めようという言い方で
無宗教の人を勧誘する行為はマヌケだなって思わない？
そんな宗教に入りたくもないのに、なぜ自ら洗脳されるために勉強しなければらないのか？
まずは信者のお前が、どういう宗教なのかを自分の言葉で語るのが最初だろ
読めばお前も信者になるはずだっていう考えは
すごくマヌケだよｗ >>427
ID:FAEJW2nX ほどの人物ならちゃんと読んで咀嚼しようと試みれば疑問はいくらでも出てくるはずなのに
読んでもいっさい疑問はないとつっぱねる
>>307だと分かった時点で、俺はいっさい相手をするつもりはなかったけれど、それと知らずに
善意の ID:hF16Uo8A が >>407 でアラン・ケイが挙げているよりもっとイメージしやすいところを挙げてくれているのに
それに対してだってとんちんかんな反応を繰り返すだけ
これ以上、なにをどうせいっちゅうんじゃ？ >>432
なんで疑問が出るんだ？お前は疑問が出てるのか？
読んだら誰だって疑問が浮かぶはずだと思ってるのか？
どういう理屈なんだそりゃｗ
当時の時代背景ではそうだっただろうね。
今当てはまってないのは、時代が変わったからだね
という納得しか無いわｗ
> >>307だと分かった時点で、
「俺は相手が誰だか見抜きました。すごいだろー」
っていうのは今の議論に何の関係があるんだ？
それこそどうだって良いことだろ
> これ以上、なにをどうせいっちゅうんじゃ？
アランケイを読んだ上で、俺独自の意見を言ってるんだから
それに対して反論してくれればいい。お前すべて見なかったことにしてるだろｗ
俺が理解してないというのなら、理解していないならばこそ俺の意見に穴があるはずだろ？
その穴をお前はつけばいいだけなのに「教祖様の話を聞けば改宗するはず」と繰り返してるだけ
えとな、自分の言葉で説明できないのは、理解してないからなんやで？ 「オブジェクト指向」には抽象データ型をクラス等で実現するストラウストラップのそれとは別にアラン・ケイのそれがある
よくメッセージングで象徴されがちだけど、「決定の遅延の徹底」という真の目的まで言及されないことが多いから要注意な
ってなことを紹介してるだけなのにどうして宗教の押しつけだの教祖がどうのこうの難癖つけられるのかわからん
「カプセル化、継承、多態性」に象徴されるストラウストラップの考え方を紹介するとこれも宗教なのか？
むしろアンチという宗教の押しつけをやめてほしいわ
> 「決定の遅延の徹底」という真の目的まで
それは目的じゃない。手段
「決定の遅延の徹底」ではなく「決定の遅延の撤廃」と言い換えれば、
決定の遅延の撤廃が真の目的だ！と言われた時に
お前はなんで？って聞き返すだろ。
これは目的じゃなくて手段だからだ。
わずか30秒の速攻レスにもうお手上げかなｗ
速攻でレスしたんだから、気づいてないはず無いよね
早く決定の遅延を徹底する目的
何のために決定の遅延を行うのかってのを
言ってほしいものなんですがね
まあここまでいくつも出た目的をさんざん打ち破ってきたので
これ以上目的が思いつかないってのもわかりますがねｗ
つくづく独りよがりの哀れなやつだな…きっと長生きするよ
ほんと議論する気ねーのなｗ
そのくせそんな書き込みだけはすると
決定の遅延の目的はシンプルで明確だよ
システム開発において「依存元に着手する時期 <= 依存先が解決する時期」という不等式は必ずしも成立しない
むしろ社内政治の都合で不等式が成立しないことの方が圧倒的に多い
これはコーディングフェーズだけの問題ではなく企画から運用まで様々なフェーズで起こりうる問題
依存関係木の葉から順番に問題を解決するやり方ではとてもじゃないが納期には間に合わない
なので依存先の解決を待たずに依存元の解決を可能にして並列に処理しなければならない
そのためには決定の遅延を導入する必要がある
>>440
コーディングフェーズの話をしてくれ
単に仕事をする上で仕様等が決まっていなくても
こうなるだろうという仮の"決定"を行って
先に作業をすすめる。あとで本当に決まった時に
仕様変更するという話にしか聞こえん
それだと別に静的型付け言語でコンパイルするようなものでも
仮の仕様を先に決定して、あとから修正することも可能だろ 一般論の話をすすめるのなら、契約が済んでいなくても
待ち時間を無駄に過ごすぐらいなら、先行して作業することが有るだろう
だけど契約することなく終わってしまえば、その作業は無駄になる。
トレードオフの話になってしまって、決定の遅延は必ずしも正解ではなく
徹底するのはやめた方がいいという当たり前の結果になる。
で、まだこのまま一般論の話を続ける？
当てはまらなくて意味がないから、
さっさとコーディングベースの話をしてほしいんだが
せめて「疎結合システムは言語レベルで実現するものではない」とかいう的外れな拘りから離れられない限り議論なんて無理
もっともその縛りを解いたら、ケイの書いている「決定の遅延の徹底」のメリットの例に疑問も異論はないんだろ？
議論しようにも争点が見当たらないよ
コーディングベースの話がしたいなら次世代言語スレでも行けば？
>>443
だから、俺が言った（？）言葉を再掲して終わりじゃなくて
それに対してお前の意見を言えよｗ
お前の意見じゃなくて俺（？）の意見を、
お前が言ってるだけじゃねーかｗ >>444
じゃあ何の話をしたいんだよｗ
一般論の話で決定の遅延はトレードオフなんだから徹底するものではないと
いったはずだぞ。読んでないのかもしれないが。 ああ分かった分かった「徹底」にひっかかってんのね
「徹底」っていうのは文字通り「底まで貫き通す」という意味以外にも
慣用的には努力目標（この場合はそれよりちょっと強めだけど）とする場合もあるんだよ
適用不可能と思われる局面でもそれを克服するために工夫するということはあっても
あきらかに適用したらダメな局面にもバカみたいに例外なく貫き通すって意味じゃあない
生きるのつらくない？
>>442
もちろんコストとメリットのトレードオフはあるがそれはコントロールできるもの
そして評価は統計的な視点で行うべきだ
あまりにも期待値が低いなら無理に利用する必要はない
例えば「契約が取れるかどうかもわからないのに完全な納品物を作る」という決定の遅延は期待値が低いので避けるべきだ
あるいは「同じ取引先の別案件が成功して本案件の契約が取れる見込みが高まったので技術的な調査とテンプレート作成に限定して先行着手させる」という決定の遅延ならば期待値が高いので採用してもいいだろう
その辺りはバランスの問題だな
なんらかのリスクがあるから決定の遅延は絶対にダメだなどというのはあまりにも思慮に欠けるよ やっぱり一般論の話の方をしたいのか（苦笑
オブジェクト指向とは全く関係ないな
なんか話がアランケイの話から
オブジェクト指向にすり替えられようとしてるな
気づいてよかった
>>387
> できたらアップデートするアプリケーションも再起動しないで済む仕組みだとなおいいね
結局それはトレードオフの問題だからね。
アプリを修正したら即反映できるかっていったらそうとは限らない。
メモリ内のデータ構造の変更が必要になることが有る。
だから単純にオブジェクトを入れ替えるだけではなく
データ構造的に互換性がある形にするか
新旧両方のデータ構造に対応させるか
データ構造の変換機能（マイグレーション）が必要になる。
で、それが面倒だから本当に永続化しなければいけないものを限定して保存することで
再起動してそれ以外の重要ではない部分を破棄させる。
だからOSや言語だけで対応できることじゃないんだよ。
今でもやろうと思えばできるが、コストがかかるからやらないってこと 要点だけ言っておくと、アランケイが目指したシステムっていうのは
当時の世界観でのシステムであり、当時の世界観の
システムっていうのは言語そのものだった。言語がOSだと言っても過言じゃない。
だからアランケイが目指したシステムは今では言語で実装するものではなく
OSやアプリケーションレベルで実装したほうがよい。
アランケイが目指した再起動なしにオブジェクトを入れ替えられるという機能で
実現したかったものは、オブジェクトよりも大きな単位であるアプリケーション
・サービス・OS・仮想マシン・コンテナなどの単位で入れ替えることで実現できるようになった
>>450
> メモリ内のデータ構造の変更が必要
やっぱ読んでないんじゃん… >>440
アランケイの文脈から外れるけど
依存関係逆転とかはOOの原理のひとつだし
修正しやすいのはOOのメリットだと思う
>>441
Javaのインターフェイスと
Rubyのダックタイピングじゃ
修正の柔軟性が違ってくる >>451
そうだよ
アランケイの遅延決定の話は
OSレベルまで射程範囲がある
だけどだからこそ本当に
理論が実現できるかは別の話で
Smalltalkのシステムを現代のOSに
そのまま適用できるかというと大いに疑問
あのままだと動的で自由過ぎて
収拾がつかなくなりそうな予感がする >>452
だから自分の意見を言えって
俺が言ったことを復唱しても、
俺が言ったこと以上の意味は持たない
>>453
OOの文脈の話なんかしてない
アランケイの世界が今と外れてるって話をしてる
> Javaのインターフェイスと
> Rubyのダックタイピングじゃ
> 修正の柔軟性が違ってくる
トレードオフ。Rubyのダックタイピングはインターフェースがないのではなくて
インターフェースは有るが、明示的に書かないってだけ。
ソースコードで書く代わりに、ドキュメントとして書く
ひどいものになるとソースコード読んで同じ名前のメソッドの
利用状況から判断しろになるがだがｗ
いずれにしろ、コードとして書くか、ドキュメントとして書くかの違いで
書く量は減るが読む時に苦労するのがRuby。Javaはその逆 >>455
＞トレードオフ
これはそうだが
＞インターフェースは有るが、明示的に書かないってだけ
仕組みとしてない
（似たことをできなくはないが） >>456
例えば○○メソッドを持っていること
というのもインターフェースだよ
それをソースコードとして表現するか、
ソースコードとして表現できないから
ドキュメントとして書くかの違い 要するに、アランケイのOOは
現在では
「粒度がおかしい」
アランケイは、生態系がどうとか、インターネットの機器がどうとか、言うが
粒度がおかしい
オブジェクトに持ち込むようなことではなかった
アンチ-アラン・ケイ教の布教だから
相手するだけ時間の無断
俺に言い負かされて反論しないんじゃあ
そりゃ時間の無駄だろうね
ID:FAEJW2nX とアラン・ケイの対立軸は
今のOSが最適解だとするか、そういう態度が間違いだとするかだな
あとID:FAEJW2nX は自分の結論を前面に押し出してアラン・ケイの意見を潰そうとしているが
アラン・ケイは「決定の遅延」はあくまで次善の策だと予防線を張っていて謙虚さも違う
粒度とかスケール感ってかなり重要で
大型ダンプをそのままびょ〜んと縮小しても軽トラにはならないからな
コックピットが小さすぎて人が乗れないし、きっとエンジンもかからない
アランケイの言ってるようなことはプロセスとかの大きな単位でやれば良いこと
便利そうっつって縮小してオブジェクトに持ち込んでもしかたがない
人間が仕事しやすい粒度ってものがある
アランケイは良いことも言ってると思うけどな
その意見の具現化であるSmalltalkは完全に出来損ないのゴミだけど
「わずか30秒の速攻レス」とか「言い負かす」とか中学生のメンタリティだな
的外れなこと言って呆れられてるのに気づかずに勝ち誇ってちゃ世話ないわ
>>461
「決定の遅延の徹底」が真の目的だとか言っておいて、
今度はアラン・ケイは決定の遅延」はあくまで次善の策だと言ってるなの？
しかも自分の主張ではなく、あくまでこれはアラン・ケイの主張だからねっていうスタンスだしさ
自分の意見を明確に出さず、まともに議論しようとしてないから宗教って言われるんだぞ >>466
>「カプセル化、継承、多態性」に象徴されるストラウストラップの考え方を紹介するとこれも宗教なのか？
カプセル化ってどういうこと？って聞けば具体的にオブジェクト指向の文脈で答えが返ってくるだろ？
ストラウストルップはこう言ってる、ストラウストルップの主張をまず読めとは返されないでしょ
決定の遅延ってどういうこと？って聞いても具体的にオブジェクト指向の文脈で答えが返ってきてるか？
その答えらしきものとして返ってきたのがアプリケーションのライブアップデートとか
データベーススキーマの意思決定の遅延とかそういうのだったからそこに反論されてるんだろ？
そしたらその反論にきちんと答えず、アラン・ケイの考えに対しての自分がどう考えるのかも明確にせず、
最後には「アラン・ケイは〇〇と主張してる」に戻るから宗教って言われてもしょうがないよ
アラン・ケイの主張と関係なく、君らのせいでアラン・ケイがバカされてるじゃん >>463
Smalltalkが出来損ないなのは同意するが
アラン・ケイが次善の策とする「決定の遅延」の実践の場としては
目的外で作られた既存の他の何を使うより幾分かはマシ >>467
その批判は対称性を欠いてるよ
ストラウストラップのオブジェクト指向である抽象データ型のオブジェクト指向は
現在主流で「オブジェクト指向」と言ったときに想像されるものとそれほど祖語がない
だから、カプセル化とはなにかと問う人がいても他の大多数が「オブジェクト指向」の文脈と認識する説明は容易だ
それに対してケイのメッセージングのオブジェクト指向はほとんど正確に語られることがなく
現在主流の「オブジェクト指向」の文脈からも離れた主張だ
ケイの言葉を借りずにどうやって説明できようか
まして全く異質の現在主流の「オブジェクト指向」の文脈にのせなあかん縛りとかどんな無理ゲーだよ
あと蛇足だが、もし「カプセル化とは？」ではなく「抽象データ型とは？」と訊かれたら
やはり「＊ストラウストラップによれば＊“ユーザー定義のデータ型”だ」と答えるよ
リスコフのそれとは違うからね まあアレだな。占いや予言と一緒だ。
曖昧かつ一般論的に言っておけば後から
都合の良い解釈ができると
はいはい電波電波
こんなの真に受けるやつ居ないよ、マジで
80年代ならいざ知らず、今はもう2017年
>>470
それはなかなか興味深い指摘だね
煽りとしてはありがちな事実誤認に基づいていてまったく正しくないが
ここで言うケイの「決定の遅延」の文脈からは言い得て妙ともとれる内容だ
まずケイの件のアイデアは
40年以上動き、変化もし続けているSmalltalk（彼自身も認める出来損ないではあるが）によって
ある程度その実効性が検証・実証されているからアイデアだけと揶揄したり
まして結果にコミットしない「占いや予言」の類とひとくくりにするのはおよそ見当違い
一方で、「占いや予言」がそうであるように将来の状況の変化に対応できるように
将来の状況の変化を見越して“対象物”をその根本を後から“どうとでも”できるように作っておくことは
まさに「決定の遅延」を実践であり
くしくもケイの主張の本質を（おそらく発言者はそうとは意識せずに）なぞらえているようでいて面白い >>471
> （可能なかぎり）それ自体存在させるべきでないというスタンスが示されているよね
そして目的はなくなっちゃってるよね。
手段が目的となってしまっていて、なぜ存在させるべきではないのかが
どこにもなくなっちゃってる。 そしてアランケイの時代とは違い
変更しやすくするのと真逆の方向に進んでいる。
https://ja.wikipedia.org/wiki/Immutable_Infrastructure
> Immutable Infrastructure（イミュータブル インフラストラクチャ）は
> 不変なサーバー基盤のこと。具体的には、一度サーバーを構築したらその
> 後はサーバーのソフトウェアに変更を加えないことを意味する。
> 通常、サーバーにはソフトウェア構成の変更がしばしば行われ、場合によっては
> それがアプリケーションの安定稼働に大きな影響をもたらすことがある。
> また、アプリケーションがサーバーソフトウェアに変更を加え、サーバー環境が破壊されてしまうこともある。
変更できることは素晴らしいと思うけれど、安定動作という点においては危険なわけだ
車を走らせながらその車の修理をするようなもの。最後の手段としてはありだと思うが
通常の運用においては変更できることは、安定した動作の妨げになる。 自称アランケイに詳しい人が、何のために「決定の遅延」を
行うのかを全然説明してくれないから、そこはぼやかして書くけど
ようはアランケイはOSなどアプリとはレイヤーが違う所まで
アプリの手法と同じやり方で目的を達成しようとしていた。
当時は厳密な区別がなかったから仕方なかったとも言える。
重要なのは目的を達成する事であり（アプリと同じ）手段を用いることではない。
つまり「決定の遅延」という手段は必要なかった。
その一つがイミュータブルインフラストラクチャ。
変更するのをやめて壊して作り直すということ。
「決定の遅延」で達成できる目的は「決定を破棄して変更」に
置き換えることが可能である。
国会じゃないんだから否定することが目的の議論は時間の無駄だよ
アラン・ケイを神格化して鵜呑みにすのも馬鹿げているが
その主張をろくすっぽ読みもせずに、なんの役にも立たない、時代が違うと問題領域を取り違えた反論を繰り返すのもどうかと思う
キミもいいかげん「疎結合システムは言語レベルで実現するものではない」とかいう持論への固執をやめた方がいい
> 国会じゃないんだから否定することが目的の議論は時間の無駄だよ
そう。だからずっと反論してくれと言ってる。
> キミもいいかげん「疎結合システムは言語レベルで実現するものではない」とかいう持論への固執をやめた方がいい
それが「否定することが目的」になってるよね？
否定することが目的の議論は時間の無駄だよと言った本人が
否定することが目的のセリフを吐いて、
こいつ頭悪いのかとしか思えなかったが、
俺が言った言葉として受け取ってくれ。
俺が自分の考えを述べているのだから、
単に否定するだけではなく（否定するのを目的としてはいけない）
自分の考えをちゃんと言うように。
アランケイの何かを読めも。全然反論になってない。
否定したいなら反論（自分の考え）を言うように
それこそが時間の無駄ではない議論というものだ。
繰り返し言うぞ。否定することが目的の議論は時間の無駄だ。
俺は自分の考えを言ってる。
自分の考えを言わないやつは
押し付けるやつよりたちが悪い。
お前が間違ってる（どーん！）
勉強すれば俺と同じ宗教に入ることになるはずだ（どーん！）
何を言っても諭しても
言葉尻を捉えてくだらん揚げ足取りで話を明後日の方向へ持って行こうとする
つくづくコミュニケーションに向かない人だな
持論に固執してケイが想定している問題領域と違うトンチンカンな反論を繰り返しても無意味だと再三指摘している
反論できなくなったら
「言葉尻を捉えてくだらん揚げ足取りで話を明後日の方向へ持って行こうとする」
というだけで、どの部分が揚げ足取りなのかも言えないし
正しい方向に持っていくこともできない。
ただただ、それは「揚げ足取りなんだー（ぶつぶつ」っていうだけ
議論にならないのも当然だろう？
ケイが想定している問題領域とはなに？
答 勉強すれば俺と同じ宗教に入ることになるはずだ（どーん！）
コミュニケーションに向かないから
自分の言葉で説明できない
お前が間違ってる（どーん！）
勉強すれば俺と同じ宗教に入ることになるはずだ（どーん！）
はいみじくも、「自分の考え」という錦の御旗をかかげつつ、
しかしその実はアンチ-アラン・ケイ教を押し付け続けるキミの言動そのものだよ
↑こういうのが揚げ足取りな
何故かと言うとこのスレの議論の内容とは全く関係なく
言葉尻を捉えてくだらん揚げ足取りで話を明後日の方向へ持って行こうとしているから
決定の遅延
正しい例「優れた言語の構文なんて簡単に決めようがないから、各々が自由に言語を作って選ぶことにして、それを連携できるシンプルな仕組み（例:http）を用意しよう」
間違った例「神の言語Smalltalkを使え」
さて、また答えられない質問のひとつになるのかね？
ケイが想定している問題領域とやらに
自分の言葉で答えてくれるのを待ってるんだが
まるであの人だな
主張するだけで人のレスは全部無視
新規IDが俺に絡むのってなんでなんだろう？
上の方で誰かがスマホまで用意してーとか言っていたが
それか？
プロレスはもういいんで
もっとタメになるオモロイこと書いてや
Smalltalkに興奮したおじいちゃんの話は退屈
なだけなので止めてや
ケイが想定している問題領域を聞いた
俺のレスはまた無視状態で終わるわけか
>>493
そりゃ簡単な理屈だよ
お前さんのようにダラダラと一日中スレに張り付いて書き込みを続けるような人ばかりではない
最初の書き込みが昼過ぎの人もいれば夕方の人もいる
そしてここに来た人が最初に目にするのは意味不明な理屈で大暴れするお前さんだ
自覚ないかもしれんが悪い意味で凄い目立ってるんだよ
そうなるとその日最初のレスがお前さんへの苦言という形のレスになってもなにもおかしくはないだろ
これが単発が仕組んだようにお前に絡むように見えるトリックな 要するにマトモな理屈を書き込む
書き込む頻度を下げる
この二つを守ればお前に絡む単発などあっという間にいなくなるよ
こんな誤解と偏見で言論レイプされてちゃ
アランケイのズル剥ケイも草場の影でシコっとるで
個人的には俺も>>487と同意見だな
かなり的を得ていると思う
掛け違えたボタンなんだよな
だいたい卵が先か鶏が先かみたいなことになるんだけど
最初の一歩を誤ると、そのあと全部がずれる
ズレまくった典型が北朝鮮で
>間違った例「神の言語Smalltalkを使え」 疎結合システムは言語レベルでやらなくてもできるし、
それを言語レベルだけでやろうとしたSmalltalkは
引きこもりのOSモドキに成り下がって、
多様な言語を含む大きなエコシステムから取り残されて
99.99%の開発者の選択肢から外れてしまいましたとさ
smalltalk信者は何が言いたいんだ？前回も意味不明で、今回も同じ展開だが。
要するに、smalltalkが「決定の遅延」（手段）によって目指したもの（目的）は
現在は他の手法によって十二分に達成されている為、
smalltalk流の「決定の遅延」なんて不要、というだけだろ。
「決定の遅延」をするのが目的ってのは、典型的な「手段の目的化」でしかない。
ワイのレスが一番的をエーテルやろ、おっとこれはギャグなｗ
結局のところ、自称「アラン・ケイの主張を解説してる」君は
アラン・ケイは〇〇と言っているというだけで
自分も理解してないから質問されてもまともな返答ができない
だから原典を読んでみんな感じてねってことだよ
それ以上の話をしても残念ながら無駄
むしろ信者の方が必死だ。全く論理的に反論できてない。
まあ今の時代にsmalltalk信者になるような奴は論理的思考が出来ないという証明にはなったか。
うむごくろう。
>>473
Smalltalk単体だけじゃなくて
RubyやPythonの普及ぶりを見ると
メッセージング式の動的なオブジェクト指向は
一定の成功を収めているのは確かだと思う
アランケイの本来の理想からすると
あくまで暫定的なものだけど >>510
> なんかオレオレ用語じゃないか
インターフェースは元は英語で
オブジェクト指向用語でも有るでしょ？
そのインターフェースをプログラム言語の文法で記述するか
コメントで記述するかの違いはあっても、
インターフェースはインターフェース >>511
んで、メッセージング式って何？
アランケイの本来の理想って何？ >>503
Smalltalk自体はマイナー言語（環境）だが
そもそもWindowsやMacは
オブジェクト指向を取り入れたOS
RubyやPythonがSmalltalkの
影響を受けてるのと同じこと Smalltalkがメソッドを「メッセージ」という名前で実装しているから
メッセージって言ってるだけな気がするよな
ぶっちゃけメソッド呼び出しと変わらんでしょ？（煽りｗ）
メソッドとメッセージが違うというのであれば、
何が違うかを言ってくれればいいんだよ。
もしもそれがメソッドのように呼べ、メソッドのように振る舞うのなら、それはメソッドである
Windows（Macは知らん）のどこがオブジェクト指向を
取り入れたOSなのかを俺が説明してあげよう。
（気に食わなければ自分の言葉で説明するように）
Windowsといえば、まあウインドウが有るわけだが、
そのウインドウはウインドウハンドル（HWND）というもので管理されている。
このウインドウというのは、アプリのウインドウだけではなく
ダイアログはもちろんのこと、ボタンやチェックボックスまでウインドウなのだ。
その証拠にチェックボックスをCreateWindow APIで作成する
Windowsではいろんなものがウインドウクラスを継承してできているわけだ。
もちろん自分で拡張して新しいものを作ることもできる。
そしてそれらのウインドウ（当然ボタンやチェックボックスなども含む）は
メッセージ（ウインドウメッセージ）を使用して相互に通信する。
ほらな？立派なオブジェクト指向やろ？
言語レベルの遅延システムに反対している奴がアラン・ケイの言っていることの何を否定したいのかわからん
70年代にネットに接続したマシン単位で可能だったことが、今は(実・仮想)OSやアプリ単位で可能になるまで進歩したって話で
早すぎる最適化は後でコストがかさむからできるなら避けようみたいな普通のことを言っているだけだと思うのだが…
「アラン・ケイの言っていること」が
何のことか詳しく説明しろって言われてるだけ。
> 早すぎる最適化は後でコストがかさむからできるなら避けようみたいな普通のことを言っているだけだと思うのだが…
その普通のことを、言語レベルでやるもんじゃないよって
普通のことを言ってるのが、アランケイに反対（？）している方なんだよ。
アランケイ信者がなんにも理解せず、
「アランケイが言ってることー」でごまかし続けてるから
こういうことになってる。
あんたもその一人に見えるよ
「アラン・ケイの言っていること」と中身を
書かないのはやめた方がいい。
なんだ要は言語レベルの遅延システムに反対している君は
英語が読めないからアラン・ケイの言っていることの要点まとめてほしいだけなのか
ちょっと違うな。読んだ上で自分の考えを述べているわけだから、
それに反論が有るのなら、アランの考えは違うんだーとかいってないで
ちゃんと自分の言葉で反論してくれってだけ。
まあ別にアランケイが言ってることを（自分の言葉で）まとめてくれても良いんだよ。
> なんだ要は言語レベルの遅延システムに反対している君は
これも少し違うね。
言語レベルの遅延システムに反対しているのではなく
全てを言語レベルの遅延システムと同じ仕組みを使うことに反対している。
レイヤーが違うんだから違うものを使っていいんだよ。
そっちのほうがより適切かもしれない
そこで、そもそも遅延システムの目的は何？という話につながるわけさ
そこをアランケイ信者が言おうとしない（理解不足で言えないってのが正解だろう）
だから、ぐだぐだ話が長引いている。
俺の理解ではシステムレベルで遅延させる目的は、メンテナンス性や変更のしやすさや
安定性や可用性や信頼性の高さのどれかもしくはその全てだと思っている。
（違うというのなら「違う」と言って終わるのではなく自分の言葉で説明するように）
で、メンテナンス性や変更のしやすさや安定性や可用性や信頼性の高さであれば
それは決定の遅延で実現するものではなく、非同期処理や壊して作り直すという方面に
変わってきているということ。
そこに言語レベルで使用されていた遅延システムは登場しない。
一旦稼働したならば、その構成に変更は加えない。加える必要があるならば壊して作り直す。
言語レベルで言えば、プロセス終了させてプログラムビルドして最初からリスタートするようなものだよ。
言語レベルで動かしたまま修正が加えられるといっても、結局システムレベルから停止と再起動をさせられてしまう。
アランケイの馬鹿を未だに信望してる時点でお察し
俺の方が頭いいしなｗ
自分の言葉で説明しろ
↓
丁寧に説明する
↓
無視する
↓
まじで反論はないのか
↓
また勝利してしまった
このループもう飽きたんだけど別スレにフォークしてそっちでやってくんないかな
別スレにフォークwwwwwwwwwwww
最近覚えた言葉を使いたかったのかな？＾＾
> 自分の言葉で説明しろ
> ↓
> 丁寧に説明する
↑これがないんだよなーｗ
いや、有るっていうのなら、
そのレス番にアンカーしてくれればいいんだが。
あ、無視しないで反論している所は、
当てはまらないのは、理解してるよね？
大抵はこの流れ
自分の言葉で説明しろ
↓
的はずれな説明する
↓
反論する
↓
反論に答えられず逃亡
>>527
君の言う言語レベルの遅延システムって何？
具体的にどういう機能を指してるの？
それができると具体的に何がうれしいの？ このスレ、ずっと見てるけど
未だにオブジェクト指向設計のメリットが１つも見えない
そもそも議論ってなんの議論してるのか毎回わからない
オブジェクト指向のメリットにつながるのかと思ってみてるとくっだらねぇ
知識自慢だし
その議論に決着が付いたところでオブジェクト指向のメリットは１つもわからないゴミクズばかり
議論しにくるクソスレ
Smalltalkのオブジェクト指向はそもそも特殊で、
元祖か何か知らんが、今となってはSmalltalkだけが例外で
他の一般的にオブジェクト指向には当てはまらんから
分離するのは賛成。こっちくんな。
>>542
オブジェクト指向のメリットは何だと考えていて
smalltalkにはそれがなくて
他の言語にはそれがあるという
意見で良い？
君の考えるオブジェクト指向のメリットは何？ >>543
× smalltalkにはそれがなくて
○ smalltalkは大風呂敷を広げすぎていて、
OSやマシンレベルでやるべきことまで
言語の機能を使ってやろうとしていた。
言語レベルでは目的がありメリットがあったが
それを盲信するあまりOSやマシンにまで適用しようとし
目的を見失い、決定の遅延をさせるという手段が目的となった
もはやだれも目的を理解していない
その一方、目的ベースで考えている人たちは、Smalltalkにも
オブジェクト指向にも頼らず、OSやマシンレベルで
真の目的（>>531に書いてあるようなこと）を達成すべく
いろんな技術を生み出してきた。
Smalltalkは以前昔のまま。
> 君の考えるオブジェクト指向のメリットは何？
前提としてSmalltalk特有の話は分離させよう。
でないと話は始まらない。 >>535
> 自分の言葉で説明しろ
> ↓
> 的はずれな説明する
> ↓
> 反論する
> ↓
> 反論に答えられず逃亡
俺が読んだ感じだと
すでにアラン・ケイが言っていることとさして変わらないことを反論と言い張る
↓
それアラン・ケイが言っているから同意見でしょ？読んでない、読めてないんじゃ？と指摘する
↓
俺は完璧に理解している反論があるなら自分の言葉で反論しろ
↓
困る
↓
勝利宣言
って感じのループ 逃亡くんはスレ分割して何がしたいの？
見えない敵と戦っているの？
ジャップさあ・・・なんだい、このスレは？
ジャップランド村の土人さんたちは議論ができないって本当だったんだな
すーぐ感情的になって論点ずれて人格攻撃に走る
ファビョの起源はジャップランド土人ってマジ？ｗ
>>545
問題はね
> すでにアラン・ケイが言っていることとさして変わらないことを反論と言い張る
これがどれかを言えないことなんだよ まあ、アランケイのオブジェクト指向は死んだと
アランケイが言ってるっていうのなら、それはそれでいいんだがｗ
>>548
そんなのいくらでも出ているだろう
直近では>>527がそうだし、ちゃんと上の方さかのぼればいくらでもありそうだが？ >>550
自作自演失敗かね？
>>527を言ったのはお前だろ
そして>527の内容じゃわからんから、
>>528や>>536が、ちゃんと説明しろと言われてるのに
ほらまたお前、それを無視してるじゃんか
この流れだよ。 >>551
自分の発言を参照したら自演なの？わけわからんわ
対応している段落まで示さないといけないのは面倒くさいなぁ…
「早すぎる最適化は後でコストがかさむからできるなら避けよう」は
The Fram oil filter principleのところで述べられているんだよ
ついでを言えば、その次のLate bindingにある図で、プロジェクトの途中で得られたノウハウを
早期結合の言語で決めうちして作られたプロダクトだと適用しにくいという指摘がある > ついでを言えば、その次のLate bindingにある図で、プロジェクトの途中で得られたノウハウを
> 早期結合の言語で決めうちして作られたプロダクトだと適用しにくいという指摘がある
これは嘘だね。
別に早期結合の言語でもそうでない言語でも
適用のしやすさに違いはない。
ただ単にノウハウを取り入れてコードを修正して
再コンパイルすればいいだけの話なんだから
ついでにいうと「早すぎる最適化は後でコストがかさむからできるなら避けよう」は
「決定の遅延」とは何の関係もない。
なぜなら、最適化してないコードをもう作ってるわけだろう？
遅延しているのは最適化だけであって、コードは作られている、つまり決定はなされている。
それに「避けようと決定している」という言い方もできる。
つまり避けるぞーっと方針を決定している。遅延せずに。
何が言いたいかというと「決定の遅延」とは何の決定なのか
全く書いてないし、そもそもアランケイが言った言葉なのかも不明。
「オブジェクトの結合の遅延」の話から目的を忘れ、
遅延という言葉だけが独り歩きし、オブジェクト指向と関係ないことにも
適用しようとしている。オブジェクト指向とは関係ない話だから
「決定の遅延」と呼ばざるをえない。
>>554
ちょｗ、おまｗ、読んでなかったんじゃん… >>556
いや？読んでいたけど？
何をどう解釈するとそうなるんだ？
まさか「アランケイが言いたいこと」が
明らかに間違いの部分だとは思わなくてね
結局、早期結合の言語で決めうちして作られたプロダクトだと
プロジェクトの途中で得られたノウハウを適用しにくいと
言いたかっただけ？ すまん。ワイ以外にアランケイに勝ってる奴おりゅ？ｗ
殆どの人は「早期結合の言語で決めうちして作られたプロダクトだと
プロジェクトの途中で得られたノウハウを適用しにくい」と言われると
なんでだ？って思うはず。
プロジェクトの途中で得られたノウハウを適用するのに
早期結合の言語かどうかなんて関係ないじゃんと。
確かにその通りなんだよ。関係ない。
おそらくアランケイが考えていたシステムはSmalltalk上で
すべてを動かし、システムを止めること無く変更を
適用するという前提があったのだろう。それならば理屈はあう。
だけど今の時代は、稼働しているシステムとは別の待機系とか
ステージング環境とか開発環境とか、そういった止められる
環境で開発し、必要ならば止めずにシステムをデプロイ
する技術があるため、早期結合の言語であってプロジェクトの
途中で得られたノウハウを適用できるようになってる。
その点でアランケイが言ったことは今となっては間違いになってるんだよ
うんだからWeb開発はサービス単位で遅延結合が出来てるからいいんじゃないの？
その君の主張は誰も否定していないよ？
アラン・ケイはWeb開発に特化した話はいっさいしてないってだけ
何はともあれようやく話は進んだじゃないか。
アランケイが言ってることとはすなわち
「プロジェクトの途中で得られたノウハウを早期結合の言語で
決めうちして作られたプロダクトだと適用しにくい」
ということだそうだ
それはなぜなのか、それは正しいのか
その話をしようじゃないか。
間違いであることは>>560で書いたとおりだ。
反論を待っているぞ リンクだけ貼って投げっぱなしのジャーマンのやつにレスするな
>>561
アランケイが言った言葉は間違いだってこと？
「プロジェクトの途中で得られたノウハウを早期結合の言語で
決めうちして作られたプロダクトだと適用しにくい」 >>565
そんなのおっさんの開発した言語でできる性能はないよｗ >>561
> Web開発はサービス単位で遅延結合
あんたが言うサービス単位で遅延結合とはどういうこと？
俺はサービス単位で遅延なんかせずに普通に結合していると思ってるけど。
なんか無理やり関係ない言葉を再利用しようとしていない？ｗ
Web開発におけるサービス単位の「遅延」って何よ？ 明らかな間違いはそこ以外無いんじゃないかな？
プロジェクトの途中で得られたノウハウを早期結合の言語で
決めうちして作られたプロダクトだと適用しにくい
というのは間違い。
話を進めましょう
システムレベルの保守性可用性は言語レベルでやるこっちゃねぇ、
停止して再起動すれば良いんだからオブジェクトの結合の遅延は
徹底するほどのものでもねぇってのは最初から俺がずっと言ってることだしね。
そこに戻ったってだけ
先々週のハイライト？ （俺の書き込みじゃないよ）
結局この話に戻ってきたなぁと
295 名前：デフォルトの名無しさん[sage] 投稿日：2017/09/02(土) 20:43:07.29 ID:SLw7DScq [2/2]
>>280
それは完全に「メッセージ指向派」が悪い。
これ関しては、ID:x3xo3AHAが100%正しい。
プログラミングは結果ではなく手段でしかない。
「○○指向」するのは何らかの目的があっての事だ。
「決定の遅延」によって何を得たいのか、それを明示出来ない時点で
「決定の遅延」なんて使い物にならない、と言っているのと同じ。
ID:x3xo3AHAは、「決定の遅延」によって得たい物が「仕様変更」なら、
それは既に他の方法で十分に達成されているから要らない、と繰り返し述べているだけ。
これ自体は全くその通りだし、
議論を進める為に「他の目的を明示しろ」というのも至極まっとうな意見だよ。
そして>>284にはそれが書いてないのも確かだよ。
>>284内でグダグダ言われていることは、
Evalを持っている言語なら普通に出来ることでしかない。
しかしEvalは普通は要らんというのも事実だし、
メジャーなEval使える言語(JavaScript)もあるんだし、欲しければそれ使え、でしかない。
>>293
それが今対応出来てなくて、「決定の遅延」で対応出来るとでも思ってるの？ >>569
え？そうなの？じゃあ
For example, a paradigmatic system such as generalized desktop publishing can
be examined in both worlds, and some answers can be given about why the late
bound one in Squeak is more than 20 times smaller, took even less fractional
person-time to create, and yet still runs faster than human nervous systems
at highly acceptable speeds.
も間違いとは思わないと？にわかには信じられないなぁ… >>572
知らんがなｗ
アランケイのファンじゃないんだから
読み飛ばしたりしてる部分だって有るだろうさ。
あんたがそこが間違いだっていうのなら、
そこも間違いでいいんじゃね？ >>573
なるほど
ではこちらの主張はどうだろう？ここは>>563にも関わる本質部分だと思うのだけれども
とくに問題とは思わなかったと言うことはやはり読み飛ばしちゃってた？
On the other hand, most programmers learn their craft by starting with
“algorithms and data structures” courses that emphasize just the opposite:
sequential logic and nonobjects. This is a kind of simple “godlike” control of weak
passive materials whose methods don’t scale. I think it is very hard for
many programmers to later take the “nongod” view of negotiation and strategy
from the object’s point of view that real systems designs require. 読みとばすっていうか忘れてるんだよ
何年前だと思ってんだよ。読んだの
つーか俺が読んだか読んでないかを追求するのはそんなに重要な事なのか？
仮に俺が読んでないとするならば、それだけすきがあるってことだろ？
そこを攻めてこいよ。
自分の言葉で俺が言ったことに反論してきてくれ
>>544
平気でこういうおかしなレスをする
オブジェクト指向のメリットになんねぇならどっちでもいいだろがそんなとこ
自分の指摘箇所がオブジェクト指向にとってどうでもいいのにこだわってるの君？ またかよーｗ
>>576
だから、おかしいと思ったなら、
どこがどうおかしいかをレスしろって。
ほんと俺ばっかりだなお前 >>578
死ねよ
ちゃんと書いたじゃん
>>544
平気でこういうおかしなレスをする
オブジェクト指向のメリットになんねぇならどっちでもいいだろがそんなとこ
自分の指摘箇所がオブジェクト指向にとってどうでもいいのにこだわってるの君？
解説するよ
まずさ、君はsmalltalkを他のオブジェクト指向言語と違うって主張でいいんだよね？
そしてそれはオブジェクト指向のメリットである部分に抵触してるんだよね？
ここまではおｋ？ >>580
全然OKじゃねーよｗ
Smalltalkは他のオブジェクト指向言語に比べて余計な思想が有る。
その部分を信者どもは優れていると言うが、
余計な部分でありSmalltalkの言語からは消し去るべき部分
言語でやらなくていい部分だからだ。
ここまではおｋ？ Smalltalkの余計な部分というのは
オブジェクト指向とは全く関係ない
ということも言っておかないとダメだったな
>>581
それって俺の質問に答えてなくね?
それはお前が考えるオブジェクト指向のメリットに抵触する箇所なの？ >>582
だったらお前の指摘ってのっけからズレてんじゃん
smalltalkと他のオブジェクト指向言語に大した違いは無いって自分で言ってるけど
みんなにごめんなさいって言えよとりあえず Smalltalkは余計な機能が付いてて
他の言語と比べて出来損ないのゴミである
これに反論できるやつはいないって事？
まずは一つづつ明確な結論を得て行こうよ
一連の議論の発端は>>224, 225, 228
2週間以上もやってるんだね。
単純な質問に答えられず、意味のある反論も出来ないなら
無駄レスが続くだけだからもうやめてくれよ それもこれもオブジェクト指向のメリットを誰も挙げられないからだ
あるような？
ないような？
どこにも明確に書かれていないし
各自が勝手な解釈を垂れるだけ
各自が勝手な郷土研究を発表するだけ
実際はどうだ？と問うと
今度はそれはオブジェクト指向じゃない
お前のは違う、俺のがあってる
技術の統一見解が全くない
ハッキリ言って
捨 て ち ゃ え よ こ れｗ
>>585
そんなの次世代言語スレかSmalltalkスレ行ってやれよ OMTで設計うまく行ってると思ってるんだけど
何か見えてない問題点あるのか?
尊師の教えと違うとか宗教的なことでなくて
3行で言えるメリット
>>589
そうやって反論どころか主張すら曖昧な書き込みするから
いつまでも話が堂々巡りになるんだよ
Smalltalkはゴミ。存在価値なし。それで良いよな？ >>592
比較対象がないとメリットもデメリットもないよ >>595
いや、それが語れないならこのスレいらないだろ
自分の形を知るには他人が必要なんだよ
オブジェクト指向も同様 >>591
> Smalltalkはゴミ。存在価値なし。それで良いよな？
それでいいんじゃね？ｗ
俺は最初からSmalltalkのやり過ぎなオブジェクト指向、
言語とは関係ない部分にオブジェクト指向を適用するのが
おかしいと、アランケイの考えが古いと言っていたのに、
それを理解できてないやつがいるんだよな。IcOpWHLwとか あー、なんとなくわかってきたなぁ
お前ら、ぶっちゃけこれ以外での組み方知らない？
>>597
このスレは既にオブジェクト指向設計をする前提でその上での良し悪しだろ?
じゃなかったら設計全般スレの一つの主張でいいだろ >>600
は？
じゃあ、何をやるにも全くメリットわからないのに
自己流でオブジェクトに分けてそれで何がしてーの？
何がよくなんの？
何に向かって何やってるの？
すげー馬鹿だろお前等
じゃあ、オブジェクト単位で分割するの辞めてみたら？
それでも分割するお前の行動は何か利益を産んでるの？
全く無駄なことやってるの？ >>601
プログラミングのスレでPCの電源の入れ方から質問するようなもんだろ
いちいち初心者に説明してたらキリがない
まずオブジェクト指向について勉強してから出直せ >>602
っていつも逃げるけど
オブジェクト指向のメリットなんてどこにも書いてないし >>542
それは知らないだけだろ
オブジェクトの指向の源流だから
今当たり前に使っている技術も
Smalltalkから生まれてきた
たとえばRubyが「すべてはオブジェクト」だ
っていうのもSmalltalkが元祖
テストフレームワークも
最初にSmalltalkで生まれた >>603
説明してやってもいいけど
使ってもいないのに聞いてどうするの? >>561
＞Web開発はサービス単位で遅延結合が出来てる
マイクロサービスが典型的だな
サービスを分けることでマクロに遅延結合できる
だけど別にアランケイが間違っていたわけじゃなくて
むしろその発想を大規模に発展させた結果だよね
Smalltalk誕生の時代にはインターネットなかったから >>607
議論の軸になるはずだが
予言していいけど絶対お前は説明できない >>603
何と比較したいの？
こういうやり方のほうが俺はいいと思ってるってな意見があれば議論になると思うけど >>608
> マイクロサービスが典型的だな
> サービスを分けることでマクロに遅延結合できる
でもそれオブジェクト指向ではないですよね？ >>608
> だけど別にアランケイが間違っていたわけじゃなくて
アランケイが間違っていたのはオブジェクト指向や
Smalltalkで実現しようとしていた所
マイクロサービスにSmalltalkもオブジェクト指向も関係ない >>609
先にはっきりさせときたいんだけど、
どういう点を論ずるの? >>603
わざわざ書く必要がないほど自明だからだよ。
だけど初心者には分からない。なぜならOOPは大規模じゃないとメリットが無いから。
だから大きい(10k行以上）の物を書き、保守をしばらく続ければ、誰でもわかるようになる。
例えばCの手続き型で書いたとしても、保守しやすく保てば、だんだんOOPに似てくる。
これが分かっているからJava等では最初から初心者をOOP信者として洗脳しようとする。
ところが初心者にはOOPのメリットが見えるはずもない。これが大体のパターン。
500行程度のプログラムをOOPで書いても大してメリットない。当然理解出来るはずもない。
最低3k行程度、出来れば10k行以上書いて保守してみ。いやでも分かる。 >>611
>>612
＞マイクロサービスにSmalltalkも
＞オブジェクト指向も関係ない
いやそうは言い切れない
マイクロサービスは突然出てきた訳じゃなくて
オブジェクト指向からコンポーネント指向や
サービス指向を経由してきたもので
オブジェクト指向が発想の源流 >>614
は？
悪い
俺には全くメリットがわからねぇ
お前のそんな長文を読んでも全くメリットが欠片もわからねぇ >>615
その根拠は？
なんでそれを書かないかな >>616
オブジェクト指向の利点が分からず、君がいっぱしのプログラムを書けるというのなら、
その君のやり方で大規模な物を書いて保守してみればいい。
だんだんオブジェクト指向に似てくるから。
500行程度のプログラムを書き捨てするのなら、大してメリットはないし、当然理解も出来ないよ。
プログラミング言語C++とか読めば、いろいろ具体的にハゲが力説してるよ。
ただその意味は初心者には分からないと思うよ。 >>618
そんなにどこにでも書いてあるなら
リンクを5個ぐらい貼ってみろよ
オブジェクト指向の入門サイトにでもあるんだろ？
なにせ常識らしいからな >>616
ちなみに、分からなければ分からないでいい。
所詮はOOPも手段であり、OOPを用いずとも困ってないのなら、わざわざ使う必要はない。 >>620
違うだろバカ
テメーはメリットなんか知らないだろ >>620
何偉そうにしてんの？
わからないくせに
わかるならいくつでも箇条書きで
書いてみろよアホ 規模が大きくなるほど
手続き型で保守しにくくなる
大規模プログラムで保守性が高まるのは
オブジェクト指向のメリットのひとつで
いろんな入門書に書いてある
>>623
言語レベルではそうだね。
だけど大規模プログラムを保守しやすくするなら
オブジェクト指向にするだけじゃなくて
単純に規模を小さくすればいい
それがマイクロサービスでもある >>619
ひょっとして、手続き型おじいちゃんの土人の方ですか？
屁臭いペチプァの方ですか？ ID:IcOpWHLwが論点を挙げられないのは
テキトーに否定するだけだったからか
>>623
どういう原理で？ｗ
そもそもなんででかくないと効果がないの？
機能10個作るのと機能20個作るので難易度変わるの？
変わるように組んでるの？ >>627
そんなにオブジェクト指向のメリットが常識だって主張するなら
書いてあるサイト探してこいって言ってんだよ
嘘つき野郎 メリットなんてケースによるんだから否定するのは容易い
俺は大規模開発なんてしないもん!とかな
自分の開発対象にあった開発方法をとって、
その上での議論だろ
>>632
論点を挙げられないこと指摘されて邪魔か
さすがクズ なんで見えないのにわかるんだ
口からでまかせばかりだな
>>624
ちなみに俺はそれもありだと思ってるよ。
具体的に言えばJavaScriptの連中が壮絶に酷くて、OOPどころかそれ以前なんだけど、
実際はそれでも結構動いてしまう。
理由は簡単で、サーバー/クライアント構成でデータ管理は完全に分離されてて、
データクエリはhttpでフォーマットもJSONとお決まりで、何も考える必要なく、
JavaScriptは単にGUIの装飾だけやればいい感じだから。
抽象度もそれなりだから50行位で一機能出来てしまって、
5個くらい(=250行)あればまあまあ見栄えしてしまう。
ああこれでは成長せんなーとは思ったね。
この規模なら毎回コピペ＋書き捨ての方が生産性高いし。
ただ、従来はデータ管理等も全部自前でやるから肥大化するのであって、
正直OOPでがんばって自前でやりくりするより、
既製品のDBとか使ってマッシュアップするJavaScript的開発の方が楽だから、
今後はそうなる気もする。 >>630
> そんなにオブジェクト指向のメリットが常識だって主張するなら
> 書いてあるサイト探してこいって言ってんだよ
これを主張した奴はこのスレ内にはいない。
つまり、日本語でおｋ
俺が言ったのは「プログラミング言語C++」で、これは本だ。
お前が知りたいのなら、おまえ自身が探してきて、
ここにこんなこと書いてますが合ってますか？と訪ねればいいだろ。 >>637
今どきはJavaScriptでもwebpackとかあるんだし
使い捨てせずにモジュール化して使いまわすよ普通は
OOPかどうかは別として >>637
ああそういう所はあるよな
Web（アプリ）って単体のコードは
壮絶に汚くなりがちだし
OOPも退化してる
だがフロントエンドとバックエンドを分けるとか
Webの仕組みが上手くできてるんで
それでも何とかなっちゃうんだよな 張り切ってるヤツは
俺の考えにそぐわない物は間違いである
って主張なの？
結局こういう論理なんだよな
オブジェクト指向を使うと従来よりも保守性や拡張性が向上する場面が有る
↓
オブジェクト指向は保守性や拡張性をもたらすものである
↓
保守性や拡張性をもたらすにはオブジェクト指向を使ったほうが良い
↓
保守性や拡張性がある＝オブジェクト指向である
↓
マイクロサービスとかクラウドとか保守性や拡張性が有るやろ？
それらは全部オブジェクト指向なんやで？
オブジェクト指向とは一体何なのか？
>>641
っていうか
この技術は効果無しの似非技術で
間違いなくね？
そんなに当たり前の技術なら
メリットなんてググったら
その仕組みから明確なものが出てきていいだろｗ
こんなに勿体ぶる必要もないし
仕組みがわかれば大きいプロジェクトでないと効果がないも
わかるけどそもそも
正しいオブジェクト指向が反映されたソース自体よくわからんし そもそもなぜここまでメリットの説明できないものを
効果がありそうに言うの？
お前らは
これ役に立たないだろ
だから説明できないじゃん
お前らがアホなんじゃなくて
どの資料にもサイトにも
具体的なメリットおよびその効果をもたらす仕組みの記述がねぇんだよ
だから誰も具体的な話がよくわからないが正解だろこれ
んでオブジェクト単位で分けたところで
書く必要のある処理を書かなくて良くなることはないし
保守だの拡張だのなんてあるわけないし
なんで騙されてるって気が付かないんだ？
>>639
使いまわせればそれに越したことはないんだけど、
チョイ変更が必要なときどうするかだよ。
そこを共通モジュール側に変更として取り込むか、使い捨てと割り切ってコピペ+改変で乗り切ってしまうか。
やってみて分かったんだが、GUIって実際に使ってみないと使い勝手が分からないことも多くて、
張り切って作ってもゴミだとか、
或いは一時凌ぎで適当に作ったら意外に使いやすくて拡張していき、おかげで酷いことになるとか結構あって、
どれを取り込むべきか最初には分からないんだよ。
（俺にGUIのセンスが無いといえばそうだが）
だからとりあえずコピペ+改変で組んでしまって、
後で本当に使える場合はもう一度共通側に取り込むほうがましだと俺は判定している。
二度手間ではあるが、変に最初に取り込んで除去する方が死ねるから。
>>640
イエス。 >>644
じゃあ他の手法でやってりゃいいじゃん
自分でどういう設計するか自分じゃ決められないのか >>645
騙されてるって、誰がなんのためにプログラマを騙すんだよ
なんらかの陰謀論のせいにして思考停止ですかw >>648
c言語が完璧過ぎたから
オブジェクト指向言語って名目で売り出したかったんだろ？
販売戦略の一環だろこれ そろそろitproとか日ソフに
オブジェクト指向役に立ちませんでしたって記事書いてほしいけどね
まともに作ったオブジェクト指向プログラムでは
ユーザーの既知の言葉とクラスが対応している
クラスに関わる情報が集約されてる
よって仕様変更に対応しやすい
もっともメリットを享受してるのはここだな
>>651
意味がわかんない
どう仕様変更されるかもわからないのにそんな言葉出しちゃう時点で
テメーはクソだから発言しなくていいよ >>639
ああすまん、俺が言っているのは「スニペット」と言うのかもしれん。
（俺自身はあの機能は嫌いだから使ってないが、たぶん意味的にはこれ）
モジュールというよりは「お約束的コード」の塊を持っておき、
それをベースにその都度必要なら改変して使う、って奴。
それで使えると判明したら「お約束的コード」に新しい機能を取り込む。
JavaScriptはGUIの装飾が主だから、割とこんな感じのほうが上手く行く気がする。 >>649
関数型も完璧すぎるC言語に対抗するためのマーケティングと捉えてる？ >>654
名前なんかなんでもいいんだろ
言語と必要であれば設計手法も付けて売り出せれば本当になんでもいいんだと思うよ >>652
え、どう仕様変更されるかわからないからって仕様変更への対応しやすさはまったくの度外視でシステム作っちゃうのお前 >>655
構造化もマーケティング、手続きもマーケティング、さあどこまで遡ればマーケティングと無縁の世界、お前の桃源郷に辿り着くんでしょうかw >>645
> そもそもなぜここまでメリットの説明できないものを
> 効果がありそうに言うの？
メリットというか、人間のメンタルモデルに一番マッチしてるから
使いやすいってだけだよ
小学校入学前の子供であっても、車という種類（クラス）があって
白い車、黒い車、なんて属性（プロパティ）や
走る、止まる、曲がる、なんて処理（メソッド）が
車に紐付いてるって理解してるだろ？
なんかその道のプロは、オブジェクト指向の真のメリットは
継承やカプセル化や多態性とか言ってるけど、
それはオブジェクト指向の応用でできることであって、
オブジェクト指向はわかりやすいっていうのが
（メリットではなく）特徴 >>657
ちゃんと見定めればいいんじゃないかな？
役に立つものと立たないものを >>656
> え、どう仕様変更されるかわからないからって仕様変更への対応しやすさはまったくの度外視でシステム作っちゃうのお前
仕様変更に対応しやすくするために必要なのは、
コードを書かないこと。これはオブジェクト指向とは関係ない。
コード量が少なければ、仕様変更で書き換えるコードも少なくなる。
オブジェクト指向的にはモジュールを抽象化して、拡張性を持たせることだろうが
それは過剰な設計になって複雑さが増すだけで無駄になることが多い。
最初に作り込むのをやめて、最低限動くコードを書くのが良い。
これもオブジェクト指向とは関係ない話 >>652
仕様変更はユーザーの既知の言葉でなされる >>660
オブジェクト指向と関係ないか
じゃあどんな設計手法となら関係ある？手続き型も関数型も、再利用のしやすさ、仕様変更への対応のしやすさとはまったくの無関係？
どんな設計手法を取ろうと、仕様変更への対応はまったく同じだけのコストがかかる？ >>663
ユーザーの既知の言葉をクラス化したと言ったはずだが
お前には何もできないね >>667
> じゃあどんな設計手法となら関係ある
どんな設計手法とも関係ない。
例えば仕様変更に備えて既存のコードを読みやすくするために
わかりやすい変数名をつけることは、どの設計手法とは関係あるか？と
聞かれてお前、なんて答える？
そういうレベルの話
> どんな設計手法を取ろうと、仕様変更への対応はまったく同じだけのコストがかかる？
場合による。どれが最高とかはない。銀の弾丸はないのだよ君 >>668
ユーザーの既知の言葉には
動詞もあるはずだが、それもクラスにしたのか？ >>670
動詞はクラスのメソッドだろ
基本くらい勉強してこい ユーザーの既知の言葉をクラス化したというが
じゃあオブジェクト指向以外ではできないと思うのか？
理由はクラスが無いからできないと思ってる？
関数しか無いからユーザーの既知の言葉は関数になると思ってる？
違うな。C言語で作られたLinuxでも見ればわかるだろう。
他の手法ではモジュール（またはファイル）になるんだよ
まあバトるのはいいと思うけど、結局のところsmalltalkの話と似たような事になっていて、
・smalltalkが「遅延結合」で実現しようとしたことは、現在は他の手法で十二分に達成されており、
わざわざsmalltalkを用いる必要はない
・OOPのメリットは、現在では他の手法でも得られるため、OOPに頼る必然性はない。
だからメリットが見えないのなら使わなければいいだけ。
JavaScriptとかの状況だと、OOPで書いてもあまりメリットないのは事実だし。
ID:H6eyWyRr
完全なるガイジ
こういうのが現場に一匹でも紛れ込んでいたら
さぞ迷惑だろうな
>>672
それはオブジェクト指向言語でないとできないかという話か?
設計の話をしてんだよ
できるしgtkとかC言語でオブジェクト指向設計で組んだプログラムもある
オブジェクト単位で分けたならオブジェクト指向設計だし、そうでないなら他の設計だろ
モジュールはオブジェクトだったり機能分割だったりより包括的な言葉だ
お前の言っていることは間違えてる 結局さ、オブジェクト指向が生きるのは実装の話なんだよね。
言語より外に出ないでほしい。
オブジェクト指向言語で実装しやすいように設計したり
オブジェクト指向言語で実装した場合に後でメンテナンスが楽になるように設計するのが
オブジェクト指向設計じゃろ？
弁解せずに話し飛ばして逃げたか
ID:9ArzpmiBが恥を晒すだけのスレになってしまったな
「オブジェクト指向」って言葉自体、色んな意味で使われて混乱の元になっていたのは事実だわな。
最近の本では
「オブジェクト指向でなぜつくるのか」
がそのあたりの状況も含めてすっきり整理して分かりやすかった。
とりあえず
「オブジェクト指向プログラミング」
「オブジェクト指向設計」
「オブジェクト指向分析」
はきっちり分けて会話しないとますます混乱するな。
>>678
横レスだが君のレスのほうが普通におかしいよ
>まともに作ったオブジェクト指向プログラムでは
>ユーザーの既知の言葉とクラスが対応している
ユーザーの既知の言葉が先にあって
それをオブジェクト指向言語で実装しやすく・メンテしやすくするために
対応するクラスを作ったんだよね？
オブジェクト指向言語以外でも同じように実装しやすく・メンテしやすくするために
対応する関数やデータ型を作るだけじゃないの？
ユーザーの既知の言葉にどの程度対応付けできるかは
実装言語で扱える抽象化の方法にもよるけど
対応付けができるのはオブジェクト指向言語に特有のことではないよ >>679
一時期オブジェクト指向が目的になってる感があったよね
オブジェクト指向の適用範囲はプログラミング
そして設計のうち基本的な部分までだろう。
基本的な設計というのは具体的に言えばフレームワーク。
そのフレームワークというのは汎用的なもので
フレームワークの利用者に具体的な処理の部分だけを
書けばいいような形に設計するから、オブジェクト指向を意識する必要はなくなる。
またサーバー設計とかデータベース設計（オブジェクト指向データベースは除く）は
そもそもオブジェクト指向とは関係ない >>681
だから言語の話はしてないって
ガイジかよ >>651
その通り
DDDの発想だね
>>667
そんな訳ないよな
仕様変更しやすいのはOOのメリット >>681
＞対応付けができるのは
＞オブジェクト指向言語に特有のことではない
横レスに横レスだが……
OOPじゃないと「できない」わけじゃないが
OOPの方が「やりやすい」 ・「オブジェクト指向」には「抽象データ型をクラス等でやる（カプセル化・継承・多態性）」と「遅延結合を（メッセージを送ってとかを方便にして）徹底する」という２種類あり混ぜると危険
・「オブジェクト指向」には「〜プログラミング」（前二者の混在）の他に「〜分析」（前者の強い影響下）「〜設計」（後者の強い影響下）があり混ぜるとワケワカメ
って二段階において区別が付かない人間がいるともう議論はおろか会話すら成り立たなくなるといういい例だったな
ついでにこのスレには「遅延システムを言語仕様に持ち込むな」とかいう宗教のSmalltalkアンチ＆他人の話は読み飛ばすくせに自分の意見は押し付けるガイジがいて、話がエンドレスエイト
>>686
で？
それってどこの資料に書いてあるの？
テメーの意見だろ
死ねよ >>686
もうSmalltalkはゴミだから存在価値なしって結論出たろ
その時に反論できなかったくせにシレッと復活させんな >>687
オブジェクト指向プログラミング（のひとつ）が、抽象データ型（簡単に言うとユーザー定義のデータ型のこと）を
クラスなどで実装するアイデアだというのは、ビャーン・ストラウストラップが次で提唱（厳密には整理）しています
http://www.stroustrup.com/whatis.pdf
大枠としては、Simulaという言語が初めて作った「クラス」という言語機能を使って
整数型や浮動小数点少数型、文字列などといった通常は言語組み込みのデータ型と同様に
プログラマがデータ型を拡張できるようにしようというアイデアです。メリットは、いったん必要なデータ型を定義して
しまえば、そのデータ型やそれ同士の操作というかたちでプログラムの記述を抽象化（換言すると
シンプルに）できるというところにあります。
ストラウストラップのこのアイデア（正確には同時期に抽象データ型の発案者のリスコフ、Simulaの設計者の
ダールとニガードは当然として、Eiffelのバートランド・メイヤーらも同様の発想に到達しています）に準じれば
オブジェクト指向プログラミングのメリットのひとつは抽象データ型（データ抽象ともいう）を実践することと変わりませんから
（もちろんクラスを使うことで追加して継承による差分プログラミング、その結果の多態性を享受できます）、
メリットを検索したければまず"抽象データ型" "利点" などとしてググるとちゃんと出てきます。
まずここまでよろしいでしょうか？ >>689
え？どこに仕組みが書いてあるの？ｗ
そもそもそいつの理論自体クソなんじゃねコレ
メリットは、いったん必要なデータ型を定義して
しまえば、そのデータ型やそれ同士の操作というかたちでプログラムの記述を抽象化（換言すると
シンプルに）できるというところにあります。
はぁ？
これが本当にメリットになっているか
こんな曖昧な表現で誰も検証してねぇのがそもそもの間違いなんだよ 俺はオブジェクト指向言語でプログラミングを覚えたから、やっぱり設計するときもベースになるのはオブジェクト指向だな
なんかやたらとオブジェクト指向に噛みついてる人がいるけど、勝手に自分がいいと思う方法論でやればいいじゃんっていうw
>>690
とりあえず、まずは抽象データ型をクラスを使って実践するアイデアの「オブジェクト指向プログラミング」が
それなりに名の知れた先達のアイデアであり、>>686個人の意見ではないことを言外に了解いただけたことは良かったです
抽象データ型（ユーザー定義のデータ型）のメリットについてはデータ型自体のメリットが当たり前すぎて
それを具体的に意識できないとちょっとピンと来にくいかもしれません
たとえばもし浮動小数点数データ型（float）が言語の組み込みでなかったとしたら
小数同士の演算やそれを入力・表示するためにプログラムを書くときに
どんな不都合が生じるかを考えると逆にメリットをイメージしやすいと思います
そもそもデータ型というのは人間とコンピューターの両方に対しこれから扱おうとするデータが
何を意味するのかについての情報を共有するためのタグのような役割を果たします
浮動小数点数ならその型であるfloatを宣言することで
人間側は変数や関数を通じて浮動小数点数（指数表現付き小数）を扱えることを知ることができ
コンピューター側は変数に代入された、あるいは関数に渡されたビット列データが浮動小数点数として
つまり各ビットが符号、指数部、仮数部のどれを表しているかを知り、ビット列に対し相応しい扱いをすることができるわけです
もしこのデータ型という情報がビット列データや変数、関数に附随させることが出来なかったら
たとえば浮動小数点数同士の加算を行なう関数（仮にadd_float）を呼び出すにも
渡したビット列が果たして本当に浮動小数点数を表すのか
そもそもそのadd_float関数を使うことが適切なのかの判断がしにくくなり
プログラムの正しさを保証・把握しにくくなります
また応用として（こちらの方が即効性のあるメリットですが）変数や関数にもデータ型情報を付加することができれば
同一名の関数や演算子を渡すデータ型ごとに適切に振る舞わせることが可能になり
プログラムの記述をシンプルにすることに役立ちます
a, b が float で、add_float(a,b) の場合、add_int、add_fractionなどというようにデータ型ごとに
いちいち区別せずに単に add(a,b)で済ませることが出来たり
演算子を用いてもっとシンプルに a + b と記述することも可能になります >>692
そいつらもなんも説明してないよな
そいつらの説明する文書にメリットの具体的な仕組みがない
曖昧な表現で溢れてて
本当にメリットなのか誰にもわかなくなってしまった >>691
自分が初めてちゃんとやったプログラミングがVisualWorksでの開発だったから，
今後他の言語でプログラム組むようになったら大変だろうなと思う >>694
最初の本格的プログラミングが商用Smalltalkというのは羨ましいですね >>692
抽象データ型はOOPじゃなくても
現在に使われてる言語の大半で実現できることなのでそのメリットを長々と語っても意味がない
抽象データ型を”クラス”を使って実現することがOOPの特徴だと言うなら
“クラス”を使うことのメリットを説明しないと 設計の話で言語がー言いだす
ガイジは言語スレ行けよ
>>696
F#はマルチパラダイムだけど、いったんそれは置いとくとして、オブジェクト指向言語と非オブジェクト指向言語ではどっちがDDDやりやすいの？
オブジェクト指向言語しか知らないから教えてほしいな >>697
おっしゃるとおりです
ただ ID:H6eyWyRr への説明だったのであえてデータ型まで掘り下げました >>692
C++やJavaは抽象データ型を重視するOOP
ただJavaScriptはプロトタイプベースだから
オブジェクト指向の全部じゃないんだけど
静的型OOPの主流ではある
>>689
＞もし浮動小数点数データ型（float）が
＞言語の組み込みでなかったとしたら
この例は分かりやすかった
（抽象）型設計していくのが
C++やJavaのOOP >>696
別にPrologでDDDやってもいいんだよ
でもエリックエヴァンスのDDD本では
オブジェクト指向がメインになってるので
そこを無視して「関係ない」と言ってはいけない
やっぱりOOPの方がDDDをやりやすい このスレなら信頼できるレスを期待できると信じて質問しますです。
<< 質問 >>
デザインパターンは、大手企業の開発者以外では使われていないのだろうか？
特に地方では、全くと言っていいほど使われていないのだろうか？
>>703
よほどのことが無い限りOSS使って開発するのがほとんどだから意識しないうちに触ってるとかはよくある
Factoryパターンとかは頻繁につかうからデザインパターン勉強してないやつが設計しても出てくる
デザインパターンバリバリに意識して設計されてるのは見ない >>703
デザインパターンは良く使われてるデザイン、設計をパターン化したものだ
そのデザイン自体は無能でなければどこかしらで使っているだろうが、
パターンとして認識してるかは別だ フレームワークは、デザパタの集積だから、知らず知らず使ってる
フレームワーク製作者は、デザパタの勉強が欠かせないけど、
使う方は、知らなくても使える
>>703
デザパタ自体はあるあるに名前を付けただけだから知ってても知らなくても使ってる。
コードを配置するときに、結果的に○○パターンというのはあるが、逆に、
デザインパターンの中からどれにするか選ぶ、という奴はいないと信じたいが、どうなん？
構造を検討するのならクラス図を直接ホワイトボードに書けばいいだけで、（名前がまるで直感的でないので)
それをわざわざ会議で「ここは○○パターンで行きましょう！」ってのもないと信じたいが、これもどうなん？
というか俺はあの名前を真面目に覚える気にはならない。
あれって、継承/委譲/インタフェース等の組み合わせを全部展開して命名しただけであって、
それより継承/委譲/インタフェースをそれぞれどういう時に使うかをしっかり抑えたほうがいい気がしている。
例えるなら、物理でma=Fとsin/cosで終わるところを、
角度30度の斜面のときは…とか展開して覚えている感があるので気に入らない。
それ以前にクロージャ/関数ポインタ等、もっと使える部品も入ってないし。
というわけで、俺はデザパタはいらない子、と思っている。（使っているが、デザパタとは意識してない）
まあそれ以前に、最近は継承はいらない子、委譲だけでよし、ってのも流行ってるみたいだが。Goとか。 >>703
ストラテジーみたいに単純なものは
意識されなくても自然と使われてる
ビジターとか複雑なのはあまり使われてない
デザパタは意識して組まなくてもいいが
一通り学んだ方がいい
「これは○○パターンだな」って分かると
設計するときの土台になるから デザパタは神話
カタログ化こそに異議があるという意見もあるが
それこそ噴飯物
読者のレベルにもよるのはわかってるが
だいたいガバガバ理解ですれ違ってるのを見る
GoFのことかと思えば
GoFのことではなくて独自用語ぶっこんできたりもする
(>>704に見られる「Factoryパターン」であったり)
設計のための勉強に使うと言い切ったほうがまだマシに思える現状 >>711
>>704は「Factory」だけで意味通じる
GOFの23パターンだと
Factory MethodかAbstract Factoryだけど
そこまで融通が利かなかったから
そりゃ使いにくいだろうけど 断言していいと思うけど
・（いわゆる）ファクトリメソッド
・Factory Methodパターン
・Abstract Factoryパターン
この区別は>>704には無いし
後者二つについての理解は不十分だと思うｗ
デザパタデザパタ言ってみても
早速その辺で深い溝を感じる つまり、方言が多くて意味無いって事か？
俺も、>>704で通じると思う派だが、しかし確かに>>714の3つって何よ？とも思い、確認してみたが、
正直、区別する必要なくね？理解は以下でいいか？
・（いわゆる）ファクトリメソッド＝factory関数をどこかに用意して使う
・Factory Methodパターン＝factory関数をメソッドとして提供する
・Abstract Factoryパターン＝＝factory関数を別クラスに配置する
要するに直newせずにファクトリ呼べ、ってだけで全部同じだが。
俺はデザパタのこの手の無駄に組み合わせ数が爆発してる感が大嫌い。
OOPもそうだが、デザパタもここまできたらデザパタが目的になってる感がある。 デザパタはパターンに名前を付けたことに
意義があるというが眉唾
だからデザパタ用語を使わずに
デザパタの会話しろ
できるだろ！
>>716
一部にのみレス返す
・（いわゆる）ファクトリメソッド
インスタンスを返すメソッド
単にメソッドのこと
・Factory Methodパターン
インスタンス化をサブクラスに任せる
サブクラス化時にオーバーライドすることによって
親クラス内部で使ってるインスタンスの一部を置き換える
メソッド、親クラス、派生クラス、という関係性の中にあるパターン
・Abstract Factoryパターン
インスタンス群を作成するファクトリを抽象化する
ファクトリごと置き換えて、インスタンス群を丸ごと置き換えたい時使う
インスタンス群、ファクトリごと、が特徴
こーいうのはクラスライブラリを作って他人に提供しようとしたとき欲しくなるパターン インスタンスを返すメソッド
↓
インスタンスをnewして返すメソッド
のほうがいいかな
>>718
了解した。ｊこれでいいか？
・（いわゆる）ファクトリメソッド＝factory関数は非仮想関数
・Factory Methodパターン＝factory関数は仮想関数でオーバーライドされる
・Abstract Factoryパターン＝数クラスのfactory関数を纏めて抽象化
上2つは区別の必要なし、
下1つはメタ気味だからこれが適切な場合に「ファクトリ」と言えば上2つと混同することはなさそう。
って感じだなあ、俺は。 ちと補足すると、
・（いわゆる）ファクトリメソッド＝factory関数は非仮想関数
・Factory Methodパターン＝factory関数は仮想関数でオーバーライドされる
この2つが普通に「ファクトリ」と呼ばれるもので、俺は区別する必要が無いと思っている。
これらを使ったクラスが複数合った場合、それらを束ねるために
・Abstract Factoryパターン＝数クラスのfactory関数を纏めて抽象化
が使われると思うので、下から組む場合には、文脈的に混同されることはないはず。
上から組む場合は若干齟齬があるかも。
電気回路でも有名なやつには名前がついているものだからなぁ
組み合わせたり改良して使うのだろうから
〜の亜種、ということが多いのかもしれないが
>>699
どっちでやりやすいかは対象のドメインと
モデリングする人間のメンタルモデルによる
例えばDDD本に出てくる経路選択サービスなんかは
関数型の考えでモデリングするほうが自然に思える人が多いんでない？
実装言語としては型の表現力の高さや抽象化のしやすさは重要
F#のUnion TypeみたいのがあるとそれがないScalaでは面倒くささが全く違う ScalaがOOP寄りでF#がFP寄りだから
関数型ならF#の方が組みやすいが
Scalaが選ばれるときは
Javaとの親和性で選ばれる
Java（Web、Android）かWindowsか
DDDがOOPの方がやりやすいのは
ビジネスソフトには
状態を持ったモデルが多いから
状態を持たない経路探索なんかは
関数型（論理型）の方が得意だが
全体のサービスの一部なら
マイクロサービスでそこだけ関数型にしてもいい
まっ、デザパタは現場では死言ということがわかった。
簡単なごく当然な（デザパタと言うほどのことはないイテレーターとかコマンドとかファクトリメソッドとか・・・）
パターンは自然と使われているということね。
みなさん、サンクス。
Iterator パターンは、イテレータを提供するパターンだぞ
独自のデータ構造なんかを作った際に、それを辿れるようなイテレータを提供すること
既にあるイテレータを使ってるからといって
Iterator パターンを使ってるのとは違う
設計することと、設計されたものを使うことは違う
Iterator パターンを使って設計するのと、そのイテレータを使うことは違う
デザパタへの誤解は仕方ない
必要になるまでは分からないだろうから
設計の立場に立つまでは分からないだろう
ならばせめて
必要になるまではせめて語らないでほしい
イテレーターがプログラム機能として初めから無い言語が無くなってきたから
パターンを意識しなくてよくなったんだよな。
イテレータが言語にあるから
もうデザパタいらない
って考えは非常に短絡的だと思う
それだと言語に標準である
配列のイテレータとか以外で
独自のデータ構造を走査するとき
とたんにゴチャゴチャになる
>>733
> 設計の立場に立つまでは分からないだろう
> ならばせめて
> 必要になるまではせめて語らないでほしい
多分ここが間違っていて、というよりはポリシーの違いだが、
君の職場は「設計」と「コーダー」が完全に分離していて、「コーダー」にはデザパタの知識は必要ないのか？
俺が知っている限り、設計とコーダーの分離は失敗だったと聞いているが。
そもそも設計において必要なのは「外部インタフェースの固定」だ。これは
・（いわゆる）ファクトリメソッド(A)
・Factory Methodパターン(B)
・Abstract Factoryパターン(C)
として、(A)→(B)の場合には外部（使う側）のソースコードの改変は全く必要ないし、
(B)→（C)にアップグレードする場合も正しく隠蔽されていれば同様だ。
中身を見せていれば(B)→(C)時にダウンキャストが必要になるが、これはそもそも設計が悪いし、
それでもラップすれば、外部ソースは改変無しで保てる。
だから使う側からすると「ファクトリを必ず呼ぶ」ことを徹底すればそれでよく、
中身が(A)(B)(C)のどれでも関係なく、クラス担当者が最適なものを選べ、でしか無いと思うが。
最悪駄目駄目なら差し替えればいいだけだし。本来これが隠蔽のメリットだろうに。
>>737
いらんだろ。イテレータ自体、
・走査を begin(), next(), end() と抽象化すれば実装によって異なる走査が必要でも隠蔽できます
なんだし、言語側のイテレータもこれとインタフェース合わせてあるし。
同じ思想を2度学んでも意味が無い。
仮にデザパタがGoF以外の100人から提唱されているとして、それぞれ微妙に方言があり、
「○○のデザパタでは△△のことをこう呼びます」ってのを色々覚えても意味無いだろ。
デザパタのイテレータパターンと言語のイテレータ」は違います！ってのは俺にはこう見える。
どうでもいいことにこだわりすぎだ。 >>738
いやいるだろ
言語と設計（思想）が分離する
「外部インタフェースの固定」が有効なのはいいが
そういうのもイテレータとかデザパタから学んでいく お？アランケイは終わったのか？
どの辺りのレス番から再開すればいんだ
>>739
いる/いらないの言い合いは意味無いが、やっぱり俺は区別の必要は無いと思うぞ。
「言語のイテレータ」は「デザパタのイテレーターパターン」を言語側に取り入れた機能であり、
「言語のイテレータ」を正しく使える＝「デザパタのイテレーターパターン」を正しく使える、となるから、
別に学ぶ必要はない。
言語と設計(思想)の分離と言うのは、例えば依存性逆転の法則(DI)等であって、
これは言語とはまったく無関係だから、どの言語でも使えるし、また、使わなくとも実装可能だ。
とはいえこれも、例えばフレームワークは基本的にDI的であるので、
フレームワークを正しく使うようにすれば自然と身に付く。
(フレームワークに沿って記述することが必要であり、これはプチDI）
上達を登山に例えれば、デザパタは一つの登山道であるが、それ以外のルートもあるということ。
どれが効率がいいのかは知らんが、
少なくともデザパタを通らないと頂上にたどり着けない、って事はない。
本来デザパタの目的はこの「上達への最短ルートの開発」だったはずだが、
GoFからして冗長で暴走気味だと思うよ。 DIP=Dependency Inversion Principle
DI=Dependency Injection
>>742
イテレータの本質はコレクションとアルゴリズムの分離だから学ぶ意味はあるよ
イテレータのことをコレクションを走査するインタフェースとしか捉えないなら、いまや大抵の言語でサポートされてるから使い方だけ知ってればいいけど >>742
＞「言語のイテレータ」を正しく使える＝
＞「デザパタのイテレーターパターン」を正しく使える
ならないって
たんにループ文の代わりに使ってるだけだと
言語でサポートしてない部分になった途端に
分からない、出来ないゆとりになる
ただ使うだけでなく仕組みを知る必要があるが
仕組みを学ぶにはデザインパターンが有効 言語やフレームワークを使ってれば
パターンが自然と身につくってのは大いに疑問
OOP言語のJava使ってても
中身は手続き型で書いてるケースがよくある
自然と身につくのは道具の使い方だけで
パラダイムは意識的に学習しないと分からない
いいんだよ
そんなのどうせ金にならねぇから
工数が決まっちまった後の話に力を入れるな
>>746
本人に学ぶ気があれば、使っていれば身につくんだよ。
お前は日本語を学んで上達したのか？違うだろ。使って上達したんだよ。
もっと分かりやすい例で言うと、ギャグだな。
「鉄板」「お約束」「乗り突っ込み」等のデザパタはあるが、
これらをデザパタとして学ばないと「乗り突っ込み」出来ないのか？
違うだろ。使ってるのを見て学んだんだよ。
（トンキンでは学ぶのかもしれないが、関西人のは地だぞあれは。
「ふーん、で、オチは？」という環境にいるから自然と身につくんだよ） 用意されたイテレータを使うだけの人と
イテレータやジェネレータを自分で作って使える人とでは
力にかなりの差があるのでパターンとして学ぶことの意義はあると思うけどな
>>748
オブジェクト指向設計は学ばなくても使ってれば身に付くという思想なら、そもそもこのスレに何しに来てんの？お喋り？自分の考えを聞いてほしくて？ >>748
＞日本語を学んで上達
日本語は母語だから自然と上達するが
英語だと学ばないとカタコトのまま
数学だとさらに意識的な学習が必要
プログラミング言語は英語や数学に近い
意識的に学習しないと上達しない >>749
まさに要点はそこだね
使うだけの人になるよな
使うだけなら慣れれば十分だが
作る人になるには学ぶ必要がある >>750
むしろお前は何しに来てんだ？
デザパタ学べば上達するなら、本なりサイトでも読めばいいではないか。 >>751
× > 英語だと学ばないとカタコトのまま
○ 英語は使わないとカタコトのまま
これはほぼ通説だぞ。むしろ俺の説を補強してどうする？
学ぶ＝イメトレであって、それは上達を早める方法ではあるが、
学ぶだけでは上達しないんだよ。使わないといけない。
もちろん使ってさえいれば上達するか？と言えばそうじゃない。
日本人内でも文章の上手下手があるように、いろいろ意識して使って無いと駄目だ。
いわゆる職人気質だよ。今よりも上を常に求めているか？ということ。 デザパタは名前が付いてることが大事なんだよ
その一言で共通認識ができる
こんな基礎もわからん馬鹿がデザパタはいらないキリッ
とかいいながらペチプァ〜でウンコードモリモリ大将軍してるんだろ？
PHPと共に死んで欲しいね
>>754
＞英語は使わないとカタコトのまま
違う、もちろん実際に使わないで
座学だけではダメだが
発音は意識して学ばないと
いくら使っててもカタコトのままというのが定説 おい聞いてるのかペチプァ
単価最底辺の土方ども
生きてるだけ無駄なんだよ屑が
今すぐ死ねよ！
>>756
英語は使わないとカタコトのまま
ということは否定するんですよね？ >>756
もう完全に脱線しているが、さらに続けると、
> 発音は意識して学ばないと
> いくら使っててもカタコトのままというのが定説
これは正確ではない。
一般日本人について、確かに君の上記意見は当てはまる。
しかしこれはエラーをフィードバックする「耳が無い」からであって、
逆に言えば「耳がある」人は意識して学ぶ必要はない。例えばネイティブの幼児とかがそうだ。
脳科学的に、確か聴覚は幼児期に発達して、そのまま終わりだったはず。
それで俺たちはLとRが聞き分けられない耳になってしまって、結果、LとRの発音が出来なくなる。
これは、先天的聴覚障害者がアーウーとしか言えず、正しく発音ができない（滑舌が著しく悪い）ことからもわかる。
聴覚障害は口蓋の障害ではないのに正しく発音できないのは、
自分の発音が聞こえず、正しく発音できていないことを認識して修正できないから。
（分かりやすく言えば、噛んだことが分からないから）
英語についていえば、LとRの違いがわかる耳があれば、明らかに違う（らしい）のであっさり上達する。
(むしろ、何でこれが聞き分けられないの？と不思議らしい）
俺らみたいに、「耳がない」人が「正しい発音」をする為には、
俺らも聴覚障害者と同様に、正しい発音をする為の口や舌の動きを意識しないと上達しない、というだけ。
だからまあ、エラーをフィードバックできれば自己学習で上達はする、ということにはなる。
つまり自分で書いた糞コードが糞だと認識できれば、上達する、とも言える。 イテレータをパターンとして学ぶ価値があるかどうかから
パターンそのものの価値があるかどうかに話変わってるよね
んでもって、その英語の話はもうパターン関係なくなってる
もしLとRを聞き分けられるようになる<LRパターン>があるとしたら
パターンを学んだやつのほうが学習効率が高く上達が早いわけだ
そのパターンを知らないやつ独学でいくら努力しても
いつまでたってもLとRが聞き分けられない可能性もある
無理やりパターンにつなげるとだけど。
>>760
そうじゃない。
自分のコードが糞だと認識する為には、逆に、良いコードならこんな感じになるはず、と想像できる必要がある。
当然、あらかじめ「良いコード」を知っておく必要がある。
だからコードリーディングも同様に上達の手法ではある。これもよく言われてるだろ。
もちろんデザパタ学習も上達の方法だし、やればいい。
ただ、頻出パターンならコードリーディングでも当然遭遇するし、>>704はそういうことなんだよ。
だから>>704が理解出来ない＝OSSを使ってない、コードリーディングしてない、ということ。
どっちが上達が早いのかは知らん。両方やるのがベストなのだろうが。
デザパタ学習が唯一の道ではない。 >>758
英語は使わないとカタコトのまま
英語は学ばないとカタコトのまま
上の両方を肯定する
「使ってれば学ばなくても自然と覚える」
という片方だけを否定することを否定する >>759
クリティカルエイジ以前の幼児が
英語を自然と身につけるのは知ってる
プログラムの話に戻ると
幼児の頃からプログラミングしていた
奴なら自然と身につくかもしれないが
一般人については意識して学ぶべき 内部がどんな実装か知ってる必要ないね
使い捨ての土方なら
>>764
俺が否定しているのは、君らが学びの方法が唯一デザパタ学習だと信じていることだ。
これは明らかに間違いで、>>762の通り。コードリーディングでもデザパタは身につく。
OOP信者と同様、デザパタ信者もまた、視野狭窄だ。 >>766
もちろん唯一の道じゃないけど
コードリーディングだけで
デザインパターンを身につけるのは効率が悪い
あらかじめパターンを知ってて
「これは○○パターンだな」っていう方が
圧倒的に上達が早い 時間の無駄になる相手に
レスを返しては行けない
分かる人だけ守って欲しい
自分の時間を守って欲しい
>>762
何がそうじゃないのかわからんのだがww
今度は「デザパタ学習が唯一の道ではない」に主張を変えたのか
その主張なら誰も否定しないだろね
最初からデザパタ学習が唯一の道なんて言ってる人いないから >>767
君がそう思うのならそれでいい。
ただ事実として言えるのは、「デザパタ」は頻出パターンであり、当然他でも言及されてるんだよ。
例えばファクトリー、以下はJavaScriptの例だが、クロージャの部分でさらっと出てくる。
ただしJavaScriptの場合はクロージャを生成する為にファクトリーを積極的に使う理由があり、GoFの範囲を超えている。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Closures
もちろんイテレータはプログラミング言語C++の中でハゲが力説しているし、
ストラテジーについては継承まんまだろ。OOP言語なら確実に説明されてる。
各言語機能も、作った側は「こう使って欲しい」ってのがあるから、それぞれ力説されてる。
(K&Rはあまりにも淡々としすぎているが)
だから頻出パターンならいい教科書で各言語機能を学べば自然と目にしてる。
そして文法は学ぶ必要があるから、これらは読むしかない。
その後にデザパタを見ても、頻出パターンは確実に重複するんだよ。
そしてどうでもいいパターンを学ぶ意味はないし。
デザパタは結局頻出パターンだから、学ぶ気があればどの方法でも自然と身につく。
コードリーディングでも、教科書を読んでも。
「デザパタ自体を学習せねば！色々初めて見るし！」と思ったのなら、それは君らが普段からあれこれ見落としているだけ。
デザパタなんてそこかしこに転がっている。いちいち言及されてないけど。
だから本来はわざわざ別に学習しなければならない物でもないのさ。 >>772
> 文法は学ぶ必要があるから、これらは読むしかない。
文法はコード書いたり読んだりしてれば自然と身につくよ
日本語の文法を学ばない人に日本語は使えないかというとそうじゃないだろ？
教科書を読むのが文法を学ぶ唯一の方法だと思ったら大間違いだよ
はい、これがお前的反論パターンw >>772
上から目線で捉えていることは
無条件で正しいとでも思ってるのかな
「君がそう思うのならそれでいい」が
GOFの23パタをすべて習得してるのは当然の前提として
GOF以外のデザパタもあるし
GOFの23パタからアレンジしたものもある
日本ではマイナーなものもある
Null Objectなんかは最近浸透してきたが
Type ObjectとかExtension Objectとか他にも色々ある
またイテレータと同様に
ビジターにも内部／外部があるとか
関数型やジェネリックの書き方があるとか
発展的なトピックもある
だからデザパタ単体で学習した方が整理される
言語を学んでいるときはパターンより文法に
コードリーディングしてるときは
実装のテクニックに目が行きがちだしね みなさん、ほんとうにデザパタを使っているんですか？
簡単な分かり易いものは使っているんでしょうが、これぞっていうパターンを
使っている人このスレに居ますか？
大手企業のパッケージ開発やフレームワーク開発に従事している秀才プログラマー
が使っているのは度々見ましたが、中階層、低階層の現場では見たことありません。
ちなみに我輩はしがない流れ者の派遣プログラマー（プログラム設計もやってます）です。
アルカンシェルパターンはよく使ってるね
最強のパフォーマンスを目指す選ばれた者だけが行使することを許された神ーGODーの力
>>771
やっぱりそうですよね
普通にデザインパターンって言いますよね
うっかりデザパタとか言わないように気を付けます >>776
GUIで使われるようなものはwebだと使う機会なかったりするし
無理に使うようなものじゃない
GoFのデザインパターンは共通認識としての意味合いが強いから
勉強しとかないと話にならない >>782
毎回長々と説明してるのか
生産性の低い環境でやってるんだな デザインパターンなんてゆとりには通じないよ
ゆとりはif文とforループしか理解できない
彼らとのコミュニケーションは全て懇切丁寧に一から説明しないといけない
そして彼らはそれが当たり前だと思っている
甘やかされて育った人間があれほど厄介な生き物になるとは思わなかった
違う生き物と話しているようで辛い
デザパタの分かる年寄りより
分からない若いのを雇うのがIT土建屋
>>786
若いから安く買えて
工数かかるから高く売れるんだな
サビ残人身売買 使い潰してもいくらでも捕獲できるし便利っちゃ便利だわな
>>775
なんだゆとりか。
つか、君は結局何が言いたいんだ？
> 圧倒的に上達が早い (>>767)
については、俺は既に
> どっちが上達が早いのかは知らん。 (>>762)
と言っているんだから、平行線だし、ここの議論では結論は出ない。
各自が各々の考えを主張できるだけだ。
君がそう思うのなら、君はそうすればいいだけ。俺はそうは思わないから、俺はそうしない。
それ以上でも以下でもないだろ。勝手に切れるゆとりは多いが。
> コードリーディングしてるときは
> 実装のテクニックに目が行きがちだしね
それは君がそうだってだけ。自覚できているのなら、そうならないように気をつけながら読めばいいだけ。
>>785
ゆとりが糞なことについては同意。
てかまじで、>>775とか何が言いたいのか分からん。
同意してくれなきゃヤダってゴネてるのか？としか。
よく見かけるけどね、このパターン。 >>776
何でもそうだが、デザパタもやりすぎたら手段が目的化するんだよ。>>775とか。
言われてみれば使ってるっていう、>>779位がちょうどいい頃合だと思うよ。
何が問題って、GoF自体が古いからではあるが、今ならもっと単純にできるものが大量に有って、
というかGoFの時点で既にアクロバティック気味で、何がやりたいんだこいつらは？って感じなんだよ。
名前も厨二過ぎてイミフだし。
結局はOOPの文法の全ての組み合わせから、あるあるに厨二な名前をつけただけ、っていう。
例えばコンテナ等でお約束的に使われる「型消去」だが、GoFにはないだろ。
（見落としかもしれんが、それなら「型消去」と直感的な名称の方が断然良いからGoFが使われないだけ）
だからWikiにも書いてある通り、俺は
> デザインパターンをむやみに適用するのは不適切であり、不適切な使用はコードの複雑さを無意味に高めてしまうと注意している。
> 一部のデザインパターンは、プログラミング言語（例: Java, C++）の機能の欠損の印であると主張されることがある。
の側面もかなりあると思うよ。 >>776(続き）
ただ、使ってる/使ってないと言えば、それは確実に使っている。
既に言ったがストラテジーは継承そのものだから、OOPならほぼ間違いなく使うし、
オブザーバーってのはフレームワークのイベントモデルがこれ(.NETとHTMLはそう）なので、
例えばC#やJavaScriptにおいてこれを使ってないというのはありえない。（自覚しているかどうかは別）
なおJavaScriptはこれを言語自体にも取り込もうとしたが、いいところまで行って頓挫した。
https://www.html5rocks.com/ja/tutorials/es7/observe/
本当に頻出なら言語で直接サポートした方が便利だから、そうなって行くものなんだよ。
それがイテレータであってね。
だから、この類の「言語新機能」を追いかけていても、頻出パターンについては自然と学習することになる。
GoFは1995だし、それからソフトウェア工学も進歩しなかったわけではない。（Javaは10年間進歩しなかったが）
新しい言語は分かりきっている問題に対しては対策をしてくる。
そしてGoは「継承はいらない」という彼らなりの結論を出してる。
GoFなんて古典を妄信するより、Goが何故こういう結論を出したのか考えるほうがいいと思うぞ。
> ちなみに我輩はしがない流れ者の派遣プログラマー（プログラム設計もやってます）です。
君がここら辺の話について来れないのなら、とりあえずまず読んでみろ、ではある。
それでどう思うかは君の自由だ。
多分結局は適性なんだよ。パターンから選ぶほうが楽なら積極的に使えばいい。
俺にはデザパタは粒度が大きすぎる。自分で継承/匿名関数等を使って組み上げるほうが楽だ。（というより直感的）
ただし結果的には同じようなことになっているとも思うが。 ストラテジーが継承そのものってどういう意味？
HTMLのイベントモデルがオブザーバーってどういうこと？
>>794
> そしてGoは「継承はいらない」という彼らなりの結論を出してる。
> GoFなんて古典を妄信するより、Goが何故こういう結論を出したのか考えるほうがいいと思うぞ。
いまでもGoFを学ぶ意味があると言うと、盲信してることにされちゃうんだね
ということは、Goの出した結論をGoを指示する人は盲信してるの？
まぁGoが正しいわけじゃないし、SwiftやScalaが出した答えも考える価値があるね >>796
> まぁGoが正しいわけじゃないし、SwiftやScalaが出した答えも考える価値があるね
その通りだ。俺は自分で考えろと言っているだけだ。
GoFが古いのは事実だ。
その間にソフトウェア工学が進歩していると仮定するなら、当然問題は解決されてくる。
実際そうなっているわけでね。
メジャー言語では、Javaは例外的に全く進歩してないが、
他言語(C++/C#/JavaScript)はなんだかんだで色々試行しているよ。
俺自身、継承はちょっと結合が強すぎるとは感じる。
ただ全部委譲の方がいいか？と言われれば、どうかな？とも思うが。
とはいえ、「全部委譲でよし、継承イラネ」ってのは2chでも散見されるだろ。
で、君はSwiftやScalaを知っているんだろ？それはどうなっているんだ？ >>794
> そしてGoは「継承はいらない」という彼らなりの結論を出してる。
> GoFなんて古典を妄信するより、Goが何故こういう結論を出したのか考えるほうがいいと思うぞ。
継承という文法がなくても
継承を別の方法で実装できるからでしょ？
「継承はいらない」ではなく「継承を直接行うための文法はいらない」が正しい
そしてGoでも継承自体はやる。 ほんと、ストラテジーが継承そのものってどういうことよ？？
最近はOOでも関数を渡せる言語が増えてきたから
ストラテジーの実装は継承使わないほうが多いと思うぞ
古臭いGoFをそのまま学ぶ必要はないだろうが
単に各パターンを知る・使えるようになることよりも
パターンを通してOOの設計原則を学ぶことが重要
アラン・ケイやGoFのデザパタに触れるとスレが荒れるということは分かった
名前がついてるものの中でも
クイックソートやB+Tree、線形補完でスレが荒れるなど聞いたことないし
やはり何か根本的に微妙なんだろうな
良し悪しを証明出来ないからだろう
アルゴリズムのオーダーとかなら数学で証明できるから議論の余地がない
数学的に曖昧なものほどバカでも議論に入る余地があるから調子乗って参加しちゃう
こういう議論でしか話せないんだよバカは
クイックソートでも再帰を使えないアホウが発狂するぞ
どんなネタでも発狂するキチガイは存在する
再帰なんてわかんなかったら繰り返しになるまでコード書いて見ればいい
繰り返し部分を関数にすれば作成完了だ
しかし、スタックオーバーフローで死ぬ
ここまでがワンセンテンスだ
例えばクイックソートなんか、明らかに名前を付けるに値する人類の英知でしょ
ちょっと自分では思いつかないかもしれないし
誰でも真っ先に思いつきそうなセレクションソートなんかと比べれば効果は劇的だし
動きも複雑っちゃ複雑なところもあるから、人に説明するのも大変でしょ
だからクイックソートは絶対名前を付けて共有したほうが良い
それと比べてどーなんかなーという
じゃあバブルソートとかリニアサーチは名前つけるほど大層なもんでもないから、先頭からひとつずつ見ていくやつ、みたいな感じで表現すればいっか
基本的には名前が知られて有名になっていく過程というものが有るんじゃないかと
その自然的プロセスをすっ飛ばして
良くありそうなアルアルに名前を付けます、俺の独断と偏見でな！
ってのがね
パターンに名前を付けることの価値がわからない人には
オブジェクト指向は向いてないんじゃね？
a, b, x, y, t1, t2みたいな命名しとけばいいと思うわ
>>802
プログラミングは暗記だ！と思っている文系の馬鹿がすがるからだろ。
彼らにとっては、自分達が｢上級者｣だと証明するものは記憶したデザインパターンの個数しか無く、
そんなもの無意味だ、と言われて発狂してるだけ。
上記の遠り、俺は何度も｢何故意味がないか｣を具体的に説明しているが、
彼らは感情的にしか反論できてない。これがまた彼らの馬鹿っぷりを証明している。
本来は経験の差を知識で埋め、初心者→熟練者にジャンプアップさせることが目的だった。
これは表面的には達成できるんだけど、やっぱり中身は初心者のままで、考え方がずれてるんだよ。
しかしそのメッキしただけのまがい物が上級者ぶって語るからおかしなことになる。
ただまあ、デザパタ議論をしているだけでもマシな方だ。
JavaScriptはネット見てるだけでマジでカオスで、ろくなコードはないし、でたらめを主張する奴も普通にいる。
現場は壮絶な状態だというのは想像に難くない。
あいつら、jQueryが使えたら達人扱いっぽいのだが、jQueryってCでいうprintfだからな。 >>808
名前を付けるのは基本的にはいいことなんだが、直感的じゃ無いと駄目なんだ。
これはmemeと同じで、みんなが妥当だと思わないと広まらないんだよ。
(これが君の言う「自然的プロセス」で、つまり自然淘汰されただけとも言える)
ストラテジーパターン、アダプターパターン、デコレーターパターン、ビジターパターンとか言われても、は？だろ。
バブルソート、クイックソート、リニアサーチ、バイナリサーチってのはそのものずばりだ。
>>807みたいな馬鹿にはそれすら分からないらしいが。
ところで>>807、お前は早くSwiftとScalaの説明しろ。 愚にもつかない長文を一生懸命連投するメンタリティが悲しい
愚にもつかない長文を一生懸命連投するメンタリティが悲しい
>>814>>815
書き込めたかどうか確認することすらできない人はそう言った >>813
クイックソートのどこがそのものなんだ？
単に「速いソート」って名乗ってるだけだろ
クイックソートよりも速いアルゴリズムを採用して
「超速いソート」と名付けたらそのものズバリだと思うか？
超速いソートという名前からどんなアルゴリズムを想像するよ？ >>817
ゆとり死ね
>>808
そういえば、実際に頻出だと名前が無いと困るので、別の名前が付いてる。
多態(ポリモーフィズム)＝ストラテジーパターン
ラッパ＝アダプターパターン(だと思う)
グローバル≒シングルトンパターン
包含/委譲＝コンポジットパターン
○○プール(スレッドプール等)＝フライウエイトパターン
構造体渡し＝コマンドパターン(ただしこれはCでは日常的過ぎてパターンだとも認識されてない)
元々有った物については、イテレータ等同じ名前でないものはデザパタ側の名前がアホ過ぎてスルーされてる。
例外的にsingletonは使われているが、これはglobal=悪というJava教ではなぜかsingleton=善とされているから。
(適用範囲はほぼ同じ。実は駄目っぷりもほぼ同じなのだがスルーされてる。
坊主がウサギを鳥だと言い張って食ったようなもの。)
ぱっと見た感じはこんなもんか？
俺はデザパタの名前は普段使って無いから間違ってるかもしれんが。 3行しか読めない馬鹿はマジでプログラマ辞めて自殺してくれ。
絶対に上達しないし、糞コード量産されるだけで迷惑だ。
つか、普段から仕様書なり解説記事なり読んでないの丸分かりだし。
>>824
伝わらないことを他人のせいにしてんじゃないよ
長くても読みやすい文章はいくらでもあるけどおまえはそうじゃない ゴミみたいな長文を書くウジ虫はコードも長い
平気な顔して10行20行の関数を書く
パターンとかなんでも名前ついてるじゃん
reduxとかpromiseとかgit flowとか
頻出だったら名前が必要でそうでなければ不要とか、主張の意図がわからんわw
名前があったら困るのかw
やはりゆとりは殺すべき。
根本的に勘違いしている。長文のほうが簡単なんだが。
>>830
> reduxとかpromiseとかgit flowとか 長文自体が問題でもあるけどこの場合
「愚にも付かない」長文を「一生懸命連投」しちゃってるところが涙を誘う
小学生の九九暗唱連呼なら、しつこくても間違ってても、まだ微笑ましい
既に言ったが俺は>>775の意図が理解出来ない
文才溢れるゆとりによる適切な解説を求む 俺はデザパタ知らないし話についていけてないけど
それでも長文書くやつはバカだろ
長文書いただけで、そいつが言ってることが
間違いだってわかる＝デザパタはクソ
ディベートのテクニックの一つだよ
相手が長文で攻めてきたら
長文はキモいの一言で
で相手の理論を論破できる
要点を絞れない
簡潔に説明できない
長文はアホの得意技
>だからデザパタ単体で学習した方が整理される言語を学んでいるときは
>パターンより文法にコードリーディングしてるときは
>実装のテクニックに目が行きがちだしね
なるほど、確かに何言ってるか分からんな
>>842
それもディベートでよく使う。
基本相手の発言は遮って自分の発言で上書きするのが
テレビでもよく使われるテクニックだが、
相手がなにか言ってしまったら、
要点を絞ってもう一回発言してくださいと
逆に相手に同じことを言わせるというテクニックもある。
このテクニックをうまく使うと、要点を絞らせるから
相手がいいたいことを減らすことができる。 長文書く奴は脳が女の脳してるからプログラムには向いてないんだよな。
曖昧で冗長で不正確で理解しにくいの４拍子そろってるな。
>>849
なら君なりの等式を書いて議論を進めて、どうぞ。
というかマジでお前ら、それで何とかなってるのか？
リアルで詭弁論法使う奴がいたら俺はそれ以降相手にしないんだが。 お前ら、この状況をよく観察しろよ
そして、スルーの使い時を学ぶんだ
>>854
では君が思う「長くても読みやすい文章」の例示よろ >>855
長くする意味がわからんｗ
ちょうどいい長さでレスしろよｗ >>794
＞ストラテジーは継承そのもの
ストラテジーは委譲だよ
継承そのものと言えるのは
テンプレートメソッドの方
デザパタの基本じゃないか
＞ここら辺の話について来れないのなら
上から目線で言ってて
間違ってりゃ世話ないな！ >>859
テンプレートメソッドパターンは本来は依存関係なしのコード共通化＝C++のテンプレート、C#のジェネリック
のような気がするが、まあそれならそれでよし。
・多態(継承/委譲)＝テンプレートメソッドパターン、ストラテジーパターン、コンポジットパターン
・ファクトリーの多態＝アブストラクトファクトリーパターン
で、これらは現在、ほぼ全ての場合に左側の用語が使われ、デザパタ用語はリストラ済みの認識でいいか？ >>860
＞テンプレートメソッドパターン
＞C++のテンプレート、C#のジェネリック
デザインパターンのテンプレートと
ジェネリックのテンプレートは関係ない
ジェネリックは型を汎用的に扱う仕組み
デザパタの方は処理を継承で共通化する仕組み
＞ほぼ全ての場合に左側の用語が使われ
その確信の根拠はどこから来てるの？
多態はデザパタとは別の概念で
イコールで使われるようなものじゃないだろ
コンポジットパターンのことを指して
多態って言われても意味分からん >>861
Smalltalkerは
どうしてもOO原理主義的になりがちだから
どんな分野でも原理主義は衝突と摩擦を招く
関数型原理主義とかでも荒れるだろ？ >>861
SmalltalkはOSと言語が合体している独自の世界だから
Smalltalk実行環境（＝OS＝開発環境）のみがコンピュータ上で動いており
Smalltalk実行環境は電源を消すまで動作しているという前提の話をするから
言語だけの話にならない。
例えば開発した新しいプログラムをOS上で起動するというのは
Smalltalkの世界では、Smalltalk実行環境上で新しいクラスを作って呼び出すということで
プログラムを一旦終了してバグを修正して再起動するということは
Smalltalkの世界では、ではクラスを動的に変更するということになる。
このように一般的なOSでは、プログラムの作成や修正という当たり前にできることが
Smalltakでは「オブジェクトは遅延結合が必要で動的に変更できなければならない」という
根拠になってしまっているから、お前らの世界では遅延結合や動的が必須なのだろうけど、
そのマイナーな世界を押し付けるな。そんなものはなくてもできる。という感じで荒れる >>861
良いSmalltalkerと悪いSmalltalkerがいて
このスレには後者が住んでるから
ケント・ベック、ウォード・カニンガム、エリック・エヴァンス、ラルフ・ジョンソンらは
Smalltalkを垣根を越えてこの世界に影響を与えた人達
日本だと羽生田さんとか
悪いSmalltalkerはSmalltalkの世界観に閉じこもって現実を見ない
技術力が無いから他に生かせないというのもある >>862
C++のテンプレートなら、
継承関係ないクラスの同じ名前のメソッドを呼び出し側は共通に使えるんだよ。
静的ダックタイピングと言えば分かるか？
Javaはこれが出来ないから継承ありきになるだけであって。
> ＞ほぼ全ての場合に左側の用語が使われ
> その確信の根拠はどこから来てるの？
だって見たことないし。
ネットでも継承/委譲議論は見かけるが、わざわざデザパタ用語使ってる奴はいないだろ。
余計に分かりにくくなるだけだし。
元々>>703の質問がこれだが、君はリアルで使っているのか？
> 多態はデザパタとは別の概念で
> イコールで使われるようなものじゃないだろ
多態自体が本来はパターン(多態パターン)で、これはオブザーバー/ファクトリー/フライウエイト等と並べられるだろ。
継承/委譲は多態の実装方法であって、それらの組み合わせで○○パターンとか無駄に水増しするからデザパタはダメなんだよ。 まず自分の考えが正しいというのが第一にあって、そこに無理矢理デザパタの思想を当てはめようとするから、
なに言ってんだこいつ、みたいになる
誰だよお前、お前が考えてることなんて知らねえよ、お前の考え基準で説明されてもわかんねえよハゲっていう
>>866
＞余計に分かりにくくなるだけだし
オレオレ用語の方が分かりにくいと思うが
長文の応酬だるいから
>>820
に戻ってひとつだけ言うと
＞構造体渡し＝コマンドパターン
こんなのこのスレで初めて見たぞ
同じようなこと言ってる
人でも本でもサイトでもいいけどいるの？
なんか用語や概念が自分勝手すぎて
議論が噛み合わない
>>869
＞お前の考え基準で説明されてもわかんねえよ
だよな
「お前の中ではそうなんだろうな」としか思えないよな >>872
それは既に書いただろ。日常的過ぎて言及されないが、あえて言うならそうだと。
Cでは(というか他言語も一般的にそうだが)引数が増え過ぎたら構造体にして見た目単純化するんだよ。
こんなのパターン(ｷﾘｯされても困るわ。
それに文句言うのなら、ネット上でデザパタ用語使って制御構造議論してる奴探してこいよ。
俺は見たことないぞマジで。
ただまあ、平行線なら平行線でいいよ。
君は君の意思でデザパタを学び続ければいいだけだし、俺が同意する必要すらない。 なんてことはない >>820は
右がパターン（やりたいこと）で
左がその実装方法（の一つ）ってだけ 例えば、
if = 条件分岐制御
for = ループ処理
みたいなことだよ。
>>874
>Cでは(というか他言語も一般的にそうだが)引数が増え過ぎたら構造体にして見た目単純化するんだよ。
それコマンドパターンと全く何の関係もないから
みんなツッコんでんだろ もちろん>>820で書いている左の実装方法は劣化版。
右にで書いてあるパターンは、もっと多くの要求に対して
スマートな解決策を示しているが、
>>820左の実装方法はパターンで要求しているものの
一部部分しか満たせていない。
もちろん実際にはそれほどの要求は求められていないことが多く
左の実装方法で実現できるある程度のことで十分であることも多い
だけど、所詮左に書いてあるのはパターンの
簡易な実装でしか無い 例えば
グローバル＝シングルトン
というのは
まず>>820の盛大な勘違いを訂正しておくが、世の中で悪と言われているのは
グローバル「変数」であってグローバル「関数」やグローバル「オブジェクト」ではないということ
グローバル変数のどこがダメかというと、どこからでも
その変数に好きな値を入れてしまえるということ
（変数の型にあったものしか入れられないという制約は有るものの）
グローバル関数はそもそも値を入れるものではないし、
グローバルオブジェクトはpublic変数なんてものは当然禁止で
関数経由で代入するので自由な値は入れられない。
そういった制限ができない時点でグローバル変数では
シングルトンの代替にはならないが、
小規模プログラムで、気をつけて使えばシングルトンの
代わりにならないことはないという点で
かろうじてグローバルでも実装可能 > 構造体渡し＝コマンドパターン(ただしこれはCでは日常的過ぎてパターンだとも認識されてない)
「構造体渡し」というのが（実装レベルの）パターンの名前だよ
構造体があるのは一部の言語で、通常はクラスのインスタンス（＝オブジェクト）渡しということになる。
要するに引き数をオブジェクトにするということ。
つまり引き数が多いから、コマンドパターンを使いましょう。
＝引き数をオブジェクトにして実装するということですね！
ということで、パターンがやりたいことで
実装方法がオブジェクトだったり構造体だったりするということ
構造体渡しというのはあくまでオブジェクトがないC言語での実装方法であって
反対に構造体がない言語ではオブジェクト渡しとなる。
その２つを抽象化したものがコマンドパターン。
例えば言語が決定してない時点で構造体渡しを使いましょうなんて言えないじゃないか
構造街があるかないかわからんのだから
だから設計時点での言い方として「構造体渡しという実装方法の名前」ではなく
「コマンドパターンという名前」を用いる
> ラッパ＝アダプターパターン(だと思う)
これは>>820の勘違いがよく分かる例だな
アダプタパターンというのは、
電源アダプタと同じく、どんな電気機器でも
アダプタを使えばコンセントにさせるということで、
互換性がないものを、ある共通のインターフェースに
適合できるように変換するもののことを指す。
だからラッパという手段を用いることで
アダプタパターンを実装できるが、
だがラッパというのは別にある共通のインターフェースに
適合させる必要はない
あるライブラリがC言語用のAPIしか備えておらず
オブジェクト指向的には使いづらいから、APIのラッパを
作ってオブジェクト指向風に使えるようにするなんてのもある。
これはラッパは必ずしもアダプタパターンが要求している、
ある共通のインターフェースに適合させるなんてことはしていないが、
ラッパを使ってもできる場合があるということでやっぱり実装方法の話題なのさ >>881
＞つまり引き数が多いから、コマンドパターンを使いましょう
眠いから要点だけ言うが
引数を圧縮したいだけなら配列渡しでもいい場合があるよな
逆にコマンドパターンは引数がひとつでも使う場合もある
コマンドパターンはもっと汎用的な抽象化技法で
要求をオブジェクトにすることで
アンドゥの挙動が実現できたりする >>881
その説明コマンドパターンと何の関係ないよ
完全に勘違いしてるのでググって はい。ググって正しいことを証明します。
http://www.techscore.com/tech/DesignPattern/Command.html/
第22章ではCommandパターンを学びます。あるオブジェクトに対して要求を送るということは、
そのオブジェクトのメソッドを呼び出すことと同じです。
そして、メソッドにどのような引数を渡すか、ということによって要求の内容は表現されます。
さまざまな要求を送ろうとすると、引数の数や種類を増やさなければなりませんが、
それには限界があります。そこで要求自体をオブジェクトにしてしまい、
そのオブジェクトを引数に渡すようにします。それがCommandパターンです。 相変わらず低レベルなやつほど長文で連投するねこのスレ
ホントだよ
現場ではデザパタなんて使ってないっていうのに
>>889
自分が何を知っていて何を知っていないかにすら無自覚だから
知らないところを無意識に嘘や想像や見栄で補って膨らませて
フワフワの長文合戦になる
十分な知識かマナーがあれば、どちらかがあれば、こうはならない でも自分で思ってるコマンドパターンが明らかに間違ってて
もう恥ずかしくて出てこれないでしょ
構造体渡し=コマンドパターン とか初めて見たわ
>>880
君がグローバルの問題を全く理解してないことは分かった。
ただこれは君がグローバルを使ったことが無いことを意味しており、悪いことではない。
>>881
「構造体」を適宜「オブジェクト」に読み替えられないのはゆとりだけ
>>882
「ラッパ」で問題なく通じるのに特殊限定した｢アダプターパターン｣と言い換える意味はない。
>>886
・関数ポインタ/関数オブジェクト＝コマンドパターン
やっぱデザパタ用語って死語じゃん >>886、訂正
・関数ポインタ/関数オブジェクト/callback＝コマンドパターン
> Design Patterns says that “Commands are an object-oriented replacement for callbacks.” >>890
相撲の決まり手みたいなもので
当人は意識せずに作ってて後からこれは、て分類しているようなものだから
先にパターンありきではないし、パターンを理解していなければ作れないということはない
ただ設計時・作成時に、ここはこのパターンを使う、って明示できる場合には
そのパターン名をモジュールの名前につけることで
設計書の記述を省略できたり、後からコードを見た時に理解しやすくなるという利点がある >>895
正解
てかこんな基本のKも理解できずに
デザパタいらない、デザパタは死んだ、デザパタなんて学習しなくても俺天才（キッ
とか言ってる馬鹿どもは馬鹿なのか？馬鹿ｗ >>895
前半は同意だが、、、
> そのパターン名をモジュールの名前につけることで
> 設計書の記述を省略できたり、後からコードを見た時に理解しやすくなるという利点がある
ねーよ。StrategyMyModule とか恥ずかしすぎるし余計分かりにくいわ。 >>893
> 君がグローバルの問題を全く理解してないことは分かった。
あんたがグローバルの問題を全く理解してないと言いたいのはわかった。
だが、あんたはその理由を全く言っていないｗ >>894
> ・関数ポインタ/関数オブジェクト/callback＝コマンドパターン
だ、あらそれ、コマンドパターンというパターンを
関数ポインタ/関数オブジェクト/callbackで
実装しますって話だよね？ >>897
で、お前は
OrizinaruTensaiHoge
とか付けるんだろ？
神だなｗ神馬鹿ｗ undoを実装するにはどうしたら良いでしょうか？
正解 コマンドパターンを使います。
undoを実装するにはどうしたら良いでしょうか？
誤答 関数ポインタを使います。
え？ 関数ポインタ？
関数オブジェクトも使います。
え？ 関数オブジェクト？
コールバックも使います。
え？コールバック？
それらを使って実装します。
だからそれらを使ってどのように実装しますかって話なんですが？ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
>>897
StrategyMyModuleはないわww ID:R8lp94JX
ラッパでも吹いてろゴミゆとりwwwwwwwwwwwwwwwww
>>899
俺はデザパタ用語は死語だと言っているだけ。
>>901
> undoを実装するにはどうしたら良いでしょうか？
> 正解 コマンドパターンを使います。
undoに何が必要か全く考えずに、ググって見つけたコードがコマンドパターン(ｷﾘｯだったんですね。
コピペプログラマ死ね >>893
構造体とオブジェクトの違いがわからない（理解しようとしない）クズ >>904
> undoに何が必要か全く考えずに、
え？ よく知られた設計を使わずに
独自で考えるの？無駄じゃない？
だからデザインパターンがあるんでしょ >>904
> 俺はデザパタ用語は死語だと言っているだけ。
今普通に使われてる用語が死語だと言われましても・・・ >>904
なんとかパターン（ｷﾘｯ
普通のプログラマがふっつーに語彙として使ってるパターン名を、お前はドヤ顔されてるように感じちゃうからイライラするんだな
勝手にイライラしてる人ってたまにいるけど、お前もそっちだったか これはヤバイ
901 デフォルトの名無しさん sage 2017/09/24(日) 10:48:10.22 ID:dIaNhcU3
undoを実装するにはどうしたら良いでしょうか？
正解 コマンドパターンを使います。
>>904
お前の名前は今日から
「構造体」を適宜「オブジェクト」に読み替え関数ポインタ/関数オブジェクト「ラッパ」パターン
君な >>910
それデザインパターンやん！
いつパタやん！ >>910
undoっていったらmementだろ
やったことじゃなくて状態の方を覚えとくんだよ >>910
またお前か
メメントも知らないカスが粋がるんじゃあない >>914
GitHubでパターン名を検索するくらいの知恵もないのか >>914
「構造体」を適宜「オブジェクト」に読み替え関数ポインタ/関数オブジェクト「ラッパ」パターン君
自演パターンはよくないで >>913
> とはいえ、デザパタに頼る＝デザパタが無いと何も出来ないから、というのはよく分かった。
> undoすらパターン提示されないと作れない程馬鹿なのね。
そうやって相手の程度を決めつけないと上に立てないほど自信がないのはよくわかった。
って言い返されたいパターン？ >>918
> mementoってパターンにする必要ないほどのゴミだろ。この程度でいちいち命名してたらきりがない。
じゃあmementoって名前を使わずに
mementoの話をしてくださいな。
自分でmementoって言ってるくせになぁｗ デザパタ派はアルゴリズムを考えることを全くせず、既存パターンからコピペすることは分かった。
この場合、パターンは手持ちのカードだから、無理にでも増やそうとするのも分かる。
実際、馬鹿にプログラムさせる場合はこの方が捗るかもしれん。この感覚は俺にはなかった。
たしかに、引数が多いのをまとめるために構造体渡しにすることを
コマンドパターンとか言っちゃうオツムの人にとっては
デザインパターンは便利かもしれないね
同時に、コマンドパターンを見て
引数が多いのをまとめるために構造体渡しにすることと同一だと
思ってしまうオツムのひとは
デザインパターンを学んでも理解できないわけだから
それ以前の知能が足りてないという意味で役に立たないだろうね
こういう人は本を読んでも、誰かに説明を受けても
理解できない、知識が吸収できない、抽象的なことが理解できない
わけだから、常に場当たり的に対応するしかないね
会話も成り立たないし
>>922
> デザパタ派はアルゴリズムを考えることを全くせず、既存パターンからコピペすることは分かった。
いやそりゃそうだろｗ
設計はアルゴリズムじゃない。
アルゴリズムは処理だが、
設計は構造だ
お前全く分かってないじゃないかｗ アルゴリズムにも名前ついてるの知らないのかな？
コピペはしませーん。
他の人が作ったアルゴリズムのライブラリを
使うだけだからコピペじゃありませーんって
言うつもりなのだろうか？
>>926
旧来の貧民プログラマにとってundo実装の第一選択肢は｢逆方向履歴｣なんだよ。
これがダメな場合は「スナップショット＋正方向履歴｣になる。
君はこのことにすら気づけない程の馬鹿だ。
しかし、実際、後者のほうが圧倒的に簡単だから、馬鹿には後者を押し付けておけ、というのは合ってるんだよ。
俺はC出身だから｢馬鹿はプログラミングするな｣という感覚なのだが、
昨今は文系馬鹿もプログラミングする機会があるわけだし、デザパタ洗脳も現実解としてはありなのかもしれん。
出来ない奴に考えさせたら永久にループするからね。
JavaでOOPこそが正義と洗脳するのも似たようなもんだし。 >>927
逆方向履歴パターンと
正方向履歴パターンですね？
新しいデザインパターンを考えて
名前をつけましたって言いたいの？ >>924
いつもの自分の狭い知識でなんとか理解したつもりになろうとして
「だから自動車というのは馬なし馬車だろう？」ってほざく輩の
辺りにまき散らす「めまい感」たるやw >>928
上司がお前らを馬鹿と見極めて「デザパタ洗脳」していたとしたら、全て辻褄が合うんだよ。 喚くだけの基地害
こんなやつとは絶対に一緒に仕事したくないな
>>918
undoめっちゃ難しくないか
そのへんのテキストエディタで操作履歴覚えてUndoしてるのとかって
どうやってるのか見当もつかん テキストエディタのUndoぐらいならわけない
何処までの操作を1コマンドとするかというのは有るが
まぁできるよこれぐらいは
Redo、Undoでメモリ節約のため差分を取っていく方式なら
全てのデータの変更の差分を取っておかないと上手くいかないが
そのデータが自分の管轄外の外部からも編集可能だった場合は難しい
腕の見せ所
つまりは差分を取っていくといっても
外部からも勝手に変更されるので
完ぺきには出来ないから
ある程度ファジーなつくりにする必要があるんだわ
例えばA→AB→ABCっていう編集なら
差分を取るのは簡単だし、元に戻すのも簡単だけど
他所のソフトからリアルタイムで「B」が削除されたとして
それは自分のソフトからも検出可能かもしれないが
自分のソフトから「B」を消したわけじゃないから
自分のソフトのUndoコマンドリストに入れるのはおかしな話だし
でも実際「B」は無くなってるわけで・・・
この辺下手にやるとRedo動作で消したはずの「B」が復活したりする
このような場合は若干難しい
>>933
イベントを記録して再生機能をつけるだけ
スーパーファミコン時代からある古典的なテクニックだ >>937
undo するんだから外で変更されたって覚えておけばいいだけだろ
そもそもそれ直感に反した動作になりがちだからよほどの理由がないとやらない方がいい >>937
無能らしくきちんとメメントパターンにすがれ >>929
＞「自動車というのは馬なし馬車」
「コマンドパターンは構造体渡し」って
そういうことだな、言い得て妙 デザインパターンを理解し、undo/redoに対してきちんと設計を考え答えられる人
対して、
デザインパターンが理解ない人
↓
940 名前：デフォルトの名無しさん[sage] 投稿日：2017/09/24(日) 17:12:54.02 ID:R8lp94JX [11/11]
>>937
無能らしくきちんとメメントパターンにすがれ
悲しいなぁ >>939
「それは自分のソフトからも検出可能かもしれないが」
とは書いたが、必ずしも検出が現実的に行えるかはわからないし
完璧なリアルタイム性が無くて、後から「変更したよ」
って通知が届くだけかもしれないし
そもそも取りこぼすかもしれないし
こういったことを考えていくと、ある程度ファジーに作っとくしかない
一体何の事例だと言われそうだが、俺の場合はファイルシステムだった
ファイル構成は俺の知らないところで
エクスプローラとかから勝手に変更されたりするから
フォルダ一覧から取得したファイルリストに対して何か編集が出来て
そのファイルリストがリアルタイムで実際のフォルダ構成に従って更新されうる場合
普通であれば、ファイルリストを、「一覧取得時点」での静的な物にしてしまうか
Undo、Redoを諦めるか、のどちらかだが
俺の場合はたまたま両方必要になってしまった
かなり稀なケースだとは思うけど、まぁ面倒だ >>943
ファイルシステムなら実行してダメならエラー表示するだけだろ
（どうしてもぶつかる可能性があるから）
>>937の編集とは全然違う話やん 俺にしたらデザパタ厨はゴミだとよく分かったけどね。
undo/redoするだけなら>>938-939で全く正しい。
履歴はコマンドを保持する形になり、呼び出し形式がコマンドパターンと類似してくる。これが>>886が混同した理由。
なおこのケースでは大半の場合、コマンドには関数ポインタは含まれず、構造体が渡される。
これすら分からない馬鹿が粘着している。
俺だったら内部でテーブルジャンプかハッシュだね。コマンド側から関数ポインタを与えるメリットが無いから。
なおEmacsはここでユーザ関数ポインタを与える構造になっているから、ほぼ無限の拡張能力がある。
>>943は相変わらず全く分からないみたいだが。
要はデザパタ厨はデザパタから一歩離れれば何も出来なくなるわけだ。
元々初心者にメッキを施す為だし、この意味では機能している。
>>933のようにundo出来ないよりは｢○○パターン｣で実装する奴の方が上と言えば上だ。
しかし俺は>>933を評価したい。理由は上達する可能性があるからだ。
どうすればいいのか？を考え続ければ上達はする。これが>>933だ。
この場合はこれ、を何度続けても、慣れはするが上達はしない。これがデザパタ厨だ。
プログラミング暦だけ長くても全く上達しない奴が偶にいて不思議だったのが、これか。
ただ、undo/redo等は標準的な機能ではあるし、OSS等を参考にすれば脳死済みのデザパタ厨でもある程度戦えるのかもしれん。 >>945
＞プログラミング暦だけ長くても全く上達しない奴
自己紹介パターン 日本人のカタカナ英語って
英米人と明らかに発音が違うが
オブジェクト指向を手続き型の中で
解釈するのってそれと似てるな
自分では同じつもりなんだろうけど
ぜんぜん違うんだよ
コマンドパターンの適用例の一つとしてundoがあるだけで
undoを実現するために存在してるパターンじゃないよ
undo/redoの実装方式だって一つじゃないんだし状況に応じて設計を選択すればいい
技術力の高い人はその選択が適切に出来る人
>>945
おいおい
「構造体」を適宜「オブジェクト」に読み替え関数ポインタ/関数オブジェクト「ラッパ」パターン君が
コマンドパターンなんて言葉使っちゃダメだろ
> デザパタ厨はゴミ
1レスでブーメラン頭に突き刺すとか民主党もビックリだぜ！ >>949
> コマンドパターンの適用例の一つとしてundoがあるだけで
ちなみに君の中のコマンドパターンの定義は、コマンド内には関数ポインタがあることが必要なのか？
通常のundoなら一番単純な実装はe(EventArgs)をundo stack に積んでいくことであり、
この場合は関数ポインタを保持してないから矛盾するが。 テキストエディタとか
操作毎にスナップショット撮るわけにもいかんだろ
オペレーション毎に逆捜査も実装しとんの？
それともうまいこと変更箇所だけ前後を記憶してるのか
>>918
頭の中でシュミレーションできる演繹な人なら
逆の作用を実装しなきゃいけないこと、
作用にかかわる環境、DB等も含め保存しとかないと再現できないこと、
が想定できるからcommandのようなものでなく状態の方を保持した方が楽とわかる
数学の公式を暗記する人と、自分で導いたり証明できる人との差だな
そしてわかってる人に説明するときピタゴラスの定理とかいえばいちいち証明せずに簡潔に伝わる
これが共通認識
デザインパターンは演繹と経験の帰納からによるベストプラクティスでもあるが、どこにでも使いたがるゴールデンハンマーアンチパターンもある
お前のように暗記するだけの奴は陥りがち ID:R8lp94JX
パターン暗記人間を馬鹿にしてるのに
自分がパターン暗記のワンパターン人間だったパターン
結局、ただの同族嫌悪パターンだったんだね
>>954
> 逆の作用を実装しなきゃいけないこと
お前らは本格的に馬鹿だな >>944
それがファイルのリストを編集するんよ
順番を入れ替えたり、属性くわえたり、あれやこれや
例えば順番入れ替えるのに挿入位置と元の位置をインデックスで覚えておくとすると
ファイル一覧が更新されたとき差異が有ったらインデックスがズレるから修正するとかね
(もっとほかの方法もあるけど、単純にインデックスで覚えておくとそうなる、という例え話)
もしくはファイルが消えたと思ったら、ゴミ箱から復活してきたりしたときに
ちゃんと元の編集情報を引き継げるのかとか
そういうのがUndo、Redo全般にまで絡んできてややこしいよね、って話 まぁ何か操作されるたびに状態全部丸ごと保存しておくような
アホみたいな実装でもメモリが圧迫しないほど
対象物が小さければ、それが一番簡単だわな
ただ実際には問題になるケースがあるから
逆操作どうのこうのになるんだが
逆操作が面倒なら、操作のうち30回に一回ほど完璧なスナップショットを取って
それ以外は順方向の差分にしておく方法もあるな
巻き戻すときは近場のスナップショットから順方向に差分を展開して求める
動画のキーフレームと差分フレームみたいなものだな
逆操作が要らなくなるから、かなりの負担軽減になるのと
スナップショットの頻度でメモリ使用量のチューニングが効くな
業務アプリではUndo、Redoを実装してくれって要望はあまりないんだろうな
大体は何かのエディタとかで必要になる機能だからなぁ
そんな印象を受けた
>>958
> まぁ何か操作されるたびに状態全部丸ごと保存しておくような
お前も相当にアホだな。デザパタ厨なんてこんなもんのようだが。
つか、レス読めよマジで。 結局のところコマンドパターンを使えばいいんでしょう？
>>957
もういいよ
どうみても要件がおかしいとしか思えんし ちなみに俺のレスが読めないとしても、俺以外のレスにも正解はあるんだから、
読み取れないのはお前らがどれが正解か分からないってことだぞ。
undo/redoなんて標準機能なんだし、考えたことはあってしかるべきで、
疑問を持っていた>>933はこの機会を逃さず尋ね、>>953までは進んだ。これは正しい進歩だ。
それに比べてデザパタ厨は何も考えてきて無いからこの有様。
｢もっと上｣を追求し続ける職人気質は必要だし、無いと上達はしない。
これは>>933にはあった。デザパタ厨にはない。 スナップショットと言ってもオブジェクトの全ての
情報を保存しておかなければいけないとは限らない。
一部だけで良い場合もある。
じゃあこのスナップショットを設計するには
どのようなクラスやメソッドが必要だろうか？
少し時間をあげるから考えてみると良い
>>963
あんたは重要なことをやってない。
undo/redoを行うとは言っているが、
その時に必要なメソッドはどんなものか？
を提示していない。 >>965
> その時に必要なメソッドはどんなものか？
お前も相当な馬鹿だな。 >>966
設計というのはそういうものだぞ？
アルゴリズムじゃないんだから、
クラスがあってどんなメソッドが必要かっていうのを
提示しなければいけない
例えばソート関数はアルゴリズムでこれ単体では設計ではないが、
そのソートアルゴリズムを切り替え可能な汎用的な
コレクションクラスのようなものは設計となる >>949
結局俺の疑問>>951には答えてくれないのか？
まあそちらは分かっているとは思うが、
コマンドパターンをその名の通り、「コマンドにオブジェクトを与える｣とするなら、
殆どの場合で関数ポインタを直接差し込む必要はない。
通常はキーを与え内部でハッシュ等から関数ポインタを呼ぶ。
ただ、Javaでは関数ポインタが取れないから、そもそもこの｢関数ポインタ引き用ハッシュ｣を作れない。（はず）
だからJavaでコマンドパターンを記述すると無理に継承が行われ、説明が余計に意味不明になる。
それが俺が基本的に説明のコード部分を無視している理由。Javaには構造を正しく記述する能力がない。
ただPythonでもそうなのなら、関数ポインタを差し込むのが定義なのかもしれんが。 >>968
コマンドオブジェクト内のメソッドのことを関数ポインタと呼んでるんなら
コマンド内には関数ポインタは必須だよ（間接的に呼び出すのでも別に構わないけど）
コマンドを実行する側が、コマンドの内部実装を気にする必要がなく
executeメソッドやundoメソッドみたいに共通の呼び出しで
各コマンドを処理できることに意味がある
Javaも8からラムダ使えるから単なる関数の実行だけなら
インターフェースや継承使わなくても関数ポインタ的なものを
実行側のリストに直接追加するなりハッシュ作って追加するなりできるよ undo/redoの仕組みは
- 操作を記録する方法
- 状態を記録する方法
- 状態の差分を記録する方法
のどれかかその組み合わせ
コマンドパターンでのundoは操作を記録して逆操作をする
メメントパターンでのundoは状態を記録
それぞれ良し悪しあるから状況にあったのを選べばいい
何を記録するか以外に
サポートするundoの機能によって記録するデータ構造が変わる
stackとかtreeとか
スナップショットってどうやって実現すればいいの？
undo/redoってどうやって実現すればいいの？
その答がデザインパターンなんだな
>>969
> コマンドオブジェクト内のメソッドのことを関数ポインタと呼んでるんなら
> コマンド内には関数ポインタは必須だよ（間接的に呼び出すのでも別に構わないけど）
ああ、この認識でいい。
Java7まではメンバポインタを関数ポインタ代わりとみなし、差し込んで上位からメソッド呼び出ししかなかったろ。
そこで疑問だが、ここで関数ポインタ直接差込のメリットあるか？
俺だったらハッシュをクロージャで捕捉して、
｢この呼び出し機構から呼べるのはこのハッシュ内関数のみ｣として制限する。
この方がソース上で一覧も見やすくなるし。
直接差込だと何でも実行可能になり、どうしてもバラけるし、
(俺はあまり気にしないが)変な物を差し込まれてないかのテスト等がしにくい。
パターン作った連中はここら辺の事情は分かっているはずで、ちょっと不自然さを感じるんだが。 C言語には関数ポインタは有るけど、
その関数ポインタは名前の通り関数へのポインタであって
データへのポインタは含まないんだよな
だから関数とデータで別々に扱わないといけない
>>972訂正
× メンバポインタ
○ メンバ関数ポインタ
まあ分かる範囲だろ。 >>972
> パターン作った連中はここら辺の事情は分かっているはずで、ちょっと不自然さを感じるんだが。
パターンは実装ではないので、
あるパターンに対して幾つもの実装がある
言語が変われば実装は異なる
だから君みたいに実装のことなんて考えてないんだよ
あくまで設計だから一つ上の層から物事を考えてる >>975
メンバ関数ポインタって何？
Javaに関数ポインタなんて無いんだが みんな話が通じてるかのように会話してるけど俺にはさっぱりだ
ロジックを無理に日本語にせずJavaかC++の疑似コードかなんかで書いてくれた方が誤解なく伝わるぞ
>>956
理由を挙げることができないのは馬鹿だからですか?
小学生とかよくそうだよね >>981
> デザパタって何？
デザインパターンのこと
設計のパターン
例えばソートでもアルゴリズムによって
バブルソートなどという名前がついているように、
デザパタでもパターンに名前をつけてる。
もし名前がなくて「undo/redoを実現するやり方」という言い方をしたら
どうやってやるのか？っていうのを他の人と知識の共有ができないし、
逆にどうやってやるのか？を「オブジェクトをリストの形でもって
それぞれが変更内容の情報を持っていて、その変更内容を逆方向に
適用することでundo、順方向に適用することでredoを実現する」という
言い方をしたら冗長な上に正確ではないし、undo/redo以外にも使えるってことが
わからないし、まあ何も良いことがないだろ？
名前をつけることで、デザパタの知識を持っている人の間で
知識を共有できるわけよ。
その知識のカタログがデザインパターン >>981
ゴミ。
結局デザパタ厨は誰もundoすらまともに実装出来なかったろ。推して知るべし。 いや・・・クイックソートという名前を出してる人に
クイックソートを実装してみろって意味不明だろ。
ID:3Bk8qYPA == ID:N+1HPlkM
物凄く残念な人が住み着いたから
しばらくはこのスレもお休みだな
俺は最初から居たから、その理論ならデザパタ厨がコミだということになる。
無理に布教しようとするからおかしな事になる。
仮にデザパタ厨がundo如きピシッと実装出来ていれば、自然と布教出来ただろうに。
この有様では訴求力なんて皆無だろ。
>>990
反デザパタのお前に訴求力があればその台詞も格好ついたんだろうけどなあ >>991
俺は「反デザパタ」ではなく、「デザパタは役に立たん」と言っているだけ。
ソースはデザパタ厨の実力。 ID:3XblncDf＝ID:R8lp94JX＝「構造体」を適宜「オブジェクト」に読み替え関数ポインタ/関数オブジェクト「ラッパ」パターン君
ゴミｗ
デザパタは必要
ソースは
「構造体」を適宜「オブジェクト」に読み替え関数ポインタ/関数オブジェクト「ラッパ」パターン
これ読んだだけでわかる
lud20221012023906ca
このスレへの固定リンク： http://5chb.net/r/tech/1502182334/ヒント：5chスレのurlに
http://xxxx.5ch
b.net/xxxx のように
bを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「オブジェクト指向システムの設計 173 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>1枚 」を見た人も見ています：
・オブジェクト指向システムの設計 172
・オブジェクト指向が無かった頃って
・LinuxカーネルはC言語なのにオブジェクト指向
・すまん、プログラミングのオブジェクト指向ってなんなん？PGモメン頼む
・【隔離】オブジェクト指向アンチスレ
・オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
・【時代はコンピュータ】仮設住宅早期供給へ新開発 敷地内の住宅数や配置をPC上で速やかに設計出来るシステム 数年内に実用化目指す
・ハロープロジェクトにおけるニッチ産業システムとは
・ オープンワールドで木や草が刈れる、オブジェクト壊せる、燃やせるなんてゲームの面白さに無関係では
・PCメーカー「『ＰＳ５』はシステム設計の傑作。ストレージやデータ圧縮技術などの様々な面で革新的」
・【技術】ニューロテイラーメイドの実現を目指すウエアラブル型「視覚評価用脳波計システム」を設計開発 [無断転載禁止]
・【想定外】廃炉が決定した高速増殖炉「もんじゅ」、液体ナトリウムの抜き取りを想定せずに設計されており搬出困難 ★4
・システムアーキテクト Part13
・3Dアクションゲームの設計
・日立ビルシステムの裏事情3
・【野球】＜「プロ野球離れ」＞どこまで本当か？ 伝統のスターシステムの終焉 コアなファンと一般のライトユーザーの二極化... ★3
・ヘヴィーオブジェクト 26機目
・ヘヴィーオブジェクト 28機目 [無断転載禁止]
・【ヘヴィーオブジェクト】おほほちゃんはおほほかわいい [無断転載禁止]
・【ヘヴィーオブジェクト】ミリンダ=ブランティーニはジト目かわいい2 [無断転載禁止]
・【エプスタイン事件】世界の大手企業、英アンドルー王子のプロジェクト支援を相次ぎ撤回
・オクトパストラベラー、IGNJチャンネルでストーリーや戦闘システムなどを酷評される
・「ハロプロの合宿システムは、アイドルになるなら受けるべきです」つばきファクトリーのエース・浅倉樹々が語るアイドル論！
・歴史的隔離システムのエネルギー
・ ディスクシステムの最高傑作ってなに？
・英熟語って速読よりシステムのほうが詳しい？
・【シャルリとは誰か】E･ﾄｯﾄﾞ【家族システムの起源】
・中国のスマホゲームの課金システムが合理的ですげえ
・ボーイング737MAX8墜落事故、「制御システムの欠陥」でほぼ確定
・【悲報】「武器が壊れる」システムのゲーム、クソゲーしかない
・【IT】富士通、基幹システムの移行を安価に ライセンス購入の必要なく
・札幌が静止する日 基幹システムのDBが大破して戸籍や住民票が吹っ飛んだ模様
・なんでレースゲーマーって色んなシステムの作品があるのをよく思わないの？
・【ゲーム】『武装神姫』新作ゲームの制作が決定！ 〜「武装神姫」シリーズの新プロジェクト始動〜
・【名古屋市】市民からの問い合わせにＡＩを活用へ システムの実証実験始まる
・【プログラム/和暦】簡単だと誤解されがちな、システムの「新元号」対応
・上國料システムのせいでアンジュルムの雰囲気がおかしくなってきてないか？
・貧乏臭い見た目とシステムの「ホームドア」を使った実証実験 近鉄・大阪阿部野橋駅で始まる
・【こやけん躍進↑ほま豚歴史的大敗↓】ブチかましアンチスレpart32【支配システムの当然の末路】
・【岡山市】コピー代230万円無駄だった タブレット端末使用のペーパーレス会議システムの効果てきめん
・【宇宙開発】月の有人拠点建設の「遠隔操作と自動制御の協調による遠隔施工システムの実現」にめど［03/28］
・昔のポケモンは特殊の特攻特防分離や技の物理特殊分離みたいにもっと戦闘システムの根幹から新しくなってたんだけど
・糞城プボジェクト1229 ステファンの覇権声優予告
・【こやけん躍進↑ほま豚歴史的大敗↓】ブチかましアンチスレpart31【支配システムの当然の末路】
・【サッカー】＜本田圭佑＞挑んでいた「地震予知装置」開発...豪雨被害に見舞われた西日本に“水浄化システムの導入”を提案
・【臨時政府樹立１００年】「特権層の時代終わらせるべき」＝文大統領 一方、消防隊員の待遇改善や災害放送システムの見直しも指示[4/9]
・【レイプ被害】記者からの暴行被害訴えた伊藤詩織氏が会見 捜査、司法、社会意識の改革とレイプ被害者の救済システムの必要性を訴える
・フィリピンの国家プロジェクト【ノアコイン NOAHCOIN】虚偽発覚でも爆上げ？ 13
・日本代表の戦術・システム part33
・プロジェクト東京ドールズ part123
・プロジェクト東京ドールズ part143
・ガリガリ脱出プロジェクト part63
・プロジェクト東京ドールズ part103
・【仮面女子】アリスプロジェクトEASTスレ93
・【仮面女子】アリスプロジェクトEASTスレ113
・【バーチャルYouTuber】ゲーム部プロジェクト 33
・【A応P】アニメ“勝手に”応援プロジェクト part33
・【プロセカ】プロジェクトセカイカラフルステージ！feat.初音ミクの声優を語るスレ3
・PS4に重大なバグ、特定の文字列を含むメッセージを受けるとシステムダウン 3
・東京電機大学 工学・二部・未来科学・システムデザイン工学部 Part.123
・【少子化対策】ひろゆき氏、少子化対策に大胆提言 1人産めば1000万円支給「社会のシステムが変わる」 ★3
・【NHK受信料問題】識者「お金を払わないと画面が映らなくすればすべて解決」「やらないのは今の集金システムが崩れるから」★3
・【カルロス・ゴーン】「Ｘマス後まで、おりの中」ゴーン氏再逮捕、世界に驚き 「日本の刑事システムが世界に暴露」★3
・【悲報】SKEのイベント酷すぎw メンバーがポップコーンや綿菓子を販売するも現金では買えずCDを買わないといけないシステムwwwwww★3
・【NCOS】ＮＥＣ通信システムの裏事情 PART 1
15:22:55 up 6 days, 1:47, 0 users, load average: 6.51, 8.77, 9.20
in 0.11015486717224 sec
@0.11015486717224@0b7 on 121805
|
