コンソールベースのプログラミングからGUIベースのプログラミングに移行する場合の主な違いは何ですか?


18

私は、他の多くの人と同じように、コンソールベースの(プレイステーションではなく端末のような)プログラミングから始めました。ただし、遅かれ早かれ、GUIベースのプログラミングに触れる必要があります。この移行には、フロントエンド(および場合によってはバックエンド)について考える必要がある方法に多くの変更が含まれています。

それでは、コンソールベースのプログラミングからGUIベースのプログラミングに移行するときの主な違いは何ですか?


1
ターミナルのようにコンソールを意味しますよね?プレイステーションのようではないコンソール...
JBRWilkinson

@JBRウィルキンソン:はい。質問を明確にします。
ギャブリン

回答:


18

最大の違いは、UIの設計です。優れたGUIを使用すると、アプリケーションを作成または中断できます。Macファンは、平均的なMac OS Xアプリの美しくデザインされたGUIに注目し、彼らはポイントを持っていますが、これは技術的な問題ではなく、デザイン/精神/ユーザビリティの問題です。

技術的な問題に関しては、順不同です:

  1. ユーザーは、入力を求めたり出力を指示したりするコンソールプログラムとは異なり、いつでも好きな順序で好きなことを行うことができます。ワークフローウィザードスタイルを強制しない限り、希望する順序に従うとは想定できません。

  2. すでに述べたように、イベントはこれで大きな役割を果たします。最後のイベントを処理している間に複数のイベントが発生する可能性があるため、「現在のイベント」に基づいて状態を実際に構築することはできません。クロージャーまたは同様のメカニズムを使用して、異なるイベント間でコンテキストを維持します。コンソールアプリでは、FSMは通常、「入力の取得、入力の処理、出力の更新」ループの周囲に自己完結しています。GUIプログラミングには同じ種類の構造はありません。「メイン」は、リエントラントなイベント駆動型のもので、多くの場合、重大なswitch()ステートメントです。

  3. さまざまな画面サイズ/解像度を検討し、GUIが800x600からユーザーのモニターの最大サイズに変更できるようにする必要があります。

  4. マウス、キーボード、タッチなど、さまざまな入力戦略を検討する必要があります。無料の技術(マウスホイールスクロール)もあれば、統合作業(インク)が必要な技術もあります。

  5. アクセシビリティ-GUIは、視覚、聴覚、運動能力、または認知能力が制限されている能力の低いユーザーに適しています。「ding」ノイズは、コンソールの不可解なエラーメッセージと比較して、わかりやすくて明らかです。

  6. 国際化-コンソールアプリはUS / ANSIのみであることを前提としていますが、GUIにアクセスすると、コーディングを変更せずに他の言語や地域をターゲットにできる言語/リソースパッケージを用意できます。開始。たとえば、コード内にハードコードされた言語文字列はありません-リソース検索としてすべて。

  7. 実装テクノロジには、WebベースのさまざまなGUIキット、Flash / WPFなど、さらに多くのオプションがあります。

  8. 色とアニメーションの使用。コンソールプログラムは一般的に単色であり、あまり動きません。最新のGUIフレームワークの多くは、テーマウィジェットを提供し、アニメーション効果を移動/サイズ/表示/非表示にします(多くの場合無料です)。

  9. グラフィック。コンソールアプリはダイアグラムにASCIIアートを使用する場合がありますが、GUIアプリでは完全なグラフィカル機能が提供されます。素敵なアートも大きな違いを生みます。


1
私はあなたの意見を一般的に見ていますが、ここでの誤った二分法に少し反対します。つまり、コンソールアプリのUIにも注意を払う必要があります。イベントベースのコンソールアプリを使用することも、線形テキストだけでなくGUIを実際に表示し、サイズ変更に注意を払う必要があるターミナルアプリを作成することもできます(そしてマウスで動作する場合があります)、アクセス可能なcliアプリを実行でき、guiアプリと同じ方法でcliアプリを国際化し、色を使用して物事をアニメーション化できます。7と9がより制限されていることを認めます。
ヘイレム

17

私にとっては、イベント駆動型プログラミングに慣れるでしょう。コンソールベースのソフトウェアにも適用できますが、ほとんどはGUIで使用されます。一度把握​​すれば、非常に強力なツールになります。


同意する。学習する必要があるのは、コードがユーザーが次に何をするかを完全に制御していないことです。

対話の受容と。
モーガンハーロッカー

6

私はマルチスレッドと言って、それはUIに影響します(非ブロッキングUIをしたい場合)


スレッド化は対処するのに非常に退屈な技術的問題であるため、+ 1 。
クレメントヘレマン

2

UIの制御フローとユーザー入力の検証を考慮することが非常に重要になります。


2

コンソールプログラムは時間の経過とともに洗練される傾向がありますが、GUIプログラムはねじ込みがちです。


1

通常、コンソールベースのプログラムはモデルと考えますが、GUIベースのプログラムはモデルを組み込むビュー/コントローラーです。


1

私にとって、良いGUIを設計することは、それを実装する技術的な詳細よりもずっと挑戦的でした。

「Macのようにシンプルで明確にする」と言うのは簡単です。そのようにするのは非常に困難です。そこにあるべき多くの詳細が常にありますが、同時に、それらは見えないはずです。

シンプルhttp://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png


1
Google WaveまたはiMovieをご覧になると、これらの画像が誤解を招きやすいことがわかります。
イボフリップ

0

一部の(多くの?)言語では、私にとって大きな違いは、ライブラリを選択する必要があるということです。アプリケーションのバックボーン(さらに幸運なことに、すべて)の「コンソール」プログラミングを行うと、言語の標準リソースが使用されます。GUIを追加することで(できれば)標準のイディオムで「モデル」を保持できますが、今では大きな部分である「ビュー」は一部の外部ライブラリに依存します(そして、願わくば、「永遠」に固執します)。このライブラリの選択は、あなたの(私の)場合と同様、初心者にとって大きな責任です(追加の学習ステップ曲線は言うまでもありません)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.