Windows 10 に限った事度はありません、Androidも最近そうなのですが・・
最近、プログラマのプログラムの組み方が変わってきているのが原因でしょう。
近年では、「オブジェクト指向」と呼ばれる記述法がプログラム（行動）を組む上で、[汎用性]などの良さから推奨されています。
この考え方は非常に強力で、例えば
以前のプログラミング方法は、
サッカーチームが試合をする場合に、各チームの監督（プログラム）が試合中に随時選手に指示を出す様な方式といえます。
オブジェクト指向ならば、
サッカーチームの個々の選手（オブジェクト）に対して、プログラム、つまりは状況に応じた行動が教え込んである状態であり。監督は、蚊帳の外で、しいて言えばプログラマーのポジションにあたります。
普通に考えれば、オブジェクト指向の考え方が当然のように感じますが。
以前の考え方の方が、完全に状況が把握できていました。
以前の方法の利点は、「自分自身の事なら自分が良く解っているわ！」というセリフに近いです。
【目標】 足に画鋲が刺さった場合に取り除こうとする、プログラム（行動）を記述する。
～ 以前の手法の場合 ～
プログラム記述段階
「足に画鋲が刺さったとこを検知したら、画鋲を取り除く」を実現するプログラムを書く
テスト運用
（画鋲が刺さる）
Robo Log > 「感覚器官」が痛みを検知したので対処する。
～ オブジェクト指向 ～
プログラム記述段階
[頭（判断）]、[伝達神経（パイプ）]、[感覚器官（センサ）]のオブジェクトに分けると決める
頭（判断） … 痛みを検知した時の対処する
伝達神経（パイプ） … 信号を頭に流す
感覚器官（センサ） … 刺激を検知したら伝達神経に信号を流す
テスト運用
（画鋲が刺さる）
Robo.v2 Log > 感覚器官が反応をとらえた
Robo.v2 Log > 伝達神経に送る
Robo.v2 Log > 痛み系信号は頭に送る
Robo.v2 Log > 痛みを検知。対処を開始する
このような場合、以前の手法の方が簡単に作ることができるし、ワンクッションもツークッションも付け足す必要もないです。
でも、従来の作り方では汎用性がありません。
現状では「足の痛みしか検知しない」つまりは、手に画びょうが刺さっても対処しません。
足のプログラムをコピペして、手に書き換えればいい。ほかの場合もアレもコレもと・・・・
そんなことでは、プログラムが無駄に大きくなってしまいます。
こうなれば、パーツ（オブジェクト）ごとに分けた利点が出てきます。
足以外にも、画鋲を検知したいなら。感覚器官（オブジェクト）の内容を編集・追加するだけで済み、[伝達神経]と[頭]は、独立して動作しているために何も変えなくてもよいのです。
・・・と、また長い前置きをしてしまいました。
（オブジェクト指向の利点はそれだけではないのですが・・・）
この志向の導入により、ソフトウェアの進歩は軽快になりましたし、プログラムのサイズは小さくなり、コンピュータのメモリ消費も抑えられたりして、一石二鳥なのですが・・
オブジェクト指向は、役割ごとに分けられます。言い方を変えれば、集団行動です。
一つ一つのオブジェクトは、個々の役割を個々に果たし。集団で結果を出します。
個別の意識として、ばらばらのタイミングで行動をするが故に、最近の電子機器は中途半端な挙動を示すことがあります。
・画像のダウンロードが完了していないのに、空っぽの画像ビュアーが表示される。
・得点計算が完了していないのに、結果発表画面に移り。そのまま時間が過ぎて次の画面に行く。
などなどやこれと似たような挙動が増えていますね。
ダウンロード時間や計算時間は、環境によって変わるので。予定通り行かない場合が稀に起こります。
ウィンドウも出来上がっていないのに、表示されて。「は？」ってなることもあるでしょう。し、それが増えてくると思います・・・。
対策がなかなか面倒なので、行わない場合もあります。
申し訳ないが、報告だけしていただいて今一度待ってもらいたい・・。
最近は、ソフトを閉じて、もう一度開きなおすだけでも、復帰しますし。
Windowsの問題なら、再起動しなくても、ログアウトだけでも十分にリフレッシュができますよ。
あとがき
楽をしているわけでもないですし・・・もうなんか、仕様ってつけたくなる作業ですよ・・・プログラマーは・・・
おもしろ動画で、たまにある。ゲームで車に乗ったら車のフレームだけ推進するみたいな話でした。
0 件のコメント:
コメントを投稿