オブジェクト指向システムの設計 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

◆taZqHR8ods · 2017/09/02(土) 21:35:06.66

>>323
> お前は反論を受けて反論し返す労力がなくなって楽になるだろ
いや、別に？

なんのために匿名掲示板に
書き込んでると思ってるんだｗ

◆xKvzozvsSk · 2017/09/02(土) 21:35:24.99

>>324
ハゲじゃねーよｗ

◆bb6OCCHf8E · 2017/09/02(土) 21:35:54.30

よし。あそんだからまたIP変えるわｗ

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

固定ハンドルネームの意味も知らないのか

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

固定ハンドルネームの意味は少なくとも
NGにしたい人に対してお願いして
付けてもらうものじゃなかったと思うが

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

>>329
>>292 って言ってるから協力してくれると思ってたわ

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

>>330
NGならIDでできるだろ？
それなら俺には手間はかからない
やるなら今ある情報で勝手にやってくれって話
俺は自由にやりたいようにやる

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

>>331
おまえ自身が実践してるようにIDは変化するんだよ

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

「あ」はその点、潔かったな
それと比べてこいつは言うことも馬鹿馬鹿しいが性格が姑息だ

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

>>332
変化しても見つけたらそばから
NGすりゃいいだけじゃん？
レスするぐらならNGにすればいい

**デフォルトの名無しさん** · 2017/09/03(日) 02:48:19.90

>>282
まったく読めてないな
誰がうまく行くなんて言ってるんだ

お前のやりたいことは上から下に流れる行番号プログラムが一番お似合いなんじゃないか?

**デフォルトの名無しさん** · 2017/09/03(日) 07:34:16.18

未だにコテハンに拘るやつって・・・
何歳？ガイジ？痴呆老人？

**デフォルトの名無しさん** · 2017/09/06(水) 01:04:35.69

>>334
エンジニアの才能ゼロ臭がすごい

**デフォルトの名無しさん** · 2017/09/06(水) 07:52:17.25

日本人エンジニアとしては優秀
何度でもリピートユアセルフが日本人エンジニアの信念だからね

**デフォルトの名無しさん** · 2017/09/12(火) 17:44:55.65

オブジェクト思考の設計とRDBMSの理論って
多分似たような考え方が多いんと思うんだけど、
それぞれ別々の用語で語られるから整合性をとるのが
大変。

**デフォルトの名無しさん** · 2017/09/13(水) 20:51:27.10

>>339
>> 多分似たような考え方が多いんと思うんだけど、
似たような考え方はない

>>それぞれ別々の用語で語られるから整合性をとるのが大変。
お前のアタマの出来の問題

**デフォルトの名無しさん** · 2017/09/14(木) 00:12:12.72

インピーダンスミスマッチを知らないのかな

**デフォルトの名無しさん** · 2017/09/14(木) 07:00:44.26

久しぶりにスレ読んだが

>>224
＞何がどの順で実行されているか明瞭
それは手続き型の逐次性であって
アランケイの言うメッセージングとは関係ない

>>228
＞メッセージ指向が目指したのは
＞「可能な限りの決定の遅延」
こっちの方が元祖に忠実な解釈

**デフォルトの名無しさん** · 2017/09/14(木) 07:09:15.99

>>282
＞メッセージングとは「手続き」のこと
＞相互作用とは「手続き」のこと
違う

＞何がどの順番で実行されるか一目瞭然に
＞なるよう念頭に置いて、逆算してクラスを設計する
それはオブジェクト指向設計ではない

**デフォルトの名無しさん** · 2017/09/14(木) 07:11:37.80

>>285
＞メッセージング指向とは：
＞メッセージのやり取りを実行順に順番に並べて
＞定義する(←プログラム、手続き)ことでプログラミングする方式
違う

むしろ手続き型の逐次性に縛られない
実行時に自由な順序で処理できる
のがメッセージング指向

**デフォルトの名無しさん** · 2017/09/14(木) 07:45:55.41

実装は関数型か手続き
パッケージングはオブジェクト指向
システム相互作用はメッセージ指向

今のところこれが最も楽だね
システムの隅々までオブジェクト指向に執着する意味はない

**デフォルトの名無しさん** · 2017/09/14(木) 11:18:13.19

>>342
アランケイの言うことなどあてにならないから
斜めからとらえてるんだよ
オブジェクトの外が重要→相互作用の手続きが重要
という風に

**デフォルトの名無しさん** · 2017/09/14(木) 19:22:14.60

お前の妄想とアランケイの発想とどっちがあてになるかっていったらアランケイだろｊｋ

**デフォルトの名無しさん** · 2017/09/14(木) 21:37:51.92

ニシコリケイって最近見ないね

**デフォルトの名無しさん** · 2017/09/15(金) 05:53:41.36

>>344
アクターじゃんそれ

**デフォルトの名無しさん** · 2017/09/15(金) 05:55:07.30

>>347
そうそう
オブジェクト指向の元祖だからね

別に盲信する必要もないが
このスレの批判は単に的外れだな

**デフォルトの名無しさん** · 2017/09/15(金) 05:56:09.92

>>349
アクターモデルとメッセージモデルは近い
というか影響を受けたものだから
別に似ててもおかしくないよ

**デフォルトの名無しさん** · 2017/09/15(金) 07:15:17.35

カール・ヒューイットのアクター理論はアラン・ケイのSmalltalk-72の方便・お題目であった「メッセージ」を
問題領域を並列処理に限定して真面目に定式化し実装（PLANNERの拡張）を試したものだよ
ケイも後出しでアルトにもっとマシンパワーがあれば似たようなこと（ただし定式化には興味がなく実装の方）は考えてた
みたいなことは言ってる

**デフォルトの名無しさん** · 2017/09/15(金) 08:28:38.45

つまりアクターじゃん

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

オブジェクト指向とアクターを分けましょう

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

アランケイはつまりアクターじゃん

**デフォルトの名無しさん** · 2017/09/15(金) 08:31:05.96

オブジェクト指向 vs. アクターじゃん

**デフォルトの名無しさん** · 2017/09/15(金) 08:37:46.12

まとめて言え

**デフォルトの名無しさん** · 2017/09/15(金) 08:45:57.26

アクターモデルほど並列化しなくても
OOには手続き的な逐次に囚われない要素がある

IF文と違って継承や多態したメソッドは
コード記述の順番通りでなく
クラス階層に基づいて呼ばれるし

**デフォルトの名無しさん** · 2017/09/15(金) 09:11:38.66

>>357
まとめるとそれってつまりアクターじゃん！！

**デフォルトの名無しさん** · 2017/09/15(金) 09:12:37.96

>>358
それってつまりこじつけじゃん！！！

**デフォルトの名無しさん** · 2017/09/15(金) 09:13:14.62

じゃんメソッドで理解するオブジェクト指向

**デフォルトの名無しさん** · 2017/09/15(金) 09:41:31.46

>>358
こんなふうにメッセージングやその先の遅延結合を実装や実行中のことだけに限定しがちだから
「決定の遅延」って言い換えた方がいいって>>228で書いてるとおりの展開だな

「決定の遅延」にフォーカスできていれば、ケイのメッセージ指向はアクター理論と
そもそも問題領域が違うんだから混同しようがないよ

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

決定の遅延ってなんスカ？ haskellっすか

**デフォルトの名無しさん** · 2017/09/15(金) 13:10:39.74

神のごとき傲慢さで何でも事前に決めてしまわないことだよ
OSや言語処理系はもちろん、成果物にすらそうした態度をサポートするしくみが期待される
というのがケイのメッセージ指向のオブジェクト指向のキモ

**デフォルトの名無しさん** · 2017/09/15(金) 13:27:50.13

モンキーパッチでベタベタ
後付け修正をかけてイミフにすることだよ

**デフォルトの名無しさん** · 2017/09/15(金) 15:34:39.82

ちょっと何言ってんの

**デフォルトの名無しさん** · 2017/09/15(金) 15:45:11.93

違うよ
モンキーパッチのような姑息な手を使うような局面の話ではなく、もっと根本的な問題も後から変えられるように
作る 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?
　クラスベースよりプロトタイプベースの方が使いやすいと判断したら、途中から移行できるか？

**デフォルトの名無しさん** · 2017/09/15(金) 15:53:13.42

>>367
いかん　×インスタンス変数　○インスタンス（＝オブジェクト）

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

>>367は素晴らしい
これ読んだら、意味ない、必要とされてない、ってことが良くわかって良いでしょ
世迷言の類だよ

**デフォルトの名無しさん** · 2017/09/15(金) 18:28:53.55

GoFのデザパタってもう古いの?
今は何

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

-デザインパターンとともに学ぶ-
オブジェクト指向のこころ

**デフォルトの名無しさん** · 2017/09/15(金) 20:03:02.40

-デザインパターンとともに滅ぶ-
オブジェクト指向のこころ

**358** · 2017/09/15(金) 21:17:07.69

>>362
>>358は
＞実装や実行中のことだけに限定
したつもりはないが

そこまでの流れで
アクターとの違いが疑問になってたから
典型的なOOの挙動を例に挙げたんだよ

**デフォルトの名無しさん** · 2017/09/15(金) 21:20:32.74

>>370
デザパタは古くないよ

たとえばイテレータが標準で使えるとか
新しい言語が直接サポートするようになったから
自力で実装する必要がない場合も増えたけど
アルゴリズムと同じで知ってて損はない

ただたんにOOの新しい流行って意味なら
今はDDDとか

**デフォルトの名無しさん** · 2017/09/15(金) 21:27:52.24

DDDはもう古い
当たり前のように使われる枯れたデザパタと似たようなポジション
逆に言うと使いこなせていない場合は初心者の烙印を押される

**デフォルトの名無しさん** · 2017/09/15(金) 21:28:48.44

DDDはオブジェクト指向もレイヤーが上
関数型のほうが相性がいい面もある

**デフォルトの名無しさん** · 2017/09/15(金) 22:32:03.57

みんなすごいなぁ..

**デフォルトの名無しさん** · 2017/09/15(金) 22:40:52.52

DDDのサービスとDCIのコンテキストの違いを語れるくらいにはなりたい

**デフォルトの名無しさん** · 2017/09/15(金) 23:00:39.95

アホ草
所詮は構造体に毛の生えたもんだろ

**デフォルトの名無しさん** · 2017/09/15(金) 23:02:02.51

毛の大切さはそれを失なった者にしか分かるまい

**デフォルトの名無しさん** · 2017/09/15(金) 23:03:27.14

深い

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

薄い

**デフォルトの名無しさん** · 2017/09/16(土) 10:22:39.13

>>375
ＤＤＤ古いなら今は何?

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

> モンキーパッチのような姑息な手を使うような局面の話ではなく、もっと根本的な問題も後から変えられるように
> 作る and/or それを言語処理系・OS等にサポートさせよう　という話だよ

つまりアプリケーションの再インストール
ただしOSは再起動しないことが条件
それってWindowsは実現できてるじゃん？

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

やっぱMSの技術は最先端行ってるんだな

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

もしかしたらOSの再起動をしても良いかもしれないな。
根本的な問題を変える時、OSを再インストールすることで実現できる。

きっとそれは違う！というのだろうけど、
それって「根本的な問題を後から変えられる」が本当に求めているものではなくて
「システムの停止時間がほぼ0に近いこと」が本当に求めているものではないのかね？

**デフォルトの名無しさん** · 2017/09/16(土) 11:21:50.01

>>384
アルトで動いていた暫定ダイナブック環境から40余年
https://upload.wikimedia.org/wikipedia/commons/9/91/Smalltalk-76.png
そこらのパソコンもだいぶケイの考えるオブジェクト指向（メッセージ指向）をサポートできるようになったってことか
できたらアップデートするアプリケーションも再起動しないで済む仕組みだとなおいいね

**デフォルトの名無しさん** · 2017/09/16(土) 11:35:51.04

>>387
> できたらアップデートするアプリケーションも再起動しないで済む仕組みだとなおいいね
結局それはトレードオフの問題だからね。

アプリを修正したら即反映できるかっていったらそうとは限らない。
メモリ内のデータ構造の変更が必要になることが有る。

だから単純にオブジェクトを入れ替えるだけではなく
データ構造的に互換性がある形にするか
新旧両方のデータ構造に対応させるか
データ構造の変換機能（マイグレーション）が必要になる。

で、それが面倒だから本当に永続化しなければいけないものを限定して保存することで
再起動してそれ以外の重要ではない部分を破棄させる。

だからOSや言語だけで対応できることじゃないんだよ。
今でもやろうと思えばできるが、コストがかかるからやらないってこと

**デフォルトの名無しさん** · 2017/09/16(土) 11:40:49.19

またオブジェクトの入れ替え（コードの修正）と言っても
通常は一箇所だけやればいいってもんじゃないからね。

ある機能を実現するために、複数のオブジェクトを修正しなければいけない
それを一括で適用する方法はないだろう？

だからアクロバティックなことをしなければいけなくなる。
つまりコードを修正しても、無効フラグなどで新しいコードが
使われないようにして、互換性を保ちながらコードを修正していって
あるとき一気に切り替え。そして徐々に古いコードを削除していく。

ってなことをやるぐらいなら、夜間にバージョンアップのメンテで
数時間停止します。の方がマシだったりする。
もちろん無停止システムもあるだろう。その場合は
サーバー複数用意して切り替えるとかね

結局はコストと時間を無制限に使えるというのであれば
アランケイの理想は実現できますよ（＝不可能という意味）という話でしか無い

**デフォルトの名無しさん** · 2017/09/16(土) 11:56:37.56

サービスの利用が中断されないならアプリケーションを再起動したって何の問題もない。アップデートされるアプリケーション自体にその機能を持たせる価値がどれ程あるのか？

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

>>388
> メモリ内のデータ構造の変更が必要

まあそれを必要としないのがケイの主張する「決定の遅延」の徹底（と言語やOSによるサポート）のミソなわけなんだが
長々と書いている内容を読んだかんじ、まったくイメージがつかめてないんだろうな…

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

>>391
いや「ミソ」とか言ってごまかすなよ。
今度はお前が説明する番だろ
（やっぱり理解してないのかな？）

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

変更するのはデータ構造だけじゃなくて
データの意味が変わったりもするからね。
そういう場合に変更機能はどうしても避けられない

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

>>387
Mac OSの原型か

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

OSの定期的な再起動は
現実的に仕様がないと思うけどね
現代のOSは複雑だから

Smalltalkの遅延結合の思想は
理論的には良いけど
現段階で本当に実現できるかは不明

Smalltalkで動かしながらデバッグできるっていうのと
現代のOSとではシステムの複雑さが違い過ぎるから
再起動は必要ない代わりに不具合が出たりするかもしれない

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

>>392
イメージできてない人に説明するのはかなり難しいよ
まして当事者の協力が望めないこの状況ではほぼ不可能だと思う

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

>>396
じゃあイメージしている人に対して説明すればいいだろ？
お前が説明しないのが問題だって言ってるんだから

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

前から疑問だったんだけど「あらゆる意思決定の遅延」の話がなんで「無停止デプロイ」の話にすり替わってんの？
全く別の話だよねこれって

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

>>395
> 現代のOSは複雑だから
結局そこなんだよな

システムが巨大でインターネットを介して世界中にの複数台の
サーバーで一つのシステムを構成してるっていうのは
昔の一台の構成のコンピュータでアプリを動かすのとは訳が違う

せめて遅延結合とかメッセージとかじゃなくて、
処理の非同期実行と呼んでいれば、ウェブサービス＝クラス
サービスを実行してる仮想マシン＝インスタンスと無理やり
結びつけることも出来たかもしれないね。言葉は重要だｗ

でも非同期実行だと、サーバーが再起動したとしても最終的に処理できればいいわけで
アランケイが本当に目指していたことである、プロセスを再起動せずに更新反映は
必要ないってことになっちゃうかｗ

まあすべてを非同期にする必要はないだろうけど、要所要所で
非同期で処理しておけば、システムの更新もしやすくなるんやで

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

>>398
> 全く別の話だよねこれって
結局のところ、意思決定の遅延が何をもたらすのかを
説明できてないのが原因だろうねｗ

あらゆる意思決定の遅延
→それがあると何ができるか？
→プロセスを停止せずに変更が可能（ここが一番重要）
→停止して変更すればよくね？（これにうまく反論ができない）
→停止するとつかえなくなる時間がー　（苦し紛れの理由）
→それらはデプロイ技術で解決できること

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

>>400
アラン・ケイの主張なんだからとりあえず彼が書いたこれを読もうよ
http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeringAnOxymoron.pdf
それから解らないことを具体的に訊いてけばいいと思うよ

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

>>401
読んだ。で？

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

わからないことは何も無いが、俺が勘違いしている可能性はある。
だが勘違いしている俺には、その事実がわかるはずもない。

だから他人から見て間違っているというのであれば
それを説明しろって言ってるだけなんですがーｗ

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

>>400
→それがあると何ができるのか
→プロセス停止しないで変更可能(ここは全然重要じゃない。無停止デプロイは副次的な効果のうちの1つでしかない)

正しくはこうだろう
ここから間違えてるから議論が明後日の方向に突き進んでる

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

いや、だから副次的な効果ではなくそれ以外の真の効果（なにそれ？）が
言えないのが問題だって言ってるんだが。

間違ってる場所を指摘するだけじゃなくて正しい効果とやらを言えよ
だからいつもデプロイ技術で解決できちまうんだよ。

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

ちなみにさっきも言っているが「変更」自体はプロセスを停止して
リセットすることで、行うことができる。

そのリセットにかかる時間はデプロイ技術で短くなってきており
リセットしないまま慎重に時間をかけて変更するよりも、
変更してリセットしてセーブポイントから再開した方が早い

アランケイはリセットしたほうが早いというのを
計算に入れることができなかったんだろうね

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

正しい効果なんてとっくに明確になってるだろ「意思決定を遅延させることができる」
そのまんまだよ

データベーススキーマが完成するまでアプリケーションの開発チームは何もせず待機するのか？
そうじゃないだろう
普通はモックやスタブを使ってアプリケーションを開発する
これはデータベーススキーマに関する意思決定を遅延したということだ

そしてこういった意思決定の遅延を普遍的なモデルとして再考してあらゆる問題に適用しようぜというのがメッセージ指向の本質
無停止デプロイの話なんてどこにも出てこないんだよ
無停止デプロイはメッセージ指向を応用すれば簡単に実現できるね程度の枝葉の話だ

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

「意思決定を遅延させることができる」
→それがあると何ができるか？
→プロセスを停止せずに変更が可能（ここが一番重要）

ほらまた同じ流れｗ

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

>>407
> データベーススキーマが完成するまでアプリケーションの開発チームは何もせず待機するのか？
> そうじゃないだろう
> 普通はモックやスタブを使ってアプリケーションを開発する
> これはデータベーススキーマに関する意思決定を遅延したということだ

データベーススキーマに関する "本物の実装" を遅延させただけ
データベーススキーマに関する "意思決定はなされた" からこそ
モックやスタブという "偽物の実装" を遅延させずに早期に開発することが可能なった

これが正しい解釈だからねｗ

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

> 無停止デプロイの話なんてどこにも出てこないんだよ

それがでてくるんだよなぁ。
停止して良いのならば、静的型付け言語でコンパイルして完全に型が
決定していようとも、再コンパイルすることで変更することができる。
停止していいならばね。

だからプロセスを停止するかしないかだけが焦点となってしまう。

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

世界改変のためには一度世界を滅ぼす必要があるのか！

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

安心しろ。世界を滅ぼさなくても一部だけを修正すればいいだけだ。

そしてソフトウェアは世界じゃない。
止めてリセットして同じところまで再開することが可能なのに、
わざわざ止めずに修正する必要なんて無いんだよ。

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

だめだこりゃ
話を聞かない人間に物事を理解させることほど難しいことはない

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

そりゃお前が「物事を他人に理解させるための説明」を
何一つしないからだな。

「話を聞かない」の前に、お前の話はどれだよ？ちゃんと反論してるだろ
その俺の反論した話を聞かないのはお前だろ

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

この議論はID:FAEJW2nXのほうがまともだね。

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

優越コンプレックス餓ひどい奴がいるな
かわいそうに

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

一応>>416は俺ではないことを示しておこう

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

>>407
意思決定が遅延できることには価値があるけど、それにはトレードオフが伴う
それを理解せずに普遍的なモデルとしてあらゆる問題に適用しようぜって言ってるうちは
世迷いごとと言われて当然

まずアラン・ケイの主張に対して自分たちのスタンスを明確にしたら？
困ったら「アラン・ケイの主張なんだから」じゃ議論にならんよね

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

もう一つ言っとくと無停止デプロイの類は
入れ替え可能なコンポーネントについて事前に意思決定してるからできる事なんだよ
遅延可能な意思決定の範囲ついて事前に意思決定をしてる

アラン・ケイがトレードオフについて理解できてないとは俺は思わないけどね

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

全てがオブジェクトが入れ替え可能というふうに
事前に意思決定をしているアラン系（笑）

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

開発プロセスを止めて意思決定を待つ必要が無いってことなら大きいな

運用中のシステムを一時停止する話とは全然違う

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

自分だけは常に正しいという前提

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

>>421
もう一回言っておくね。
例えばC言語で、完成してないモジュールを勝手に定義して
自分の担当のモジュールを作ることは出来ます。

止めれば良いのだから、モジュールが完成してから
再コンパイルして変更することも出来ます。

これがあなたが言ってる「意思決定を待つ必要がない」と
いうことそのものです。

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

これからは開発プロセスを止めて意思決定を待つ必要が無いという開発を
>423のことと定義しましょう。実際その通りなのですからね。