誰かが OOP のインターフェイスの膨張とは何かを説明できますか (できれば例を挙げて)。
7 に答える
こんばんは
GUI ではなく API を意味していると仮定すると、I/F の肥大化はいくつかの方法で発生する可能性があります。
- API は、分離の形をとらずに新しい機能で拡張され続けているため、使いにくくなるモノリシックなヘッダー ファイルができあがっています。
- 既存の API で宣言された関数は、そのシグネチャに新しいパラメーターが追加され続けるため、アップグレードを続ける必要があり、既存のアプリケーションは下位互換性がありません。
- 既存の API の関数は、非常によく似たバリアントでオーバーロードされ続け、使用する関連関数の選択が困難になる可能性があります。
これを支援するために、次のことができます。
- API を一連のヘッダーとライブラリに分離して、実際に必要な部分をより簡単に制御できるようにします。内部依存関係はすべてベンダーによって自動的に解決される必要があるため、ユーザーは試行錯誤によって依存関係を見つける必要がありません。たとえば、宣言された API の関数のみを使用したい場合に、ヘッダー ファイル wibble.h を含める必要があります。 shozbot.h ヘッダー ファイル内。
- 必要に応じてオーバーロードを導入して、API のアップグレードに後方互換性を持たせます。ただし、オーバーロードされた関数をカテゴリにグループ化する必要があります。たとえば、オーバーロードされた関数の新しいセットが既存の API (our_api.h など) に追加され、それを新しいテクノロジ (SOA など) に適合させる場合、それらは独自のヘッダー ファイルで個別に提供されます。 our_api_soa.h を既存のヘッダー our_api.h に追加します。
HTH
すべてのメソッドが Object で定義されている OO 言語を考えてみてください。ただし、それらは一部のサブクラスに対してのみ意味があります。一番極端な例でしょう。
ほとんどのマイクロソフト製品?
インターフェースの肥大化は、一度に画面に表示される要素が多すぎます。特に、ほとんど使用されていない要素や、機能がわかりにくい要素です。おそらくインターフェイスの肥大化を説明する簡単な方法は、37signalsのBasecampを試してみることです。ヘッダーにはいくつかのタブといくつかのリンクしかありません。
インターフェイスの肥大化は、折りたたみ可能なペイン (たとえば Javascript を使用) や、使用頻度の低い選択肢を必要になるまで非表示にするドリルダウン メニューによって改善できます。
インターフェースの肥大化とは、単純でエレガントなインターフェースだったものを、ボタン、メニュー、オプションなどがあちこちに散らばったものに変える要素を徐々に追加することであり、アプリケーションの元のまとまりを台無しにします。私が頭に浮かぶ例の 1 つが iTunes です。初期のバージョンでは非常にシンプルでしたが、時間の経過とともに、肥大化と見なされる可能性のある非常に多くの機能が追加されました (iTunes DJ、Coverflow、Genius)。
インターフェイスの肥大化は、次のユーモラスな例のように、すべての機能を 1 回クリックすることによって発生することがあります。
(面白いかもしれませんが、この例ではユーザーがすべてのツールバーを追加したため、この例は Firefox にとって公平ではありません)
「プログレッシブ ディスクロージャー」と呼ばれる UI デザイン手法は、インターフェイスの肥大化を抑える 1 つの方法です。最も頻繁に使用される機能のみを最上位のクリックとして公開します。アプリに含める価値のあるあまり使用頻度の低い機能がある場合は、それらを論理的な方法でグループ化します (ドロップダウン メニューやその他のナビゲーション要素の背後など)。
ほとんどの C++ プログラマーがよく知っているインターフェイスの肥大化の極端な例は、std::basic_string
. メンバー関数のページ アップとページ ダウンはわずかなバリエーションしかありません。これらの関数のほとんどは、メンバー関数である必要はなく、文字列ユーティリティ ライブラリのフリー関数である可能性があります。