ユーザーインターフェイスクラスをコマンドラインインターフェイスに置き換えることができると考えるアーキテクチャを設計することは良い考えですか？

コード完了ページ25では、通常のユーザーインターフェイスクラスをコマンドラインクラスで簡単に置き換えることができるとよいと言われています。

テストの利点を知っていて、それがもたらす問題についてはどうでしょうか？

この余分な作業は、Webプロジェクトとモバイルプロジェクトにとって本当に成果がありますか？中小規模のプロジェクトはどうですか。同じルールが適用されますか？設計がより複雑になる場合はどうしますか？

さまざまなインターフェース（GUI、CLI、RESTなど）で機能を再利用できることは必ずしも必要ではありませんが、他の人がシステムとやり取りする新しい方法を見つけるので、システムを偶然再利用できるようにしておくと便利です。

これには、重み付けが必要ないくつかの欠点があります。

1. 追加の抽象化レイヤー（場合によっては階層）が必要になります。これらのレイヤーは優れたエンジニアリング手法ですが、開発には追加のコストがかかりますが、他の領域（メンテナンス、再利用、テストなど）の労力を削減することはできないため、少し検討する価値があります。
2. 媒体に最適なフローは、他の人にとってはひどい場合があります。機能がGUIをサポートするように設計されている場合、Webにとってはおしゃべりすぎるかもしれません。すべての機能がすべての媒体で価値があるわけではありません。
3. サービスとユーザーインターフェイスの間に汎用コンバーターを定義しようとするとトラップが発生するため、サービスコントラクトを定義して、すべてのメディアのUIを自動的に（または可能な限り）派生させることができます。多くのプロジェクトは、このようなフレームワークを構築しようとして、要件の変更に応じて可能な限りのカスタマイズを追加しようとして、あまりにも多くの労力を浪費しました。

そうは言っても、私の経験では、そのような層を実装することは常に努力を払うことになりました。いくつかのケースでは、納期の数週間前にメディアを交換する必要が生じたため（たとえば、Webサービス統合からUIへ）、システムを時間通りに展開できました。

テストとは別に、このアプローチの明らかな利点は、プロジェクトを自動化およびスクリプト化できることです。コマンドラインコマンドをプログラムに送信できる場合は、GUIで同じことを自動化するマクロを作成するよりもはるかに簡単に（より確実に）複雑なタスクを実行するスクリプトを作成できます。

もちろん、それが実際に行う価値があるかどうかは、プログラムを自動化するユーザーがたくさんいるかどうかに完全に依存します。

余分な作業ではなく、異なる作業です。適切に行うと、より複雑になるだけでなく、設計を切り離す必要があるため、より簡単になります。実際にCLIを実装するかどうかに関係なく、設計はそれを可能にする方が良いでしょう。

言及されていないように見える主な利点の1つは、これを実行できることにより、UIが基になるコードから厳密に分離されることです。このことの一つの重要な利点は、それはあなたが大幅にGUIを（OSX規格にiOSの基準を言う、または別のグラフィックエンジン）を変更する必要がある場合、それはだということを意味していることである、すべての基本的なコードはに依存しないように、あなたが変更する必要がありますUIのレイアウト。それができない場合、コマンドラインツールが機能しないためです。

それ以外に、テストを自動化できることが重要な利点です。

はい、それはほとんど常に良い考えです。

このアプローチに従えば、GUIと同じスレッド内で、GUIハンドラーの背後でビジネスロジックやデータにアクセスすることはほとんどないでしょう。この理由だけでも投資する価値があります。

いいアイデアだと思います。さらに、2番目のコマンドラインフロントエンドを作成できることにより、ビジネスロジックが特定のアプリケーションサーバーアーキテクチャに完全に分離されていることを最終的に証明します。

これを行う上で私が見る唯一の危険は、UIの特定の部分に到達するために、ユーザーは通常UIの他の部分を横断しなければならないことです。

開発者がUIを直接実行できる場所。開発者が実際に製品を使用するまでユーザーの問題を再現できない状況を見てきました。

そのため、テストを作成するときにも考慮してください。

いいえ。ひどいアドバイスです。

それは少しヤグニです（あなたはそれを必要としないでしょう）。

コマンドラインインターフェイスを公開することは、単体テストをサポートする方法でアプリを構造化すること、SOLIDの一部に準拠すること、または推奨するプログラミング方法とは異なります。

コマンドラインインターフェイスに適さないUIでは機能しません。MSペイントは非常にシンプルなアプリですが、どのような状況でも、コマンドラインからコントロールできるという利点はありますか？

スクリプトを実装するのに役立ちません。実際には、その方向への進行を妨げます。

唯一の肯定的なことは、25ページに掲載されていることです。したがって、少なくとも、この本の残りの部分は...においがするかもしれないという警告が表示されます。ずいぶん前に読みましたが、気に入らなかったので、偏見があります。

Mason Wheelerが述べたことに基づいて、コマンドラインを介してアプリケーションとやり取りできることにより、タスクの自動化が非常に簡単になります。

これはテストで特に役立ちます。

実用的な例を挙げると、アプリケーションで自動テストを実行する場合、アプリケーションを自動的にインストールすることができます。これを行うには、次のパラメーター「myApplication.exe / silentinstall」を渡します。

このコマンドラインスイッチを指定すると、GUIインストーラーなしで、バックグラウンドでサイレントインストールが実行されるようにプログラムできます。インストーラへの入力（インストールディレクトリなど）は、おそらくXMLファイルから取得できます。

別の例を見てみましょう。Microsoft Test Manager GUI（Visual Studioに付属）を使用すると、ユーザーはそのGUIインターフェイスからテスト実行を起動できますが、同じことを行うコマンドラインインターフェイスも提供します（コマンドラインスイッチと入力の組み合わせを使用）。これは、PowerShellまたはDOSスクリプトをまとめてテストの起動を自動化でき、スクリプトを毎晩実行するようにスケジュールされたタスクを作成できることを意味します。

一部のアプリケーションには、特定のオプションで開くアプリケーションを指定するコマンドラインスイッチがあります（たとえば、「/ maximize」を使用して、最大化されたウィンドウでアプリケーションを開くことができます）。

コマンドラインインターフェイスが使用される可能性のあるシナリオはたくさんあります。これらはほんの一例です。

繰り返しますが、「[通常のユーザーインターフェイスクラスをコマンドラインクラスで簡単に置き換えることができるのは良い考えです」」というフレーズに注目してください。CLIを作成する必要があるわけではなく、簡単に作成できるというだけです。

ですから、UIを他のコードから切り離す必要があるということです。

それは依存しますが、私がそれを依存すると言うとき、それはいくつかのエッジケースを持っているだけの問題ではなく、アプリケーションとターゲットオーディエンスに非常に依存しています。方程式からゲームを排除すると仮定すると、コマンドのようなものが実装されそうにない、または実装されないようなアプリケーションを幅広く作成できます。頭の中で、モバイル（iOS、Androidなど）環境を対象とするアプリケーションは、この見出しに該当する可能性があります。

これを念頭に置いて、一般的なソフトウェアの分野では、視覚化に大きく依存するアプリケーション（PowerPoint、Mayaなど）でコマンドラインの置換が実装されることはほとんどありません。実際、Mayaなどのグラフィックソフトウェアの場合、完全かつ適切なコマンドラインバージョンがどのように機能するかを判断することは、良いメンタルエクササイズであり、ユーザーの観点からは不可能な場合があります。したがって、インターフェイスのようなコマンドが表示される可能性が低い、またはアプリケーションのスクリプト作成が望ましい場合でも望ましい場合に遭遇する可能性のある、明らかに一般的なアプリケーションがあることは明らかです。

次に、一般的なソフトウェアアーキテクチャの観点から提案フォームを見ると、「ユーザーインターフェイスなしでこの機能にアクセスするにはどうすればよいですか」と定期的に自問するのが理にかなっていることがわかります。一般に、それを行う方法がなく、ユーザーと直接対話しない場合（ジェスチャ入力など）は、アーキテクチャ全体を改善する必要がある可能性があります。テストを簡単にするために、コマンドラインからは呼び出せなくても、ユーザーインターフェイスを経由せずにコマンドに直接アクセスできるようにしたいと考えています。これは一般に、堅固なAPIを配置する必要があり、理論的にはコマンドラインまたはユーザーインターフェイスを介したアクセスを許可する優れたAPIが必要であることを意味します。さらに、長期的には、

結局のところ、提案が得ようとしていることは理にかなっていると思います（つまり、優れたAPIを使用してユーザーインターフェイスを構築します）。 。

場合によります。

多くの場合、プログラムをmodel / view / controllersまたはmodel / view / view / modelとしてパーティション分割します。モデルはコマンドラインアクセスを許可する必要があるようですが、コントローラーについては確信がありません。当然、ビューは置き換えられるものです。

ツールチェーンに基づいていくつかの違いが存在する場合があります。Code CompleteはMicrosoft Pressの本なので、おそらくこのGUIにMicrosoftテクノロジーを使用していますか？その場合、COMまたはDCOMを介してインターフェイスを公開するためのアプリを作成するときにチェックボックスがあると思います。一部のマイクロソフトテクノロジでは、リソーステーブルとメッセージパッシングは、ウィザードが迅速にプロトタイプを作成するのに役立つすべてのものとかなり密接に結びついていると思います。良くなっていると思いますが、MFCやFormsをメンテナンスしていると、少し痛くなるかもしれません。

場合によっては、GUIベースのプログラムが管理インターフェイスのラッパーであるか、独自のロジックがほとんどないため、コマンドラインインターフェイスで制御することはあまりありません。別のコンソールアプリを作成すると、より迅速になり、重要なものをスクリプト化、テスト、または使用できるようになります。

私が推測するキーポイントは、提案がルールではないということです。従うと、ユニットまたは受け入れテストが簡単になり、クリックする代わりに入力を希望する場合の代替インターフェースが得られます。それがそれ自身のために支払うならば、それをしてください。幸運を。

これは、コマンドラインプログラムの有用性によって異なります。地図上にルートをプロットしたり、3Dゲームをプレイしたりといったいくつかのことは、コマンドラインインターフェイスには向いていません。しかし、システムツールのような他のものは、スクリプト化できるという単純な理由から、GUIよりもコマンドラインからのほうがはるかに優れています。

リチャードヒップ博士はかつて、彼の理想的なGUIオペレーティングシステムは、コマンドウィンドウを開くためのアイコンとWebブラウザーを開くための別のアイコンを備えた空白のデスクトップだと言っていました。ほぼ同じように感じます。コマンドラインプログラムとして有用であり、そのように構築するのがそれほど難しくない場合は、それを行います。GUIは完全に別のプログラムである可能性があり、おそらく他の誰かが作成したものです！

最近（少なくともJavaの場合）、遅かれ早かれ、すべてのプログラムが遅かれ早かれWebサービス（SOAPまたはAjax、あるいはその両方）を追加するようです。ですから、一般的にはそう思いますが、より良いメンタルメタファーが必要な場合は、Webサービスのフロントエンドがコマンドラインよりも可能性が高くなります。

物事を見る別の方法があります。コマンドラインが唯一の方法であると想定するのではなく、音声制御が代わりに使用されると想定しないのはなぜですか。その場合、まったく異なるパラダイムが必要です。

JobsがAppleを引き継ぐ前に、非常に高度な音声制御メカニズムが検討されていました。Appleはこれをつぶして、Siriなどを支持しました。

はぁ。

人気があり明白であることは、常に「最高」とは限りません。

はい、これは一般に良い考えです。

メタファーによって、人々はこれをRESTfulなデザインの一形態と考えるかもしれません。....それ自体は、典型的な（G）UIがアカウント作成などの複雑なマルチステージトランザクションを伴う可能性があるためではありません。

Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.

ブラウザでドラッグアンドドロップUIのメタファーをプログラミングしたことがあります。バックエンドでの非常に複雑な相互作用ルールにより、UXが自然に感じられます。この問題を解決するには、サイトをAPIにし、GUIはアクション時にイベントを生成する完全なアプリでした。モジュールはこれらのイベントをキャッチし、タイマーで「APIコール」にバンドルしました（ネットワーク効率のため）。

その結果、完全にRESTfulなコアシステムが完成しました。2番目の結果は、サードパーティ用のインターフェイスがあり、ビジネスモデルに従って所属プロファイルを使用して公開できることでした。

1つの利点は、ユーザーの観点からUIのフローについて考えることを余儀なくされることです。（何を達成しようとしていますか？どのコンテキストを設定する必要がありますか？そのコンテキストを考慮して、どのように目標を達成しますか？）

「銀行口座の作成」と「ms word documentの作成」には大きな違いがあります。CLIを構築しなくても、必要な「CLIコンテキスト」を考慮するためだけに価値が追加される場合があります。モデルは、ビジネスオブジェクトモデルの中にあるだけではありません。