ユーザーインターフェイスクラスをコマンドラインインターフェイスで置き換えることができると考えてアーキテクチャを設計することは良い考えですか？
コード完了の25ページでは、通常のユーザーインターフェイスクラスをコマンドラインクラスで簡単に置き換えることができるとよいとされています。
テストの利点を知って、それがもたらすかもしれない問題についてはどうですか？
この余分な作業は、本当にWebおよびモバイルプロジェクトに見返りをもたらしますか？中小規模のプロジェクトはどうですか。同じルールが適用されますか？設計が複雑になるとどうなりますか？
さまざまなインターフェース（GUI対CLI対RESTなど）で機能を再利用できることは必ずしも必要ではありませんが、他の人々がシステムと対話する新しい方法を見つけるため、システムに対して serendipitous reuse を用意して有効にすると便利です。
これには、重み付けする必要があるいくつかの欠点があります。
- 追加の抽象化レイヤー（場合によっては層）が必要になります。これらのレイヤーは優れたエンジニアリング手法ですが、開発には追加のコストがかかりますが、それを理解することで他の領域（メンテナンス、再利用、テストなど）の労力を削減できない可能性があるため、少し考えてみる価値があります。
- メディアにとって最適なフローは、他のユーザーにとってはひどい場合があります。機能がGUIをサポートするように設計されている場合、それは Webに対しておしゃべりすぎる の可能性があります。すべての機能がすべての媒体で価値があるわけではありません。
- サービスとユーザーインターフェイスの間に汎用コンバーターを定義しようとすることには罠があるので、サービスコントラクトを定義して、すべてのメディアのUIを自動的に（または可能な限り）派生させることができます。多くのプロジェクトは、そのようなフレームワークを構築しようとして、要件の変更に応じてあらゆるカスタマイズをフレームワークに追加するために多大な労力を無駄にしています。
そうは言っても、私の経験では、そのような層を実装することは常に努力を払うことになった。いくつかのケースでは、期日の数週間前にメディアを（Webサービスの統合からUIへなど）交換しなければならなかったため、時間どおりにシステムを展開することができました。
テストとは別に、このアプローチの明らかな利点は、プロジェクトがautomatableおよびscriptableになることです。コマンドラインコマンドをプログラムに送信できれば、スクリプトを作成して、GUIで同じことを自動化するマクロを作成するよりもはるかに簡単に（そして確実に）複雑なタスクを実行できます。
もちろん、それが実際に行う価値があるかどうかは、プログラムを自動化したいユーザーがたくさんいるかどうかにかかっています。
それは余分な作業ではなく、単にdifferent作業です。正しく行うと、複雑になるだけでなく、simplerにもなり、設計を切り離す必要があります。実際にCLIを実装するかどうかに関係なく、そうすることを可能にするための設計の方が良いでしょう。
言及されていないように思われる主な利点の1つは、これをかなり実行できることです基になるコードからのUIの厳密な分離を強制します。これの主な利点の1つは、GUIを大幅に変更する必要がある場合（たとえば、iOS標準をOSX標準に、またはグラフィカルエンジンを別のものに変更する必要がある場合）はall基になるコードはUIのレイアウトに依存しないため、変更する必要があります。それはできません。そうであった場合、コマンドラインツールは機能しません。
それ以外に、テストを自動化できることは重要な利点です。
はい、それはほとんど常に良い考えです。
このアプローチに従えば、GUIと同じスレッドで、いくつかのGUIハンドラーの背後でビジネスロジックやデータにアクセスできない可能性があります。この理由だけで投資する価値があります。
いいアイデアだと思います。さらに、2番目のコマンドラインフロントエンドを作成できることで、最終的にビジネスロジックが特定のアプリケーションサーバーアーキテクチャに完全に切り離されていることが証明されます。
これを行う際に私が目にする唯一の危険は、UIの特定の部分に到達するために、ユーザーは通常、UIの他の部分をトラバースする必要があることです。
開発者がUIを直接実行できるのと同じところです。開発者が実際に製品を使用するまでユーザーの問題を再現できない状況を見てきました。
したがって、テストを作成するときにもそれを考慮に入れてください。
いいえ、ひどいアドバイスです。
それは少しヤグニです（あなたはそれを必要としないでしょう）。
コマンドラインインターフェースを公開することは、単体テストをサポートしたり、SOLIDの任意の部分、または私が推奨するプログラミング方法に準拠した方法でアプリを構築することと同じではありません。
コマンドラインインターフェースに適さないUIには機能しません。 MS Paintは本当にシンプルなアプリですが、どのような状況でも、コマンドラインから制御できることのメリットをどのように見ますか？
スクリプトの実装には役立ちません。それは実際にはその方向への進展を妨げます。
唯一の肯定的なことは、25ページに掲載されていることです。少なくとも、本の残りの部分が臭いかもしれないという警告が表示されます。ずっと前に読んで気に入らなかったので、偏っています。
Mason Wheelerの発言に基づいて、コマンドラインを介してアプリケーションと対話できることで、タスクの自動化が非常に簡単になります。
これはテストで特に役立ちます。
実用的な例として、アプリケーションで自動テストを実行する場合は、アプリケーションを自動的にインストールする必要があります。これを行うには、「myApplication.exe/silentinstall」というパラメーターを渡します。
このコマンドラインスイッチを指定すると、GUIインストーラーなしでバックグラウンドでサイレントインストールが実行されるようにプログラムする場合があります。インストーラへの入力（インストールディレクトリなど）は、おそらくXMLファイルから取得できます。
別の例を見てみましょう。 Microsoft Test Manager GUI（Visual Studioに付属）を使用すると、ユーザーはGUIインターフェイスからテスト実行を開始できますが、同じことを実行するコマンドラインインターフェイスも提供します（コマンドラインスイッチと入力の組み合わせを使用）。つまり、PowerShellまたはDOSスクリプトを一緒に作成して、テストの起動を自動化し、スケジュールされたタスクを作成して、スクリプトが毎晩実行されるようにすることができます。
一部のアプリケーションには、特定のオプションで開くアプリケーションを指定するコマンドラインスイッチがあります（たとえば、「/ maximize」を使用して、最大化されたウィンドウでアプリケーションを開く場合があります）。
コマンドラインインターフェイスが使用されるシナリオはたくさんあります。これらはほんの一例です。
「通常のユーザーインターフェイスクラスをコマンドラインクラスで簡単に置き換えることができるのは良い考えです。」というフレーズにもう一度注意してください。 CLIを作成する必要があるという意味ではなく、簡単に作成できるという意味です。
つまり、UIはコードの残りの部分から分離する必要があるということです。
状況によって異なりますそして、状況によっては、いくつかのEdgeケースがあるというだけではなく、アプリケーションとターゲットに大きく依存します聴衆。方程式からゲームを排除していると仮定すると、のようなコマンドが実装される可能性が低いか、まったく実装されない可能性がある、さまざまなアプリケーションがまだ作成されている可能性があります。私の頭の外では、モバイル（iOS、Androidなど）環境をターゲットとするアプリケーションは、この見出しに該当する可能性があります。
このことを念頭に置いて、一般的なソフトウェア空間では、視覚化に大きく依存しているアプリケーション（たとえば、PowerPoint、 Maya など）では、コマンドラインの置き換えが実装されることはほとんどありません。実際、Mayaなどのグラフィックソフトウェアの場合、完全で適切なコマンドラインバージョンがどのように機能するかを判断することは、適切なメンタルエクササイズであり、ユーザーの観点からはそうすることができない場合があります。したがって、インターフェースのようなコマンドが見られない、またはアプリケーションのスクリプトが望ましい場合でも望ましい場合に遭遇する可能性のある決定的に一般的なアプリケーションがあることは明らかです。
次に、一般的なソフトウェアアーキテクチャの観点から提案フォームを見ると、定期的に「ユーザーインターフェイスなしでこの機能にアクセスするにはどうすればよいですか」と自問するのが理にかなっていることがわかります。一般的に、それを行う方法がなく、ユーザーと直接対話していない場合（ジェスチャー入力など）、アーキテクチャ全体を改善する必要がある状況にある可能性があります。テストを容易にするために、コマンドラインから呼び出すことができない場合でも、ユーザーインターフェイスを介さずに直接コマンドにアクセスできるようにする必要があります。これは一般に、堅牢なAPIを配置する必要があり、理論的には適切なAPIがコマンドラインまたはユーザーインターフェイスを介したアクセスを許可する必要があることを意味します。さらに、長期的に見ると、アプリケーションに新しいユーザーインターフェイスを追加する必要がある場合は、時間を節約できます。
結局のところ、提案が達成しようとしていることは理にかなっていると思います（つまり、適切なAPIを用意し、そこからユーザーインターフェイスを構築する）と思いますが、Wordの選択は、ポイントを理解するために少し優れているかもしれません。
場合によります。
多くの場合、プログラムをモデル/ビュー/コントローラーまたはモデル/ビュー/ビュー/モデルとして分割します。モデルはコマンドラインアクセスを許可するようですが、コントローラーについてはよくわかりません。当然、ビューは置き換えられるものです。
ツールチェーンによっては、多少の違いが生じる場合があります。 Code CompleteはMicrosoft Pressの本です。このGUIにMicrosoftテクノロジーを使用しているのではないでしょうか。もしそうなら、COMまたはDCOMを介してインターフェイスを公開するためのアプリを作成するときにチェックボックスがあると思います。一部のMicrosoftテクノロジでは、リソーステーブルとメッセージパッシングは、ウィザードを使用して迅速にプロトタイプを作成できるものとかなり集中的に結合されていると思います。良くなっていると思いますが、MFCやFormsを維持していると、少し傷つくかもしれません。
場合によっては、GUIベースのプログラムが管理インターフェイスのラッパーであるか、独自のロジックがほとんどないために、コマンドラインインターフェイスで制御することがあまりない場合があります。別のコンソールアプリを構築する方が速いかもしれませんが、それでもスクリプト、テスト、または重要なものを使用できます。
私が推測する重要なポイントは、提案は規則ではないということです。それに従うと、ユニットや受け入れテストが簡単になったり、あなたや顧客がクリックするのではなく入力したりする場合のフォールバックインターフェイスが得られます。それがそれで元が取れれば、それをしてください。幸運を。
最近（少なくともJavaの場合）遅かれ早かれ、すべてのプログラムがWebサービス（SOAPまたはAjaxまたはその両方）を遅かれ早かれ追加するように思われます。したがって、一般的にはそう考えますが、より良いメンタルメタファーが必要な場合は、Webサービスのフロントエンドがコマンドラインよりも可能性が高くなります。
コマンドラインプログラムがどの程度役立つかによって異なります。地図上にルートをプロットしたり、3Dゲームをプレイしたりするなど、いくつかのことはコマンドラインインターフェースには向いていません。しかし、システムツールのような他のものは、スクリプト化できるという単純な理由から、GUIからよりもコマンドラインからのほうがはるかに優れています。
Richard Hipp博士はかつて、彼の理想的なGUIオペレーティングシステムは、コマンドウィンドウを開くためのアイコンとWebブラウザーを開くための別のアイコンを備えた空のデスクトップであると語っていました。私はほとんど同じように感じます。コマンドラインプログラムとして役立ち、そのように構築するのがそれほど難しくない場合は、私はそれを行います。 GUIは完全に別のプログラムである可能性があります。
これは一般的に良い考えです、はい。
比喩的に言うと、人々はこれをRESTfulな設計の1つの形と考えるかもしれません。 ....典型的な（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番目の結果は、サードパーティ用のインターフェイスがあり、ビジネスモデルに従ってアフィリエーションプロファイルを使用して公開できることです。
物事を見る別の方法があります。コマンドラインが唯一の方法であると想定するのではなく、代わりに音声コントロールが使用されると想定してみませんか？その場合、まったく異なるパラダイムが必要です。
JobsがAppleを引き継ぐ前は、非常に高度な音声制御メカニズムが検討されていました。 AppleはSiriのようなものを支持してこれを抑制しました。
はぁ。
人気があり、明白であることが常に「最良」であるとは限りません。