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

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

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

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

**デフォルトの名無しさん** · 2017/08/12(土) 17:46:07.32

コーディングよりはデータモデリングの方が
重要になってくるかなと

ユーザ -> ロール -> 権限
受注 -> 受注明細
受注 -> ユーザ

エンティティを分けるとしたらこうかな

イミュータブルデータモデル(入門編)
https://www.slideshare.net/kawasima/ss-40471672

関数型に適したデータの持ち方はこれとか

updateを行わずにinsert/deleteでやりくりするのだけれども
数百万のデータ扱うときにそういうやり方ってio的に厳しくないかな
SIer戦士の知見を伺いたいね

**デフォルトの名無しさん** · 2017/08/12(土) 18:28:09.46

>>159
つgoogle「イザナミだナルト」

読むとこのスレが丁度術にかかってるみたいで笑えるぞ!

**デフォルトの名無しさん** · 2017/08/12(土) 18:31:25.69

>>160
IOっていってもほとんど読み取りだからな
キャッシュすりゃいいわけよ
キャッシングはイミュータブルな構造との相性もいい

**デフォルトの名無しさん** · 2017/08/12(土) 18:54:00.06

イザナミだ
https://jumpmatome2ch.net/archives/9343.html

**デフォルトの名無しさん** · 2017/08/12(土) 20:33:40.23

イザナミすらしらんゴミがイキってて笑える
夏休みの宿題済ませてこいよカース

**デフォルトの名無しさん** · 2017/08/12(土) 21:35:51.52

>>6
それ宣言型、関数型、論理型が並列に並んでるのおかしいね。

**デフォルトの名無しさん** · 2017/08/13(日) 00:33:44.55

なんか一人か二人荒らしまわってる連続投稿君がいるみたいだけど
>>115
は元々
Java、C++、C#などは副作用を前提にプログラムを書くスタイルを基調としているから
手続き型言語のグループに入るけど
関数型はそれを意図的に排除する仕組みが言語仕様で用意されている
ってことまでしか言ってないからね
排除された結果、自分が思ったコードが書けなかったとしても、それは関係ない
だから類似コードを示す必要性は全くない
例えば論理型言語のPrologで注文受注のコード書いてたらバカだろ
もしくはGPUのシェーダー用のプログラミング言語(HLSLとか)で
注文受注のコード書いてたらバカだろ
あえてバカみたいなことはする必要ないんじゃないかな

**デフォルトの名無しさん** · 2017/08/13(日) 00:46:50.01

ID:A4v2+zpKが如何にキチガイか理解していただけただろうか
まぁ18も連投している時点で明らかなわけだが
付き合いきれまい

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

最近jsでデータの整理整頓をしない環境にいたので覗きに来ました

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

>>166
逃げてるだけじゃん

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

本題は、JavaやC++やC#は手続き型言語のグループに入るって部分であって
関数型は～の部分は、少なくともこれらの言語は関数型では無い
っていう例で挙げているだけにすぎず
関数型言語で受注プログラムを解くとか解かないとか
そういう話は一切してないし
関数型だとキレイに書けるとも一言も言ってないし、全く言及してない

**デフォルトの名無しさん** · 2017/08/13(日) 04:32:44.46

こうなってるけどな

http://mevius.2ch.net/test/read.cgi/tech/1467992113/991-996
関数型言語では言語仕様で、手続き型言語の欠点を意図的に排除する仕組みが用意されている

あ · 2017/08/13(日) 09:49:26.83

一体何だったのか？

**デフォルトの名無しさん** · 2017/08/13(日) 10:41:24.21

文章を勝手に改変して「こうなってるけどな」と言われても

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

>関数型はそれが出来るというより
>意図的に排除する仕組みが言語仕様で用意されているといったほうがいいな
ってしっかり書いてあるだろ

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

そしてこれは本題ではなく
JavaやC++やC#は手続き型言語のグループに入る
ってことを説明する、そうじゃないものを例に挙げたまでだ
関数型言語で受注プログラムを書くとか書かないとか
まったく言及してない

**デフォルトの名無しさん** · 2017/08/13(日) 11:12:14.57

手続き型に構造型にしやすくするための構文を追加したのが構造型言語
その構造型言語にオブジェクト指向しやすくするための構文を
追加したのがオブジェクト指向言語

そしてオブジェクト指向言語に内包される手続き型と構造型部分に
関数型言語の特徴を組み込むのが今のトレンド

**デフォルトの名無しさん** · 2017/08/13(日) 11:16:07.23

逝っとけオブジェクト指向

**デフォルトの名無しさん** · 2017/08/13(日) 12:21:52.31

構造「型」言語とか言ってる時点で
何の信ぴょう性もないもんだな

**デフォルトの名無しさん** · 2017/08/13(日) 12:29:06.82

すいません、どなたかセックスさせてください

**デフォルトの名無しさん** · 2017/08/13(日) 15:54:04.19

>>173-174
こういうことだろ

http://mevius.2ch.net/test/read.cgi/tech/1467992113/991-996
関数型言語では
手続き型言語の欠点である順番やタイミングに依存する方式から逃れること
が出来るというよりは
手続き型言語の欠点である順番やタイミングに依存する方式を
意図的に排除する仕組みが言語仕様で用意されているといったほうがいいな

**デフォルトの名無しさん** · 2017/08/13(日) 16:18:25.24

なんだよ関数型崇拝者はまだ全く説明できないで同じこと繰り返しているのかよ

**デフォルトの名無しさん** · 2017/08/13(日) 16:21:51.11

>>180
で

> 手続き型言語の欠点である順番やタイミングに依存する方式を
> 意図的に排除する仕組みが言語仕様で用意されているといったほうがいいな

ってなんだよ
エアプか？

**デフォルトの名無しさん** · 2017/08/13(日) 16:29:40.28

>>182
前スレのID:m8GLf68Fがそう言ってるってことなんだがな

**デフォルトの名無しさん** · 2017/08/13(日) 16:50:18.17

そんな仕組みないです
参りました
ごめんなさい勢いで言っただけなんです
許してください🙇🙇‍♀

**デフォルトの名無しさん** · 2017/08/13(日) 21:19:15.64

ん？今何でもするって言ったよね？

**デフォルトの名無しさん** · 2017/08/13(日) 22:52:25.17

言ってないんだよなぁ

**デフォルトの名無しさん** · 2017/08/19(土) 19:12:00.14

>>10は
1. 権限管理
2. キャンセル可否のビジネスルール
3. 同時実行制御
っていうレイヤーの異なる3つをごちゃまぜにしてるからダメなんだろ
データモデルの良し悪しとは全く別次元の話だわ

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

常識的に考えるとそれらは別のレイヤーでやるよな
ただあの人みたいにいずれも検証だから同じレイヤーでやるみたいな派閥もあるみたいだね

あ · 2017/08/19(土) 19:42:05.97

>>187
cancelメソッドとそれが不可能だって例外ですべてハンドリングするのも同じ次元だけどな。
>>188
検証としては同じレイヤでやるが、実際の処理を同じものが持つかどうかは別だぞ。
検証処理を行うのは一人がやるべきだし、それぞれのステートにおいて適切なロジックがやるべき。
そのロジックの結果同士の和とか積になるよね、って。
そうしないと優先順位が生まれたときに、あとから定義したりしていなかった優先順位の解釈を、既に散在してしまったチェックロジックに入れて行くことになってしまう。
データが一人でやるべきものではなくて、ビジネスロジックが検証してやるべきものだ、って話だよ。

**デフォルトの名無しさん** · 2017/08/19(土) 22:03:05.65

>>>187
権限がなければキャンセル処理を実行できないようにしたいのであれば、例えばキャンセルボタンをグレーアウトさせればいい
その場合、権限ないにも関わらずにcancelメソッドが呼び出された場合は業務エラーじゃなくシステムエラーだから扱いが異なる
最終的な実装はどうあれ同じ次元として扱ってるとまともな設計にはならないよ

**デフォルトの名無しさん** · 2017/08/19(土) 22:24:13.25

アンカ間違えてた
>>187じゃなく>>189ね

下の3つを「検証」って言葉で一括りにしてるとプログラムの大半はなんらかの検証処理になっちゃう可能性がある
検証って言葉をどういう意味で使ってるのかとか、何に対する検証なのかを考えたほうがいい気がする
ロジックの散在とか優先順位の解釈とか言いたいことは分からなくはないけどね

1. 注文がキャンセル可能かどうか
2. ユーザーがキャンセルの実行権限があるかどうか
3. キャンセル実行時にデータ整合性が保証できるかどうか

あ · 2017/08/20(日) 07:16:27.75

>>190
それは、キャンセルボタンが押せるかどうかの判定で、キャンセルができるかどうかの判定と似てるが違うものだよ。
キャンセルボタンではキャンセルできないけど、電話してオペレーターにキャンセルしたい、と頼めばやってくれる、とか。

>>191
そうだな。言葉が悪いか。
状態検証
権限検証
整合性検証
は、すべて「検証」ロジックが呼び出すべき処理、って感じかな。

**デフォルトの名無しさん** · 2017/08/20(日) 08:59:15.38

>>192
引っ込みつかなくなったのはもうわかったから

**デフォルトの名無しさん** · 2017/08/20(日) 13:53:16.66

implements ICancelable
でいいだろこれでコンパイルも通る

おまえら、たったこの1行のコードもひねり出せない無能のチンカスガイジ低級プログラマ土方ジャップランド土人だったのか？

**デフォルトの名無しさん** · 2017/08/21(月) 00:11:33.04

何がええんや

**デフォルトの名無しさん** · 2017/08/21(月) 00:14:41.29

100歩譲って無能のチンカスガイジは認めるわ
土方プログラマっていうのもまあ分かる
しかしジャップランド土人というのもそのとおりだ

**デフォルトの名無しさん** · 2017/08/21(月) 01:07:09.51

>>192
>すべて「検証」ロジックが呼び出すべき処理、って感じかな。

そのすべてを呼び出す「検証」ロジックって何ぞな？

**デフォルトの名無しさん** · 2017/08/21(月) 03:03:23.75

>>196
認めすぎィ！

あ · 2017/08/21(月) 07:29:55.85

>>197
あー、確かに。それは微妙か。
データフローとか、ジョブの検証フェーズになるだろうね。

**デフォルトの名無しさん** · 2017/08/21(月) 19:51:47.16

話は変わるが
私はユーザーオペレーションのミスも例外で処理する(例外シナリオ)
これは一番やりたいことを最も早く簡潔に書くためだ(メインシナリオ)
やりたいことが出来ないのはシステムにとって致命的だが、ミスは回避できる特に開発段階では
ミスかどうか早めに自発的に判断するのはやぶさかではないが、そこでも例外を投げて例外シナリオであることを明示する

システムにとって必要不可避なユースケースを最小で実現するためだ
問題があれば聞かせてほしい

**デフォルトの名無しさん** · 2017/08/21(月) 21:02:35.44

>>200
前にそれやったらロジックが複雑になったことある

**デフォルトの名無しさん** · 2017/08/21(月) 21:28:17.07

>>201
うちではロジック変わらない
設計者の技量の問題かな

**デフォルトの名無しさん** · 2017/08/21(月) 21:52:21.63

>>202
エラーによっては別の方法を促さなきゃいけない仕様になっているのに
まとめて処理しようとしててmain関数がお化けになってた
エラーメッセージってちゃんと表示しようとするとその時の色んなもんが必要になるんだけど
それも上手く引っ張ってやらないといけない
その場でやったほうが楽だったよ
エラーメッセージ用の必要なデータの抽出ってのも結構骨が折れる
しかも頂点でしかやってねーからある時mainが全部using持ってないと動かなくなちゃった

**デフォルトの名無しさん** · 2017/08/21(月) 22:06:44.94

>>203
それは代替シナリオで例外シナリオではない
記述場所の問題なら例外に乗せて投げればいい

そもそもmain関数とかオブジェクト指向じゃないだろそれ

**デフォルトの名無しさん** · 2017/08/21(月) 22:06:53.89

もともとプログラムってのは確認して実行しても良さそうなら実行っていう戦略とは根本的に相性が悪い
確実に実行できることを保証するって深く考えると実はかなり難しいのでまず間違いなく何処かで漏れる
どうせ漏れがあるなら最初から確認せずにとりあえず実行してしまえばいい
実行してみて何事もなければそれで良し
ダメなら適切な例外をなげろって設計が実は最も自然な設計
これだけでも完全なシステムを作れる
まあそれだけだとUXが悪いからクライアント側で書式チェックぐらいはしてもバチは当たらんだろうね

**デフォルトの名無しさん** · 2017/08/21(月) 22:19:48.01

>>204
例外じゃん
少なくとも一瞬は例外だったじゃん
そこから例外→代替シナリオのルートがねーと
コード上では
お前の処理が全部食っちゃってて手の入れようがない

**デフォルトの名無しさん** · 2017/08/21(月) 22:34:43.69

>>206
いや代替シナリオは別途設計書く
コードの例外と例外シナリオは同じではないぞ

**デフォルトの名無しさん** · 2017/08/21(月) 22:39:57.15

しかも頂点まで戻って来ててしまって

代替シナリオで以降の処理を続行的な選択をすると
例外発生処理まで来たルートをフラグを見てお通しする
見事なクソコードなのだ!
パオーン!って俺も叫んだ!

プログラム全体で作ったインスタンスを消すともう動かねぇよ
どーすんだコイツ的な衝撃

**デフォルトの名無しさん** · 2017/08/21(月) 22:46:23.39

>>207
代替があるかどうか？って
ハイ、イイエ
をその処理に対して誰かがちょっとでも浮かぶかどうかじゃん?

ここまとめて例外で弾き飛ばすと
あ、ここは例外でいいよ
メッセージ出して欲しいなぁ
って客の気分やから
融通が効かないクソコードになんで

**デフォルトの名無しさん** · 2017/08/21(月) 22:48:21.65

>>209
何言ってんの

**デフォルトの名無しさん** · 2017/08/21(月) 22:55:05.00

>>210
(´・ω・`)俺の言ってることあんま理解できない?

**デフォルトの名無しさん** · 2017/08/21(月) 23:04:43.19

誰か通訳

**デフォルトの名無しさん** · 2017/08/21(月) 23:06:06.88

>>207
サービスで代替？があるやつだけ教えてやったけど
これだけだと思ってるの?
まだまだあるぜ
バーカ
検討を祈る!

**デフォルトの名無しさん** · 2017/08/21(月) 23:16:42.53

うん、俺がアホだったね
死ぬわ(´・ω・`)
環境特有の状況だね

**デフォルトの名無しさん** · 2017/08/21(月) 23:19:42.56

そしてすまん(´・ω・`)

**デフォルトの名無しさん** · 2017/08/21(月) 23:22:00.62

代替シナリオと代替サービスを一緒くたにしてるのかな

**デフォルトの名無しさん** · 2017/08/21(月) 23:26:47.25

>>216
いや酒飲んで寝起き

**デフォルトの名無しさん** · 2017/08/22(火) 06:43:04.83

お酒のせいにする男ってサイテー

**デフォルトの名無しさん** · 2017/08/22(火) 07:37:50.45

まだ夏休みだっけ？

**デフォルトの名無しさん** · 2017/08/22(火) 09:33:05.29

○次受けが多いほど退場率が早くなる。高くなる

直受けの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万台にならなくて済む

**デフォルトの名無しさん** · 2017/08/23(水) 07:27:54.25

オブジェクト指向に造詣の深い諸兄は、DTOとかPOCOとか、クラス図に書いてます?

**デフォルトの名無しさん** · 2017/08/23(水) 08:20:46.57

>>221
データベースのdtoは書かない
ViewModelは書く

**デフォルトの名無しさん** · 2017/08/24(木) 10:06:58.66

>>222
一般的にはそういう認識で良いんですね

プログラムできない上司と二人きりの社内IT便利屋なので世間様の動向が解らず
ありがとうございます

**デフォルトの名無しさん** · 2017/09/02(土) 01:06:47.28

いつの間にかWikipediaのオブジェクト指向のページがいい感じになってるな

>Eclipseを開発したDave Thomasや、オブジェクト指向という言葉の生みの親であるAlan Kay博士は
>オブジェクト指向という言葉は失敗だったと語っている。
>[1] これは、本来オブジェクト指向が重視すべきは「オブジェクト」ではなく
>「メッセージング」であるにもかかわらず「メッセージング」がおろそかにされているためである。
>特に言語の進歩において「オブジェクト」や「クラス」の側面ばかり強調される傾向にあり、
>Alan Kay博士は「Smalltalkが最高に好きという訳ではないが、他の言語に比べればマシである。」と述べている。

昔はこんな記述なかったように思うが、これが今の空気感なんだよな
俺もそういうことを言ったことがあるし、そう思う人もいくらか居て
だんだん発展して、そういう空気になってるんだな
オブジェクト指向は本当に名前が悪くて、メッセージング指向とでもしておくべきだったと思う
名前に引っ張られるってのは少なからずあるからな
メッセージング、メッセージのやり取り、というのは手続き型言語においては手続きそのものであるが
やはり手続きの部分が読みやすい方が良い、処理の順番が見たまんま一目瞭然な方が良い
何がどの順で実行されているか明瞭、といった古典的な要素を見直そうというそういう流れ
処理の順番に結果が依存する手続き型言語において、処理の順番が把握しづらいのは本来恐ろしいことだからね
なるべくオブジェクト同士の相互作用たる手続きの部分が簡潔になるようにクラス設計しなければならないんだけど
そのことを忘れて、クラスとは何ぞや、オブジェクトとは何ぞや、といったオブジェクト原理主義みたいな病気に
かかってしまう、まぁ、麻疹みたいなものではあるけど、名前が「オブジェクト指向」になってるからどうにも助長する
だからメッセージング指向の方が良かっただろうね

**デフォルトの名無しさん** · 2017/09/02(土) 09:50:16.49

> だからメッセージング指向の方が良かっただろうね

メッセージング指向の何が良いの？

**デフォルトの名無しさん** · 2017/09/02(土) 10:24:51.59

名前がカッコいい

**デフォルトの名無しさん** · 2017/09/02(土) 10:56:48.95

メッセージのやり取りが需要！

そいで何が重要なの？

メッセージのやり取りが需要なんだ
名前がまずかった。
メッセージのやり取りがー
メッセージのやり取りこそがー

で何が重要なの

メッセージのやり取りが需要だって言ってるだろ！

オブジェクト指向という言葉の生みの親であるAlan Kay博士は
名前がまずかったことにこだわり、その中身の重要性を語ることはなかった

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

メッセージは大事だが本質ではないよ
メッセージ指向が目指したのは「可能な限りの決定の遅延」
設計時、実装時、実行時、運用時（保守、メンテ時を含む）などすべての局面での徹底の試み

「遅延結合」ともいえるけど、実行時に限定してしまう人がいるからこっちの表現の方がいい

メッセージというのは「決定の遅延」の重要性やどうやればいいのかわからない人のための方便でありお題目
だからメッセージが大事、メッセージが大事と繰り返す割に説明ができる人が少ないのはまあある意味必定かと

http://metatoys.org/oxymoron/oxymoron.html

**デフォルトの名無しさん** · 2017/09/02(土) 11:48:07.70

> メッセージ指向が目指したのは「可能な限りの決定の遅延」

決定の遅延は、問題の先送りと考えればよい。
結局あとから問題が発覚するだけにすぎない。

**デフォルトの名無しさん** · 2017/09/02(土) 11:59:21.35

「最適化や解決を急ぎすぎない」といった方が適切かな

対象とするシステムやそこで解決すべき問題についての理解が深まるまで、
あるいはハードウエアなどの状況が改善し解決してくれるまで、とりあえず運用可能な実装ができ
しかもよい解決法が出てきたらそれで容易かつ安全に置き換えられるようなそんな感じ

たとえば参照先の文書をきちんと読まずに反射的にしたレスをうまく取り繕えるようなメタシステム作りを目指すのがメッセージ指向

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

> 対象とするシステムやそこで解決すべき問題についての理解が深まるまで、
それでは、ずっと理解は深まらないのか？って問題が有るな。
例えば一回作ったことがあるシステムならば理解は深まっていると考えられる。
では理解が深まってる状態で、何の決定を遅延させるのか
遅延させることに意味があるのか？

> しかもよい解決法が出てきたらそれで容易かつ安全に置き換えられるようなそんな感じ
今は容易かつ安全に置き換えられるようになっている。ただしOSの力によって。
アプリケーションは一旦終了してから入れ替えて起動しなおせばシステムを
停止すること無く、アプリを更新することができる。

そこが昔と今の違いなんだろう。昔買ったMSXは起動するとBASICが起動した。
OSではなくてBASIC。OSが存在せず言語の開発環境がOSそのものだった。
そういう時代においては、言語自身にプログラムを入れ替える方法
つまりアプリケーションの再起動というOSの仕事までやる必要があった。

だから「決定を遅延させる」なんて話が出てくる。
それがOSの力で解決して今は言語に「決定の遅延」をもたせる必要がなくなっている。

決定の遅延の重要性が理解できないのは、時代にあっていないからに過ぎない。

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

先送りして後で問題になるではなく
先送りして後で解決してもいいように作る
ってことでしょ

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

容易かつ安全に置き換えられるのはアプリだけで
OSの更新はOSを停止せずにできないように思うかもしれないが。
そこでクラウドというものがでてくる。

システムをサービス化して、ネットワークで通信させることにより
システムを疎結合にして無停止でシステムを容易かつ安全に置き換えることが
できるようになってる。

説明するまでもないと思うが、古いシステムを使いながら
裏で新しいシステムを準備し、新しいシステムが有効になったら
ネットワーク経路を切り替える。

OSもネットワークもろくにない時代に言語だけで問題を
解決する方法を模索していたってだけで現代には合わないのさ。

すでに現代はシステム全体で見れば、決定の遅延を行っており
容易かつ安全に置き換えられるシステムができあがってる。
それは言語に求めることじゃない

**デフォルトの名無しさん** · 2017/09/02(土) 12:26:11.03

以上
アホの戯言でした

**デフォルトの名無しさん** · 2017/09/02(土) 12:32:31.35

反論なし

**デフォルトの名無しさん** · 2017/09/02(土) 12:49:27.80

あと昔と今の違いは今は素人が使っているという点があるな。
別の言い方をすれば、プログラムを作った人と使う人が違う。

言語レベルで対応してモジュールや関数単位で、
容易かつ安全に置き換えられるようになったとしよう。

でもそれはあくまで言語レベルであり、メッセージの送り側と
受け取り側の両方がメッセージの内容を正しく理解できなければ
バグなく動くことはできない。

しかしその点は無視されている。バグであってもシステムが停止せずに
動き続けていればOK。バグによってデータがおかしくなっても
停止しないシステム上で修正すればいい。バグによって処理が停止しても
デバッガが起動してシステムを直して再開できればOK

当時の「容易かつ安全に置き換えられる」っていうのは
停止しないシステム上で人間がトラブルに対処して再開できればいいというレベル
コンピュータを使ってる人＝プログラマ（素人ではない）なので
自分（もしくは担当技術者に依頼）して対応するという前提になってる

**デフォルトの名無しさん** · 2017/09/02(土) 12:51:57.25

完全に早期結合の考え方なんだよね
どこから指摘してよいものかちょっと迷う

**デフォルトの名無しさん** · 2017/09/02(土) 12:53:17.39

とりあえず、参照元読んでもらうことはできる？
それについての疑問に答える方が効率的かなと思う

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

参照元なんて無いから、
俺に反論してくれればそれでいい

**デフォルトの名無しさん** · 2017/09/02(土) 13:00:33.66

>>237
今はシステム全体が、物理マシンレベル、仮想マシンレベル、OSレベル、
コンテナレベル、プロセスレベルといった単位で
疎結合になっているから言語自身は早期結合で十分という時代

**デフォルトの名無しさん** · 2017/09/02(土) 13:00:40.57

>>236
当時っていつの話？
参照先読んでもらえばわかるけど、もう君が言うような「今」の当たり前は70年代に出来ていて
その先を目指すにはって話なのだけど…

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

早期結合でできる部分はそれで済ませればいいと思うよ

**デフォルトの名無しさん** · 2017/09/02(土) 13:05:40.32

>>241
> もう君が言うような「今」の当たり前は70年代に出来ていて

70年代のどこにクラウドがあったの？

あんたの言う70年代に出来ていては
原始時代にも石炭はできていて～っていうのと変わらん。
それをうまく使いこなせるようになったのが今だ

**デフォルトの名無しさん** · 2017/09/02(土) 13:05:45.97

結局、早期結合信奉者の問題は「神の視点」から離れられないことなんだってよくわかる主張だと感じるよ

**デフォルトの名無しさん** · 2017/09/02(土) 13:06:35.50

神じゃねーけどなｗ

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

厨二「ふっふっふ、われは神の視点を持つもの」

**デフォルトの名無しさん** · 2017/09/02(土) 13:28:02.93

>>243
もちろんクラウドなんかはないけど
しかし君が想定しているよりはずっとネット環境は整っていたよ
少なくともアラン・ケイがメッセージ指向を考えたり実験したりしていた場ではね

**デフォルトの名無しさん** · 2017/09/02(土) 13:57:41.57

だがそんな彼でも、ネットワークの向こう側のコンピュータを
何台も用意して、接続先を切り替えながら無停止で
システムを運用するという発想は生まれなかったわけで

**デフォルトの名無しさん** · 2017/09/02(土) 14:05:57.73

たぶん参照リンクを参照することをしない人向けには無用かもしれないけど、いちおうは挙げておくと

たとえばこのリストアされたアルトのデモで当時すでに出来ていたことのその片鱗を見て取れる
https://www.youtube.com/watch?v=9H79_kKzmFs&;t

メッセージ指向の実践として、たとえば動かしているシステムの仕様を動的に変更するとかも
当該動画の14分あたりに
https://www.youtube.com/watch?v=9H79_kKzmFs&;t=14m12s

おまけとしてビットコインマイニングも
https://www.youtube.com/watch?v=9H79_kKzmFs&;t=23m
http://gigazine.net/news/20170703-xerox-alto-mine-bitcoin/

**デフォルトの名無しさん** · 2017/09/02(土) 14:16:11.69

>>249
20～30年前にはすごいと言われたかもしれないけど、
今だとスマホゲームでさえバージョンアップしていくよ
Googleとかいつメンテナンスしてるんだ？ってレベル。
動かしているシステムの仕様を動的に変更するのは難しいことではない

**デフォルトの名無しさん** · 2017/09/02(土) 14:19:04.95

あとそのデモも良くないね。

「やりたいこと」は何か
「それが実現できるか」であれば

今のWindowsだってプラグイン入れれば
メニューが動的に増えるじゃんっていう話で終わりだから。

**デフォルトの名無しさん** · 2017/09/02(土) 14:25:51.82

> あと昔と今の違いは今は素人が使っているという点があるな。
> 別の言い方をすれば、プログラムを作った人と使う人が違う。

あとこの話。動的に仕様が変わってるのはそのとおりだが、
使ってる人が自分で仕様を変えるのか？って話。

デモはいつだってドヤ顔で ”自分が" 仕様を変えている。
違うんだよ。普通は誰か他の人が変えるんだよ。
そして一人のために作業することはないんだよ。

変えたシステムの配布方法（アップデート方法）が必要になるし、
今変えてますから使わないでくださいなんて言えないし、
変えるタイミングは人それぞれにしたいかもしれないし。
使ってる最中に変わったら困るかもしれないし

で、今はシステムの仕様を動的に変えられるかどうか？ではなくて
変えられるの言うのは当たり前の前提で、それをどうやるかって所に進んでる。
言語？なんだって仕様を動的に変えられるよ。コード修正して再コンパイルすればいいだけ

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

使ってる人がプログラマで自分のために自分が書き換えるなら
「今まさに書き換えていっています！」って状態になるだろうけど、

今まさに書き換えてたりしたら、じゃあテストはどうするんだって話。
普通は書き換えたものをすぐ実用したりしない。

現実には「書き換え後のシステムがすでに用意されています」だからな。
リアルタイムで書き換えることはせずに用意されている。

だから、動的にコードを書き換える機能は実は必須ではなくて
動的にシステムを入れ替える方法があればいい。

それがアプリの再インストールであったり、ネットワーク
越しであればサービスの切り替えだったりする。

**デフォルトの名無しさん** · 2017/09/02(土) 14:38:23.16

シーケンス図みたいにオブジェクトが独立して存在してメッセージをやり取りするってのが本来じゃないの
でも多くの人がここからここを呼び出してこう通ってこっちに戻ってと見てる

いっそ全てのメソッドがブロックしなかったり
オブジェクトがサービスだったらいいんじゃないか

**デフォルトの名無しさん** · 2017/09/02(土) 14:38:32.54

アランケイよりズルムケイなワイの方が頭いいと思うけど何か問題ある？

**デフォルトの名無しさん** · 2017/09/02(土) 14:40:20.62

さっきからダラダラとくっちゃべってるけどランタイムの話じゃねえだろバカ

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

できる・できないの話ではなく必要となる労力の違いの話というのを理解していない
さらに不確実性やunknown unknownsがもたらす影響も理解していない
だから意思決定を遅らせることが出来るメリットについても理解できない

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

結局、早期結合の「神の視点」から離れられないわけで
時間の無駄だと思った

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

部下「Blobの管理どうします？
ファイルシステムかDBかクラウドストレージもありですね。
何を選ぶにせよ顧客との調整が必要なので確定までには時間がかかります。
メッセージ指向的にインフラをインターフェースで隠蔽しておけば今の段階ではとりあえずなんでも良いでしょう。
後で意思決定に合わせて変更できるように作れば安全です。」
x3x「ファイルシステムに決め打ちでハードコードしろ。
俺は賢いから知ってるけどな。
今どきそういうのは言語で対応する必要はないんだ。」
部下「理由を聞いてもよろしいですか」
x3x「今は技術が進歩してるんだ。
システム全体から見ればクラウドとか使って動的に安全に置き換えられるんだよ｡
だから言語での対応は必要ないってわけだ。」ﾄﾞﾔｯ
部下「何を言ってんだこの白痴(意味不明ですが承知しました。責任は取ってくださいよ)」