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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2017/08/08(火) 17:52:14.38ID:4Kd2O+xB
前スレ
オブジェクト指向システムの設計 172
http://mevius.2ch.net/test/read.cgi/tech/1467992113

類似スレ
手続き型システムの設計 1
http://mevius.2ch.net/test/read.cgi/tech/1500282714
192あ
垢版 |
2017/08/20(日) 07:16:27.75ID:mQe7YUF9
>>190
それは、キャンセルボタンが押せるかどうかの判定で、キャンセルができるかどうかの判定と似てるが違うものだよ。
キャンセルボタンではキャンセルできないけど、電話してオペレーターにキャンセルしたい、と頼めばやってくれる、とか。

>>191
そうだな。言葉が悪いか。
状態検証
権限検証
整合性検証
は、すべて「検証」ロジックが呼び出すべき処理、って感じかな。
2017/08/20(日) 08:59:15.38ID:dgrWF/1p
>>192
引っ込みつかなくなったのはもうわかったから
2017/08/20(日) 13:53:16.66ID:m8177A+a
implements ICancelable
でいいだろこれでコンパイルも通る

おまえら、たったこの1行のコードもひねり出せない無能のチンカスガイジ低級プログラマ土方ジャップランド土人だったのか？
2017/08/21(月) 00:11:33.04ID:+nwikK0h
何がええんや
2017/08/21(月) 00:14:41.29ID:+nwikK0h
100歩譲って無能のチンカスガイジは認めるわ
土方プログラマっていうのもまあ分かる
しかしジャップランド土人というのもそのとおりだ
2017/08/21(月) 01:07:09.51ID:7hohe37q
>>192
>すべて「検証」ロジックが呼び出すべき処理、って感じかな。

そのすべてを呼び出す「検証」ロジックって何ぞな？
2017/08/21(月) 03:03:23.75ID:eGD2En39
>>196
認めすぎィ！
199あ
垢版 |
2017/08/21(月) 07:29:55.85ID:H2KMBRSF
>>197
あー、確かに。それは微妙か。
データフローとか、ジョブの検証フェーズになるだろうね。
2017/08/21(月) 19:51:47.16ID:Kzr43Eyo
話は変わるが
私はユーザーオペレーションのミスも例外で処理する(例外シナリオ)
これは一番やりたいことを最も早く簡潔に書くためだ(メインシナリオ)
やりたいことが出来ないのはシステムにとって致命的だが、ミスは回避できる特に開発段階では
ミスかどうか早めに自発的に判断するのはやぶさかではないが、そこでも例外を投げて例外シナリオであることを明示する

システムにとって必要不可避なユースケースを最小で実現するためだ
問題があれば聞かせてほしい
2017/08/21(月) 21:02:35.44ID:TUwJwlJW
>>200
前にそれやったらロジックが複雑になったことある
2017/08/21(月) 21:28:17.07ID:Kzr43Eyo
>>201
うちではロジック変わらない
設計者の技量の問題かな
2017/08/21(月) 21:52:21.63ID:wYi/O97J
>>202
エラーによっては別の方法を促さなきゃいけない仕様になっているのに
まとめて処理しようとしててmain関数がお化けになってた
エラーメッセージってちゃんと表示しようとするとその時の色んなもんが必要になるんだけど
それも上手く引っ張ってやらないといけない
その場でやったほうが楽だったよ
エラーメッセージ用の必要なデータの抽出ってのも結構骨が折れる
しかも頂点でしかやってねーからある時mainが全部using持ってないと動かなくなちゃった
2017/08/21(月) 22:06:44.94ID:Kzr43Eyo
>>203
それは代替シナリオで例外シナリオではない
記述場所の問題なら例外に乗せて投げればいい

そもそもmain関数とかオブジェクト指向じゃないだろそれ
2017/08/21(月) 22:06:53.89ID:lYWr+wd6
もともとプログラムってのは確認して実行しても良さそうなら実行っていう戦略とは根本的に相性が悪い
確実に実行できることを保証するって深く考えると実はかなり難しいのでまず間違いなく何処かで漏れる
どうせ漏れがあるなら最初から確認せずにとりあえず実行してしまえばいい
実行してみて何事もなければそれで良し
ダメなら適切な例外をなげろって設計が実は最も自然な設計
これだけでも完全なシステムを作れる
まあそれだけだとUXが悪いからクライアント側で書式チェックぐらいはしてもバチは当たらんだろうね
2017/08/21(月) 22:19:48.01ID:wYi/O97J
>>204
例外じゃん
少なくとも一瞬は例外だったじゃん
そこから例外→代替シナリオのルートがねーと
コード上では
お前の処理が全部食っちゃってて手の入れようがない
2017/08/21(月) 22:34:43.69ID:Kzr43Eyo
>>206
いや代替シナリオは別途設計書く
コードの例外と例外シナリオは同じではないぞ
2017/08/21(月) 22:39:57.15ID:wYi/O97J
しかも頂点まで戻って来ててしまって

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

プログラム全体で作ったインスタンスを消すともう動かねぇよ
どーすんだコイツ的な衝撃
2017/08/21(月) 22:46:23.39ID:wYi/O97J
>>207
代替があるかどうか？って
ハイ、イイエ
をその処理に対して誰かがちょっとでも浮かぶかどうかじゃん?

ここまとめて例外で弾き飛ばすと
あ、ここは例外でいいよ
メッセージ出して欲しいなぁ
って客の気分やから
融通が効かないクソコードになんで
2017/08/21(月) 22:48:21.65ID:Kzr43Eyo
>>209
何言ってんの
2017/08/21(月) 22:55:05.00ID:wYi/O97J
>>210
(´・ω・`)俺の言ってることあんま理解できない?
2017/08/21(月) 23:04:43.19ID:Kzr43Eyo
誰か通訳
2017/08/21(月) 23:06:06.88ID:wYi/O97J
>>207
サービスで代替？があるやつだけ教えてやったけど
これだけだと思ってるの?
まだまだあるぜ
バーカ
検討を祈る!
2017/08/21(月) 23:16:42.53ID:wYi/O97J
うん、俺がアホだったね
死ぬわ(´・ω・`)
環境特有の状況だね
2017/08/21(月) 23:19:42.56ID:wYi/O97J
そしてすまん(´・ω・`)
2017/08/21(月) 23:22:00.62ID:Kzr43Eyo
代替シナリオと代替サービスを一緒くたにしてるのかな
2017/08/21(月) 23:26:47.25ID:wYi/O97J
>>216
いや酒飲んで寝起き
2017/08/22(火) 06:43:04.83ID:9GD6qpN2
お酒のせいにする男ってサイテー
2017/08/22(火) 07:37:50.45ID:w3Lq2Uzy
まだ夏休みだっけ？
2017/08/22(火) 09:33:05.29ID:NJ87VB64
○次受けが多いほど退場率が早くなる。高くなる

直受けの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.25ID:6/9LzVc0
オブジェクト指向に造詣の深い諸兄は、DTOとかPOCOとか、クラス図に書いてます?
2017/08/23(水) 08:20:46.57ID:kJ94jZYw
>>221
データベースのdtoは書かない
ViewModelは書く
2017/08/24(木) 10:06:58.66ID:hIiCK2jN
>>222
一般的にはそういう認識で良いんですね

プログラムできない上司と二人きりの社内IT便利屋なので世間様の動向が解らず
ありがとうございます
2017/09/02(土) 01:06:47.28ID:je61f8uF
いつの間にかWikipediaのオブジェクト指向のページがいい感じになってるな

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

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

メッセージング指向の何が良いの？
2017/09/02(土) 10:24:51.59ID:O1j4weut
名前がカッコいい
2017/09/02(土) 10:56:48.95ID:x3xo3AHA
メッセージのやり取りが需要！

そいで何が重要なの？


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

で何が重要なの

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


オブジェクト指向という言葉の生みの親であるAlan Kay博士は
名前がまずかったことにこだわり、その中身の重要性を語ることはなかった
2017/09/02(土) 11:23:18.99ID:Z0VXJAOw
メッセージは大事だが本質ではないよ
メッセージ指向が目指したのは「可能な限りの決定の遅延」
設計時、実装時、実行時、運用時（保守、メンテ時を含む）などすべての局面での徹底の試み

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

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

http://metatoys.org/oxymoron/oxymoron.html
2017/09/02(土) 11:48:07.70ID:x3xo3AHA
> メッセージ指向が目指したのは「可能な限りの決定の遅延」

決定の遅延は、問題の先送りと考えればよい。
結局あとから問題が発覚するだけにすぎない。
2017/09/02(土) 11:59:21.35ID:uuiwLM/7
「最適化や解決を急ぎすぎない」といった方が適切かな

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

たとえば参照先の文書をきちんと読まずに反射的にしたレスをうまく取り繕えるようなメタシステム作りを目指すのがメッセージ指向
2017/09/02(土) 12:12:35.31ID:x3xo3AHA
> 対象とするシステムやそこで解決すべき問題についての理解が深まるまで、
それでは、ずっと理解は深まらないのか？って問題が有るな。
例えば一回作ったことがあるシステムならば理解は深まっていると考えられる。
では理解が深まってる状態で、何の決定を遅延させるのか
遅延させることに意味があるのか？


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


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

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

決定の遅延の重要性が理解できないのは、時代にあっていないからに過ぎない。
2017/09/02(土) 12:23:48.00ID:O1j4weut
先送りして後で問題になるではなく
先送りして後で解決してもいいように作る
ってことでしょ
2017/09/02(土) 12:23:51.73ID:x3xo3AHA
容易かつ安全に置き換えられるのはアプリだけで
OSの更新はOSを停止せずにできないように思うかもしれないが。
そこでクラウドというものがでてくる。

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

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

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

すでに現代はシステム全体で見れば、決定の遅延を行っており
容易かつ安全に置き換えられるシステムができあがってる。
それは言語に求めることじゃない
2017/09/02(土) 12:26:11.03ID:O1j4weut
以上
アホの戯言でした
2017/09/02(土) 12:32:31.35ID:x3xo3AHA
反論なし
2017/09/02(土) 12:49:27.80ID:x3xo3AHA
あと昔と今の違いは今は素人が使っているという点があるな。
別の言い方をすれば、プログラムを作った人と使う人が違う。


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

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

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

当時の「容易かつ安全に置き換えられる」っていうのは
停止しないシステム上で人間がトラブルに対処して再開できればいいというレベル
コンピュータを使ってる人＝プログラマ（素人ではない）なので
自分（もしくは担当技術者に依頼）して対応するという前提になってる
2017/09/02(土) 12:51:57.25ID:Z0VXJAOw
完全に早期結合の考え方なんだよね
どこから指摘してよいものかちょっと迷う
2017/09/02(土) 12:53:17.39ID:Z0VXJAOw
とりあえず、参照元読んでもらうことはできる？
それについての疑問に答える方が効率的かなと思う
2017/09/02(土) 12:58:10.04ID:x3xo3AHA
参照元なんて無いから、
俺に反論してくれればそれでいい
2017/09/02(土) 13:00:33.66ID:x3xo3AHA
>>237
今はシステム全体が、物理マシンレベル、仮想マシンレベル、OSレベル、
コンテナレベル、プロセスレベルといった単位で
疎結合になっているから言語自身は早期結合で十分という時代
2017/09/02(土) 13:00:40.57ID:Z0VXJAOw
>>236
当時っていつの話？
参照先読んでもらえばわかるけど、もう君が言うような「今」の当たり前は70年代に出来ていて
その先を目指すにはって話なのだけど…
2017/09/02(土) 13:02:55.05ID:Z0VXJAOw
早期結合でできる部分はそれで済ませればいいと思うよ
2017/09/02(土) 13:05:40.32ID:x3xo3AHA
>>241
> もう君が言うような「今」の当たり前は70年代に出来ていて

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

あんたの言う70年代に出来ていては
原始時代にも石炭はできていて〜っていうのと変わらん。
それをうまく使いこなせるようになったのが今だ
2017/09/02(土) 13:05:45.97ID:Z0VXJAOw
結局、早期結合信奉者の問題は「神の視点」から離れられないことなんだってよくわかる主張だと感じるよ
2017/09/02(土) 13:06:35.50ID:x3xo3AHA
神じゃねーけどなｗ
2017/09/02(土) 13:07:04.78ID:x3xo3AHA
厨二「ふっふっふ、われは神の視点を持つもの」
2017/09/02(土) 13:28:02.93ID:mrBSaSic
>>243
もちろんクラウドなんかはないけど
しかし君が想定しているよりはずっとネット環境は整っていたよ
少なくともアラン・ケイがメッセージ指向を考えたり実験したりしていた場ではね
2017/09/02(土) 13:57:41.57ID:x3xo3AHA
だがそんな彼でも、ネットワークの向こう側のコンピュータを
何台も用意して、接続先を切り替えながら無停止で
システムを運用するという発想は生まれなかったわけで
2017/09/02(土) 14:05:57.73ID:mrBSaSic
たぶん参照リンクを参照することをしない人向けには無用かもしれないけど、いちおうは挙げておくと

たとえばこのリストアされたアルトのデモで当時すでに出来ていたことのその片鱗を見て取れる
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.69ID:x3xo3AHA
>>249
20〜30年前にはすごいと言われたかもしれないけど、
今だとスマホゲームでさえバージョンアップしていくよ
Googleとかいつメンテナンスしてるんだ？ってレベル。
動かしているシステムの仕様を動的に変更するのは難しいことではない
2017/09/02(土) 14:19:04.95ID:x3xo3AHA
あとそのデモも良くないね。

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

今のWindowsだってプラグイン入れれば
メニューが動的に増えるじゃんっていう話で終わりだから。
2017/09/02(土) 14:25:51.82ID:x3xo3AHA
> あと昔と今の違いは今は素人が使っているという点があるな。
> 別の言い方をすれば、プログラムを作った人と使う人が違う。

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

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

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

で、今はシステムの仕様を動的に変えられるかどうか？ではなくて
変えられるの言うのは当たり前の前提で、それをどうやるかって所に進んでる。
言語？なんだって仕様を動的に変えられるよ。コード修正して再コンパイルすればいいだけ
2017/09/02(土) 14:30:22.26ID:x3xo3AHA
使ってる人がプログラマで自分のために自分が書き換えるなら
「今まさに書き換えていっています！」って状態になるだろうけど、

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

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



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

それがアプリの再インストールであったり、ネットワーク
越しであればサービスの切り替えだったりする。
2017/09/02(土) 14:38:23.16ID:CJZVlBwp
シーケンス図みたいにオブジェクトが独立して存在してメッセージをやり取りするってのが本来じゃないの
でも多くの人がここからここを呼び出してこう通ってこっちに戻ってと見てる

いっそ全てのメソッドがブロックしなかったり
オブジェクトがサービスだったらいいんじゃないか
2017/09/02(土) 14:38:32.54ID:HZeOuyve
アランケイよりズルムケイなワイの方が頭いいと思うけど何か問題ある？
2017/09/02(土) 14:40:20.62ID:O1j4weut
さっきからダラダラとくっちゃべってるけどランタイムの話じゃねえだろバカ
2017/09/02(土) 15:14:50.34ID:9PaYDv7F
できる・できないの話ではなく必要となる労力の違いの話というのを理解していない
さらに不確実性やunknown unknownsがもたらす影響も理解していない
だから意思決定を遅らせることが出来るメリットについても理解できない
2017/09/02(土) 15:38:48.98ID:Z0VXJAOw
結局、早期結合の「神の視点」から離れられないわけで
時間の無駄だと思った
2017/09/02(土) 15:42:31.91ID:1DneHKSE
部下「Blobの管理どうします？
ファイルシステムかDBかクラウドストレージもありですね。
何を選ぶにせよ顧客との調整が必要なので確定までには時間がかかります。
メッセージ指向的にインフラをインターフェースで隠蔽しておけば今の段階ではとりあえずなんでも良いでしょう。
後で意思決定に合わせて変更できるように作れば安全です。」
x3x「ファイルシステムに決め打ちでハードコードしろ。
俺は賢いから知ってるけどな。
今どきそういうのは言語で対応する必要はないんだ。」
部下「理由を聞いてもよろしいですか」
x3x「今は技術が進歩してるんだ。
システム全体から見ればクラウドとか使って動的に安全に置き換えられるんだよ｡
だから言語での対応は必要ないってわけだ。」ﾄﾞﾔｯ
部下「何を言ってんだこの白痴(意味不明ですが承知しました。責任は取ってくださいよ)」
2017/09/02(土) 15:54:36.97ID:u30btijY
長文はバカ
2017/09/02(土) 16:00:51.78ID:SLw7DScq
>>259
何か思うところがあるのなら、ごたくを並べるのではなくて、
君がそれを使って素晴らしいOSSを書けばいいだけだよ。

新しもの好きや天の邪鬼は世の中に一定割合でいる。
彼等が特に無能でもない。（有能/無能と性格は相関がほぼ無い）
だから現時点でろくな物がない≒使えない、ってこと。

君が自分ではOSSを書けない程無能なら、
せめてOSSでそのメッセージ指向(ｷﾘｯしてる物を探してくればいい。
使えそうなら、誰かしら試しているはず。
そしてそれが本当に使えるのなら、自然と広まるよ。

大昔からあって、未だに広まってないのなら、ゴミ確定だよ。

それ以前に君はプログラミングしてないだろ。
何故その程度の馬鹿がこの手の議論をしたがるのか俺にはさっぱり分からないが。
> ファイルシステムに決め打ちでハードコードしろ
「ハードコード」の使い方が間違っているし、
それ以前に普通のプログラミングモデルではファイルシステムは隠蔽されてる。
（むしろファイルシステムが直に見える方が珍しい）
> インターフェースで隠蔽
これはOOPで、と言うかそれ以前にAPIで隠蔽されているから、
メッセージ云々関係ないだろ。
2017/09/02(土) 16:04:35.29ID:9PaYDv7F
>>259
早期結合とは関係ないが
これは部下の方にも十分責任があるだろ
聞き方・聞くタイミング・上司の扱い方など
2017/09/02(土) 16:07:22.85ID:1DneHKSE
〜OOSを書けばいいだけだよ〜




ププッ
2017/09/02(土) 16:10:58.33ID:HZeOuyve
ぐたぐた意味不明な長文書くやつって
srcもプェチピィみたいな屁臭いゴミ使ってぐだぐだバグ仕込むんだろうな

な？　（暗黒藁半紙）
2017/09/02(土) 16:32:42.64ID:HZeOuyve
ぐうの根も出ないか（ﾌﾟｰ）
2017/09/02(土) 19:03:41.05ID:x3xo3AHA
自分が理解してないから「どんな問題を解決するか」を語れない。
2017/09/02(土) 19:10:43.53ID:x3xo3AHA
>>259が意味不明すぎてワロタｗ

部下「Blobの管理どうします？ファイルシステムかDBかクラウドストレージもありですね」
上司「とりあえずファイルシステムを使ってあとで修正すればいいよ」
部下「ういっす」

これだけで終わりだろｗ

部下「所で修正はプログラムを実行を停止せずに動的に修正するんですかい？」
上司「普通に停止して再起動すればいいだろ。アクロバティックなことやる必要はない」
部下「ですよねーｗｗｗｗ」
2017/09/02(土) 19:29:52.53ID:0osbGpyr
>>267
ズレてるねえ
論点そこじゃないって半日以上経ってなんで気が付かないの
2017/09/02(土) 19:31:05.43ID:x3xo3AHA
客「開発するシステムは何があってもサービスは許さん！24時間365日何があっても動かし続けろ
バージョンアップの際もサービスは停止せずに行うんだ」

部下「これは言語の選定から始めないといけないですね」
上司「なんで？」
部下「○○言語を使わないと動的に仕様変更できないじゃないですかー」
上司「ん？その言語使えば、それだけでハードウェア障害起きてもサービス停止せずに運用できるの？」

部下「え？故障はハードウェアの責任でしょ。関係ないよ。故障するハードウェアが悪んだ」
上司「馬鹿か、故障するのは大前提だ。その上でシステムを作れって話だ」

部下「そんなの無茶だ！ハードウェアが故障したらプログラムも停止するしか無い！」
上司「一台ならな」

部下「なんだと？」
上司「何台、いや何十台とマシンを用意して一台停止してもサービスを停止しないシステムにするんだ」

部下「そんな非現実的なこと・・・コストが馬鹿にならないじゃないか」
上司「クラウドというものを知らないのかね？ マシンは必要な台数を必要なタイミングで
わずか数分で用意できる。そしてシステムに動的に追加削除が可能。使用している分しかコストはかからない」
部下「そんなことが・・・」

上司「そしてシステムの更新にはローリングアップデートを使用する」
部下「なんだそれは？」

上司「多数のマシンを動的に追加削除できる仕組みを利用して、一台ずつ段階的に
アップデートを行う。サービスの停止することなく、部分的に更新していくことが可能」
部下「そんなことが実現できるのか・・・」

上司「さて言語はどうするかね？ サービスを停止せずに仕様変更はもちろんのこと
マシンの動的な追加削除、再起動だって可能だが？ 」
部下「くっ、再起動できるなら、言語にこだわる理由がない。それがクラウドってやつの力なのか・・・」
2017/09/02(土) 19:31:55.73ID:x3xo3AHA
>>268
> 論点そこじゃないって半日以上経ってなんで気が付かないの

だから論点を明確にしろって言ってんの。
それが言えないのはあんたに「解決できる問題」が見えてない証拠
2017/09/02(土) 19:35:12.81ID:SvMhViqK
あの人の気配を感じる
いやこいつはもっと馬鹿か
2017/09/02(土) 19:36:47.91ID:x3xo3AHA
解決できる問題として、動的に仕様を変更できるというが、
言語のレベルで動的に仕様したいなんて誰も思ってないんだわ
仕様の変更は再起動すれば反映できるんだから
2017/09/02(土) 19:43:45.75ID:SvMhViqK
仕様は静的に変更すんだよ
変更を局所的にして他の部分を保護するためにオブジェクト指向だのメッセージ指向だのを使おうぜというだけの話
動的にデプロイできるなんてのはそれのただの副産物であって今はお前以外は誰も論点にしてないの
2017/09/02(土) 19:46:47.41ID:x3xo3AHA
> 変更を局所的にして他の部分を保護するためにオブジェクト指向だのメッセージ指向だのを使おうぜというだけの話

その部分を今はネットワーク通信でやろうぜって事になってる。
システム全体がオブジェクト指向になったと言えば理解できるか？

「変更を局所的」＝マシン単位 に時代は変わったんだよ。
2017/09/02(土) 19:49:03.82ID:x3xo3AHA
あ、もちろんマシン単位といっても物理マシン単位という意味じゃなくて
仮想マシン単位だったりコンテナ単位だったりするからな。

変更が局所的にすんでるだろう？ｗ
2017/09/02(土) 19:53:58.37ID:x3xo3AHA
それに動的に仕様変更できたとしても突発的なハードウェア障害には対応できない。

それは別の話だと思うかもしれないが、仕様変更であれば別に動的に
やる必要はなく再起動すれば十分。再起動が許されないから動的に仕様変更するのが
要件になっているのだと思うが、再起動が許されないようなシステムは
どちらにしろハードウェア障害にも対応できるのが要件の一つとなるはず。

ハードウェア障害にも耐えられるようなシステムにすると副次的に
動的な仕様変更にも対応できるようになるんだよ。
言語レベルでやることじゃない。
2017/09/02(土) 19:54:58.55ID:x3xo3AHA
で、それ以外に論点が有るというのなら
「解決できる問題」とやらを明確に書けって話
2017/09/02(土) 20:01:06.49ID:mrBSaSic
設計、実装、運用を対象に「メッセージ」を方便に「決定の遅延」を徹底するアイデアがありました
仕様策定、言語、マシン単位で今では当たり前の考え方として普及しました
めでたしめでたし　でいい話をなにを長々と
2017/09/02(土) 20:03:11.91ID:x3xo3AHA
>>278
たぶんその結果、アプリを起動したまま
デバッガなどで動的に変更できることの意味が
なくなったかのようにみえるのが悔しいんだと思うｗ
2017/09/02(土) 20:05:24.10ID:mrBSaSic
>>276
なんで「決定の遅延」が可能とする例のひとつに挙がっただけの動的な仕様変更にそこまで拘るのか謎
コンプレックスでもあるのか？
2017/09/02(土) 20:10:44.54ID:x3xo3AHA
>>280
だから、それ以外の「解決できる問題」がでてないから。
例が一つしか出てないんだから、それにこだわるしか無いわなｗ

さっさと他の例だせよ
2017/09/02(土) 20:14:14.69ID:je61f8uF
なんとな
頭の悪いID:x3xo3AHAがキチガイみたいに26もレスしてすっかり流れてしまったが
メッセージングとは「手続き」のこと
相互作用とは「手続き」のこと

それから>>254の考え方
> いっそ全てのメソッドがブロックしなかったり
> オブジェクトがサービスだったらいいんじゃないか
は非常にまずい、うまくない
オブジェクトを沢山作ったらなんか勝手に互いにコミュニケーション初めて
結果、自分の求めていた機能が得られました！
はマズい、そんな遠回りなことしたいやつはいない
俺らは生態系のシミュレーションプログラムを書いているわけじゃないし
シミュレーションの結果として目的が達成される、とはしたくない
あくまでオブジェクトは道具であり、こちらが主導権をもって手続きから制御して使う
そのためにも手続きが簡潔、何がどの順番で実行されるか一目瞭然に
なるよう念頭に置いて、逆算してクラスを設計する
2017/09/02(土) 20:15:21.59ID:x3xo3AHA
つーか>>259のアホらしいネタにつきあれば

「決定の遅延」だけなら、あとで
ソースコード修正すればすむだけの話なんだよ。
難しいことはにもない。どんな方法でも実現できる

>>267で書いたようにこの方法でも「決定の遅延」ｗ行ってる。

> 部下「Blobの管理どうします？ファイルシステムかDBかクラウドストレージもありですね」
> 上司「とりあえずファイルシステムを使ってあとで修正すればいいよ」
> 部下「ういっす」



だからあんたの言う「決定の遅延」は本質ではないってことなんだよ。
そこに隠された本当の条件があるだろ？
2017/09/02(土) 20:22:33.54ID:mrBSaSic
>>281
> だから、それ以外の「解決できる問題」がでてない

だから http://metatoys.org/oxymoron/oxymoron.html を一度読めよと何度いったら…
2017/09/02(土) 20:23:23.96ID:je61f8uF
>>254のような変なことを考えてしまうやつが出てくるのが
オブジェクト指向という名前のまずさだろうな
もしメッセージング指向って名前ならこんな勘違いするはずなかった
メッセージング指向とは：
メッセージのやり取りを実行順に順番に並べて定義する(←プログラム、手続き)ことで
プログラミングする方式
っていう感じの定義になってただろうからな
2017/09/02(土) 20:24:40.70ID:x3xo3AHA
>>284
よんだ。書いてない。以上
2017/09/02(土) 20:24:49.03ID:je61f8uF
Smalltalkerまで暴れてるのか
2017/09/02(土) 20:29:11.30ID:x3xo3AHA
>>285
メッセージング指向言語なら、勘違いしたかもしれないが、
メッセージング指向システムなら、勘違いしなかったかもねｗ

「システム」であれば単一の言語でやることじゃなくて
どんな言語であるかは関係なく、システムを小さなプロセスに分離して
そのプロセス間通信（ネットワーク通信）でシステムを構成するという
言語にとらわれない発想につながる

ようは「オブジェクト指向言語」や「メッセージング指向言語」の
「オブジェクト指向」や「メッセージング指向」部分が勘違いの原因ではなく
そのあとにくっつけてる「言語」が勘違いの原因だよ。


「決定の遅延」とやらは言語レベルでやることじゃぁないって話
2017/09/02(土) 20:31:23.03ID:x3xo3AHA
あ、もちろん

> 「決定の遅延」とやらは言語レベルでやることじゃぁないって話

は、今だから言えること。

昔のOSがなくて、言語環境がOSそのものである時代に
そんな発想ができなかったのは仕方ない話。
2017/09/02(土) 20:31:32.64ID:SvMhViqK
素直にNGが正解だったか
このスレではよくあることだが
キチガイを隔離できないと議論の場にもならないな
2017/09/02(土) 20:35:08.35ID:x3xo3AHA
いや反論もなくて、ただ単に書き込み数が多いだけで
キチガイと判断されても困るんですけどーｗ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況