OOPと手続き型プログラミングの比較 - ページ 26 1...192021222324252627282930313233...48 新しいコメント Georgiy Merts 2017.08.14 17:37 #251 考えることはあまりないんです。OOPは、多くのチェックと承認をコンパイラに渡すことができる仕組みです。しかし、それを利用するためには、多少の手間をかける必要があります。 しかし、そうしたチェックやフィットが必要ないのであれば、OOPを使う意味はありません。 例えば、グラフィカルカーネルの多次元配列 は、今必要でないエンティティが多すぎるため、私は警戒しています。それらは気が散って、計算しにくいエラーを誘発する。それをオブジェクトの集合に置き換え、シンプルでコンパクトなインターフェースでアクセスできるようにします。インターフェースを手に入れることで、私は何も覚える必要がありません。インターフェース自体が私を制限し、例えば間違ったフィールドやオブジェクトにアクセスすることを防いでくれるのです。グラフィカルなカーネル配列の場合、そのような処理は非常に可能である。 つまり、ブロックがインターフェースを受け取る場合、コンパイラ自身が不要なエンティティを「切り捨てる」ことで、ユーザーのミスを防いでいるのである。しかし、グラフィカルなカーネル配列の場合、ユーザーには不要な情報が多く、間違えやすい。 私の経験では、コンパイラ自身が、現在のブロックの中で行ってはいけないところに行かないように見守ってくれている方が、ずっと良いということがわかっています。しかも、グラフィカルなカーネル配列で......覚えなきゃいけないですね。私のシステムのマイナスは、プラスの延長線上にあるのです。あるブロックの中で、今のタスク以上のものが急に必要になったとき、グラフィカルカーネルアレイがあれば簡単です。必要なデータを取ってきて、それを使って作業するだけです。しかし、OOPインターフェースでは、必要なデータを追加のインターフェースで要求するか、（もっと嫌なことだが）既存のインターフェースを変更する必要がある。 Nikolai Semko 2017.08.14 18:10 #252 George Merts:考えることはあまりないんです。OOPは、多くのチェックと承認をコンパイラに渡すことができる仕組みです。しかし、それを利用するためには、多少の手間をかける必要があります。 しかし、こうしたチェックやフィットが必要ないのであれば、OOPの意味がありません。しかし、なぜそこまで簡略化するのでしょうか。また、わかりやすさや読みやすさについてはどうでしょうか。そして、エラー検出と訂正の簡便さ？ポータビリティは？そして、アップグレードのしやすさは？ などなど・・・。 Реter Konow 2017.08.14 18:28 #253 Nikolai Semko: それなら、テーマも違って聞こえるはずだ。プログラミングの新しいツールキット」とか「新しいプログラミングパラダイム」とか......。 OOPよりかっこいいものを作ったというのが本当なら、有名になったら自分のものにサインをしてくれるのでしょうか？問題なし!お友達へのサインも惜しみません ))))冗談でしょうけど、想像では、このやり方は本末転倒だというくらいの見通しを持っています。時間が経てば、システムの自己改良の仕組みができそうです。論理カーネルを作って、いろいろな仕組みをランダムに生成させたら。あとは選別をして、適切なものを選べばいい。そして、少しづつすり潰していく...。カーネルのおかげで、信じられないようなことができるんです。 Maxim Kuznetsov 2017.08.14 18:31 #254 Nikolai Semko: なぜ、そこまで物事を単純化するのか。そして、わかりやすさ、読みやすさは？そして、エラー検出と訂正の容易さ？ポータビリティについてはどうでしょうか？そして、アップグレードのしやすさは？ などなど・・・。ナイスバナー広告 :-)"我々の象を買え" これらの論文は、OOPでも非OOPでも、FPでもどこでも同じように適用できる。 Реter Konow 2017.08.14 18:41 #255 George Merts:考えることはあまりないんです。OOPは、多くのチェックと承認をコンパイラに渡すことができる仕組みです。しかし、それを利用するためには、多少の手間をかける必要があります。 しかし、そうしたチェックやフィットが必要ないのであれば、OOPを使う意味はありません。 例えば、グラフィカルカーネルの多次元配列 は、今必要でないエンティティが多すぎるため、私は警戒しています。それらは気が散って、計算しにくいエラーを誘発する。それをオブジェクトの集合に置き換え、シンプルでコンパクトなインターフェースでアクセスできるようにします。インターフェースを手に入れることで、私は何も覚える必要がありません。インターフェース自体が私を制限し、例えば間違ったフィールドやオブジェクトにアクセスすることを防いでくれるのです。グラフィカルなカーネル配列の場合、そのような処理は非常に可能である。 つまり、ブロックがインターフェースを受け取る場合、コンパイラ自身が不要なエンティティを「切り捨てる」ことで、ユーザーのミスを防いでいるのである。しかし、グラフィカルなカーネル配列の場合、ユーザーには不要な情報が多く、間違えやすい。 私の経験では、コンパイラが現在のブロックの中でやってはいけないことを追跡してくれる方がずっといいんです。しかも、グラフィカルなカーネル配列で......覚えなきゃいけないですね。私のシステムのマイナスは、プラスの延長線上にあるのです。あるブロックの中で、今のタスク以上のものが急に必要になったとき、グラフィカルカーネルアレイがあれば簡単です。必要なデータを取ってきて、それを使って作業するだけです。しかし、OOPインターフェースでは、必要なデータを追加のインターフェースで要求するか、（もっと嫌なことだが）既存のインターフェースを変更する必要がある。 カーネルが冗長だと思うのは間違いです。そして、その実体は、定義によって人間の言葉をまとっているので、とても覚えやすいのです。そこにはあらゆるものが集められているが、このコンテンツには明確で不変の秩序がある。オブジェクト、ウィンドウ、エレメントのプロパティは、プログラムのどの時点でも直接アクセスすることができます。そして、カーネルのループでどんな不思議なことができるのか...。 Georgiy Merts 2017.08.14 19:44 #256 Реter Konow: カーネルに余計なものが入っていると思うのは全くの間違いです。そして、その実体を記憶することは、定義によって人間の言葉をまとっているため、とても簡単です。そこにはあらゆるものが集められているが、このコンテンツには明確で不変の秩序がある。オブジェクト、ウィンドウ、エレメントのプロパティは、プログラムのどの時点でも直接アクセスすることができます。そして、カーネルをループさせることで、どんな不思議なことができるのか...。私は「カーネルが冗長」とは言っていません。「現時点では不要」と言ったのです。グラフの線を操作している場合、ウィンドウのプロパティにアクセスできないはずです。 これらのプロパティがプログラムのどこからでも直接アクセスできるという事実だけで、あなたのアプローチの主な欠点です。プログラムのどの場所でも、現時点で必要とされる要素にのみアクセスできるようにする。それ以外のものは使用できないはずです。これは - 多くのエラーを自動的に回避することができます。 コア全体にアクセスできることでできるようになった不思議なこと」はすべて、見つけにくいエラーやコード理解の問題を引き起こす可能性があると私は考えています。このような手口を避けるようにしなければならない。 このやり方は、ポインタ、インクリメント、リファレンスを1行にごちゃごちゃと書いて、言語的には正しいかもしれないが、全く読めないという、非常に馬鹿げた作業を思い起こさせる。上で自分の機能を引用しましたが、これも全くおかしな話ですが、この場合はコンパクトであることが重要だと考えました。 СанСаныч Фоменко 2017.08.14 19:48 #257 Nikolai Semko: さて、なぜそこまで簡略化するのでしょうか？そして、わかりやすさ、読みやすさは？そして、エラーの検出と修正のしやすさ？ポータビリティは？そして、アップグレードのしやすさは？ などなど・・・。ファンタスティック!1.OOP以前は、非常に複雑なツールを使って、ビスポークの部品からすべてを組み立てていました。2.OOP以前は、プログラムは例外的によく混ざったコンポートでした。3.OOP以前は、データやコードのローカライズについて聞いたことがなく、メンテナンスが非常に困難でした。4.同じプログラムの異なる部分間のデータ保護は、悪夢でしたね5.OOP以前は、誰もシステムを拡張することはなかった。これは完全に失敗です。私は、70年代後半に、このようなプログラミング文化に関連するさまざまなことを適用してきたので、おそらくこのまさにOOPが私の中から育ってきたのだろうと考えています。 Реter Konow 2017.08.14 20:02 #258 George Merts:カーネルに不要なものがある」ではなく、「今のところ不要」と言ったのです。グラフの線を操作している場合、ウィンドウのプロパティにアクセスできないはずです。 これらのプロパティがプログラムのどこからでも直接アクセスできるという事実だけで、あなたのアプローチの主な欠点です。プログラムのどの場所でも、現時点で必要とされる要素にのみアクセスできるようにする。それ以外のものは使用できないはずです。これは - 多くのエラーを自動的に回避することができます。 コア全体にアクセスできることでできるようになった不思議なこと」はすべて、見つけにくいエラーやコード理解の問題を引き起こす可能性があると私は考えています。このような手口を避けるようにしなければならない。 このやり方は、ポインタやインクリメントや参照を一行で書いて、言語的には正しいかもしれないが、絶対に読めないという、最も愚かな作業を思い起こさせるものである。上で自分の機能を引用しましたが、これも全くおかしな話ですが、この場合はコンパクトであることが重要だと考えました。 カーネルについて、自分の経験に基づく瞬間的な理論的観念で推論しているのであって、技術の話とは関係ないだろ。そのため、アクセスに問題があったり、実体を記憶していなかったり...。私はこの技術の実務経験から推論して、アクセスや制限にそのような問題はないと言っているのです。正直なところ、アクセスの問題というのは全くわかりません。そのような問題はありませんし、今までもありませんでした。どのようなアクセスの問題を指しているのか、詳しく教えてください。エラーが発生するのであれば、アクセスを制限しなければならないと考える根拠は何ですか？これは私にとって新しいことです。プロシージャコード内でグローバル配列に直接アクセスすると、それだけで発見困難なエラーが発生することがありますか？ Georgiy Merts 2017.08.14 20:14 #259 Реter Konow:自分の経験に基づく目先の理論的な観念でカーネルを語っているのであって、技術とは関係ないだろ。そのため、アクセスに問題があったり、実体を記憶していなかったり...。私はこの技術の実務経験から推論して、アクセスや制限にそのような問題はないと言っているのです。正直なところ、アクセスの問題というのは全くわかりません。そのような困難はありませんし、これまでもそうでした。すべてがどこからでもアクセスできる」というのは、どういう意味で「問題ない」のでしょうか？ それが一番の問題なんです。アクセスできないはずだ ! ポイントは、アクセス制御の作業をコンパイラに移行させることです。すべてがオープンで、プログラマーがアクセスをコントロールする。 すべて覚えているので、複雑なことはありませんでした。まあ、そのうち記憶力が落ちてきて、コンパイラがアクセスをコントロールする機能がありがたいと思うようになるんでしょうけど。覚えていないんです。また、数ヶ月前に書いたものがどのように機能するのか、ほとんどの人が定期的に忘れているのではないでしょうか。そんなとき、アクセスコントロールが威力を発揮する。 例えば、発注を担当するブロックの中にいるとしたら......発注の能力しかない。そして、チャートを描く能力もない。チャート描画を担当するブロックにいる場合、そこからの発注はできません。これにより、作業が大幅に簡略化されます。また、チャート描画の 機能の中で、突然、注文を出すように要求されたとき、なぜそうしたのか、長い間、覚えていなければならないでしょう。なぜこのような判断になったのか、詳しいコメントがあるといいのですが...。しかし、注文は1つの専用ブロックに入れた方が良いのです。 Реter Konow 2017.08.14 20:25 #260 George Merts:すべてがどこからでもアクセスできる」というのに、どうして「問題がない」のでしょうか。 それが一番の問題点です。アクセスできないようにしなければならない 要は、アクセス制御の作業をコンパイラに移しただけなのです。すべてがオープンで、プログラマーがアクセスをコントロールする。 すべて覚えているので、複雑なことはありませんでした。まあ、そのうち記憶力が落ちてきて、コンパイラがアクセスをコントロールする機能がありがたいと思うようになるんだろうけど。覚えていないんです。また、数ヶ月前に書いたものがどのように機能するのか、ほとんどの人が定期的に忘れているのではないでしょうか。このような状況だからこそ、アクセスデリミテーションの恩恵は大きいのです。 例えば、発注を担当するブロックの中にいるとしたら......発注の能力しかない。そして、チャートを描く能力もない。チャート描画を担当するブロックにいる場合、そこからの発注はできません。これにより、作業が大幅に簡略化されます。また、チャート描画の機能の中で、突然、注文を出すように要求されたとき、なぜそうしたのか、長い間、覚えていなければならないでしょう。なぜこのような判断になったのか、詳しいコメントがあるといいのですが...。しかし、注文は1つの専用ブロックに入れた方が良いのです。 関数型プロシージャプログラミングでは、あなたが言うようなアクセスの問題は存在しないのです。関数のオーバーロードもなく、フィールドやオブジェクト、ポインタなどもなく、どこからでもアクセスできるすべてのグローバル 変数のためのメモリが1つしかないのに、どうして間違った関数を呼び出すことができるのでしょう？どのようなアクセスエラーが発生する可能性がありますか？全部覚えるのも楽だしね。 1...192021222324252627282930313233...48 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
考えることはあまりないんです。
OOPは、多くのチェックと承認をコンパイラに渡すことができる仕組みです。しかし、それを利用するためには、多少の手間をかける必要があります。
しかし、そうしたチェックやフィットが必要ないのであれば、OOPを使う意味はありません。
例えば、グラフィカルカーネルの多次元配列 は、今必要でないエンティティが多すぎるため、私は警戒しています。それらは気が散って、計算しにくいエラーを誘発する。それをオブジェクトの集合に置き換え、シンプルでコンパクトなインターフェースでアクセスできるようにします。インターフェースを手に入れることで、私は何も覚える必要がありません。インターフェース自体が私を制限し、例えば間違ったフィールドやオブジェクトにアクセスすることを防いでくれるのです。グラフィカルなカーネル配列の場合、そのような処理は非常に可能である。
つまり、ブロックがインターフェースを受け取る場合、コンパイラ自身が不要なエンティティを「切り捨てる」ことで、ユーザーのミスを防いでいるのである。しかし、グラフィカルなカーネル配列の場合、ユーザーには不要な情報が多く、間違えやすい。
私の経験では、コンパイラ自身が、現在のブロックの中で行ってはいけないところに行かないように見守ってくれている方が、ずっと良いということがわかっています。しかも、グラフィカルなカーネル配列で......覚えなきゃいけないですね。私のシステムのマイナスは、プラスの延長線上にあるのです。あるブロックの中で、今のタスク以上のものが急に必要になったとき、グラフィカルカーネルアレイがあれば簡単です。必要なデータを取ってきて、それを使って作業するだけです。しかし、OOPインターフェースでは、必要なデータを追加のインターフェースで要求するか、（もっと嫌なことだが）既存のインターフェースを変更する必要がある。
考えることはあまりないんです。
OOPは、多くのチェックと承認をコンパイラに渡すことができる仕組みです。しかし、それを利用するためには、多少の手間をかける必要があります。
しかし、こうしたチェックやフィットが必要ないのであれば、OOPの意味がありません。
しかし、なぜそこまで簡略化するのでしょうか。また、わかりやすさや読みやすさについてはどうでしょうか。そして、エラー検出と訂正の簡便さ？ポータビリティは？そして、アップグレードのしやすさは？ などなど・・・。
それなら、テーマも違って聞こえるはずだ。プログラミングの新しいツールキット」とか「新しいプログラミングパラダイム」とか......。
OOPよりかっこいいものを作ったというのが本当なら、有名になったら自分のものにサインをしてくれるのでしょうか？
問題なし!お友達へのサインも惜しみません ))))
冗談でしょうけど、想像では、このやり方は本末転倒だというくらいの見通しを持っています。時間が経てば、システムの自己改良の仕組みができそうです。論理カーネルを作って、いろいろな仕組みをランダムに生成させたら。あとは選別をして、適切なものを選べばいい。そして、少しづつすり潰していく...。カーネルのおかげで、信じられないようなことができるんです。
なぜ、そこまで物事を単純化するのか。そして、わかりやすさ、読みやすさは？そして、エラー検出と訂正の容易さ？ポータビリティについてはどうでしょうか？そして、アップグレードのしやすさは？ などなど・・・。
ナイスバナー広告 :-)"我々の象を買え"
これらの論文は、OOPでも非OOPでも、FPでもどこでも同じように適用できる。
考えることはあまりないんです。
OOPは、多くのチェックと承認をコンパイラに渡すことができる仕組みです。しかし、それを利用するためには、多少の手間をかける必要があります。
しかし、そうしたチェックやフィットが必要ないのであれば、OOPを使う意味はありません。
例えば、グラフィカルカーネルの多次元配列 は、今必要でないエンティティが多すぎるため、私は警戒しています。それらは気が散って、計算しにくいエラーを誘発する。それをオブジェクトの集合に置き換え、シンプルでコンパクトなインターフェースでアクセスできるようにします。インターフェースを手に入れることで、私は何も覚える必要がありません。インターフェース自体が私を制限し、例えば間違ったフィールドやオブジェクトにアクセスすることを防いでくれるのです。グラフィカルなカーネル配列の場合、そのような処理は非常に可能である。
つまり、ブロックがインターフェースを受け取る場合、コンパイラ自身が不要なエンティティを「切り捨てる」ことで、ユーザーのミスを防いでいるのである。しかし、グラフィカルなカーネル配列の場合、ユーザーには不要な情報が多く、間違えやすい。
私の経験では、コンパイラが現在のブロックの中でやってはいけないことを追跡してくれる方がずっといいんです。しかも、グラフィカルなカーネル配列で......覚えなきゃいけないですね。私のシステムのマイナスは、プラスの延長線上にあるのです。あるブロックの中で、今のタスク以上のものが急に必要になったとき、グラフィカルカーネルアレイがあれば簡単です。必要なデータを取ってきて、それを使って作業するだけです。しかし、OOPインターフェースでは、必要なデータを追加のインターフェースで要求するか、（もっと嫌なことだが）既存のインターフェースを変更する必要がある。
カーネルが冗長だと思うのは間違いです。そして、その実体は、定義によって人間の言葉をまとっているので、とても覚えやすいのです。そこにはあらゆるものが集められているが、このコンテンツには明確で不変の秩序がある。オブジェクト、ウィンドウ、エレメントのプロパティは、プログラムのどの時点でも直接アクセスすることができます。そして、カーネルのループでどんな不思議なことができるのか...。
カーネルに余計なものが入っていると思うのは全くの間違いです。そして、その実体を記憶することは、定義によって人間の言葉をまとっているため、とても簡単です。そこにはあらゆるものが集められているが、このコンテンツには明確で不変の秩序がある。オブジェクト、ウィンドウ、エレメントのプロパティは、プログラムのどの時点でも直接アクセスすることができます。そして、カーネルをループさせることで、どんな不思議なことができるのか...。
私は「カーネルが冗長」とは言っていません。「現時点では不要」と言ったのです。グラフの線を操作している場合、ウィンドウのプロパティにアクセスできないはずです。
これらのプロパティがプログラムのどこからでも直接アクセスできるという事実だけで、あなたのアプローチの主な欠点です。プログラムのどの場所でも、現時点で必要とされる要素にのみアクセスできるようにする。それ以外のものは使用できないはずです。これは - 多くのエラーを自動的に回避することができます。
コア全体にアクセスできることでできるようになった不思議なこと」はすべて、見つけにくいエラーやコード理解の問題を引き起こす可能性があると私は考えています。このような手口を避けるようにしなければならない。
このやり方は、ポインタ、インクリメント、リファレンスを1行にごちゃごちゃと書いて、言語的には正しいかもしれないが、全く読めないという、非常に馬鹿げた作業を思い起こさせる。上で自分の機能を引用しましたが、これも全くおかしな話ですが、この場合はコンパクトであることが重要だと考えました。
さて、なぜそこまで簡略化するのでしょうか？そして、わかりやすさ、読みやすさは？そして、エラーの検出と修正のしやすさ？ポータビリティは？そして、アップグレードのしやすさは？ などなど・・・。
ファンタスティック!
1.OOP以前は、非常に複雑なツールを使って、ビスポークの部品からすべてを組み立てていました。
2.OOP以前は、プログラムは例外的によく混ざったコンポートでした。
3.OOP以前は、データやコードのローカライズについて聞いたことがなく、メンテナンスが非常に困難でした。
4.同じプログラムの異なる部分間のデータ保護は、悪夢でしたね
5.OOP以前は、誰もシステムを拡張することはなかった。
これは完全に失敗です。
私は、70年代後半に、このようなプログラミング文化に関連するさまざまなことを適用してきたので、おそらくこのまさにOOPが私の中から育ってきたのだろうと考えています。
カーネルに不要なものがある」ではなく、「今のところ不要」と言ったのです。グラフの線を操作している場合、ウィンドウのプロパティにアクセスできないはずです。
これらのプロパティがプログラムのどこからでも直接アクセスできるという事実だけで、あなたのアプローチの主な欠点です。プログラムのどの場所でも、現時点で必要とされる要素にのみアクセスできるようにする。それ以外のものは使用できないはずです。これは - 多くのエラーを自動的に回避することができます。
コア全体にアクセスできることでできるようになった不思議なこと」はすべて、見つけにくいエラーやコード理解の問題を引き起こす可能性があると私は考えています。このような手口を避けるようにしなければならない。
このやり方は、ポインタやインクリメントや参照を一行で書いて、言語的には正しいかもしれないが、絶対に読めないという、最も愚かな作業を思い起こさせるものである。上で自分の機能を引用しましたが、これも全くおかしな話ですが、この場合はコンパクトであることが重要だと考えました。
カーネルについて、自分の経験に基づく瞬間的な理論的観念で推論しているのであって、技術の話とは関係ないだろ。そのため、アクセスに問題があったり、実体を記憶していなかったり...。
私はこの技術の実務経験から推論して、アクセスや制限にそのような問題はないと言っているのです。正直なところ、アクセスの問題というのは全くわかりません。そのような問題はありませんし、今までもありませんでした。
どのようなアクセスの問題を指しているのか、詳しく教えてください。
エラーが発生するのであれば、アクセスを制限しなければならないと考える根拠は何ですか？これは私にとって新しいことです。
プロシージャコード内でグローバル配列に直接アクセスすると、それだけで発見困難なエラーが発生することがありますか？
自分の経験に基づく目先の理論的な観念でカーネルを語っているのであって、技術とは関係ないだろ。そのため、アクセスに問題があったり、実体を記憶していなかったり...。
私はこの技術の実務経験から推論して、アクセスや制限にそのような問題はないと言っているのです。正直なところ、アクセスの問題というのは全くわかりません。そのような困難はありませんし、これまでもそうでした。
すべてがどこからでもアクセスできる」というのは、どういう意味で「問題ない」のでしょうか？
それが一番の問題なんです。アクセスできないはずだ !
ポイントは、アクセス制御の作業をコンパイラに移行させることです。すべてがオープンで、プログラマーがアクセスをコントロールする。
すべて覚えているので、複雑なことはありませんでした。まあ、そのうち記憶力が落ちてきて、コンパイラがアクセスをコントロールする機能がありがたいと思うようになるんでしょうけど。覚えていないんです。また、数ヶ月前に書いたものがどのように機能するのか、ほとんどの人が定期的に忘れているのではないでしょうか。そんなとき、アクセスコントロールが威力を発揮する。
例えば、発注を担当するブロックの中にいるとしたら......発注の能力しかない。そして、チャートを描く能力もない。チャート描画を担当するブロックにいる場合、そこからの発注はできません。これにより、作業が大幅に簡略化されます。また、チャート描画の 機能の中で、突然、注文を出すように要求されたとき、なぜそうしたのか、長い間、覚えていなければならないでしょう。なぜこのような判断になったのか、詳しいコメントがあるといいのですが...。しかし、注文は1つの専用ブロックに入れた方が良いのです。
すべてがどこからでもアクセスできる」というのに、どうして「問題がない」のでしょうか。
それが一番の問題点です。アクセスできないようにしなければならない
要は、アクセス制御の作業をコンパイラに移しただけなのです。すべてがオープンで、プログラマーがアクセスをコントロールする。
すべて覚えているので、複雑なことはありませんでした。まあ、そのうち記憶力が落ちてきて、コンパイラがアクセスをコントロールする機能がありがたいと思うようになるんだろうけど。覚えていないんです。また、数ヶ月前に書いたものがどのように機能するのか、ほとんどの人が定期的に忘れているのではないでしょうか。このような状況だからこそ、アクセスデリミテーションの恩恵は大きいのです。
例えば、発注を担当するブロックの中にいるとしたら......発注の能力しかない。そして、チャートを描く能力もない。チャート描画を担当するブロックにいる場合、そこからの発注はできません。これにより、作業が大幅に簡略化されます。また、チャート描画の機能の中で、突然、注文を出すように要求されたとき、なぜそうしたのか、長い間、覚えていなければならないでしょう。なぜこのような判断になったのか、詳しいコメントがあるといいのですが...。しかし、注文は1つの専用ブロックに入れた方が良いのです。