oop - 分類の難問のためのアーキテクチャの計画に支援が必要

Question

実際のコーディングの質問というよりも、「何をするのか」という質問があります。それは私が現在取り組んでいるプロジェクトに関連しています。このプロジェクトでは、複数のマーケットプレイスAPIを1つのインターフェースに結合することを任務としています。各APIには、製品を分類する独自の方法があります。私たちが調べているすべてのAPIの最上位の親カテゴリは、多少の違いはありますが、ほぼ同じです。ただし、サブカテゴリは大きく異なります。

たとえば、あるAPIでは、カテゴリを選択するために長いパンくずリストが必要です。たとえば、スポーツ>球技>ニューイングランド>サッカー>アクティブチーム>ペイトリオッツ>メモラビリアなどです。別のAPIには2つのレベルの分類があります：スポーツ>ペイトリオッツ記念品。多くの場合、他のAPIのサブカテゴリとはまったく関係のないサブカテゴリがあります。

それで、問題は-インターフェースを設計するときに取るべき最良のアプローチは何ですか？現在、2つの可能性の間で取り組んでいます。

1）クライアントでカスタムカテゴリUIを設計し、ユーザーが選択した選択肢に基づいてさまざまなAPIのニーズを並べ替えることができるロジックをサーバーに組み込みます。

2）ユーザーが個々のAPIごとに必要な手順を実行する必要があるような方法でUIを作成します。ユーザー設定によっては、これは、API固有の情報を5、6、10回以上入力する必要があることを意味します。

オプション番号1は実際のプログラミングの悪夢であると言われていますが（私が示した例はAPIデータフィールドの変更です）、オプション番号2は顧客を怒らせると強く感じています。

そこに何かアイデアはありますか？

Answer 1

これは非常に難しい問題です。「オントロジー製品分類」を検索すると、このトピックに関する多くの研究論文やディスカッションが見つかります。一方が他方のより詳細なバージョンである場合、それは非常に実現可能ですが、あなたの説明はそうではないことを示唆しているので、独自の分類スキームを構築し、他のものをそれにマッピングする必要があります。

異なる製品カテゴリ間のマッピングを検証できる共通のキー（UPCコード？またはその他）がありますか？もしそうなら、あなたはあなた自身の分類スキームを構築し、そしてそれから他のものをそれにある程度の成功でマッピングすることができるかもしれません。

明らかに最初のオプションは消費者にとって最良ですが、そのようなマッピングを構築することは非常に困難で非常に時間がかかる可能性があり、定期的な更新が必要になります。

1つのアプローチは、提供されているどの階層よりも単純な階層を構築することです。階層が単純になると、ほとんどが単純に包含されるため、カテゴリを階層にマッピングする[ほとんど手動の]作業がはるかに簡単になります。これはユーザーエクスペリエンスを悪化させる可能性がありますが、優れた検索機能と優れた「関連製品」/「これを購入した人もこれを購入した」ツールを製品ブラウジングエクスペリエンスに追加すると、階層の不足を補うことができます。

Answer 2

ナンバーワンは悪夢のような悪いことではありません。ユーザーエクスペリエンスは最優先事項です。決してそれを忘れないで。ユーザーがより短いルートをナビゲートするのが簡単な場合は、その機会をユーザーに与えます。また、APIを抽象化でラップするので、コードはAPIについてまったく認識せず、抽象化レイヤーについてのみ認識します。このようにして、APIを変更し、ほとんどのコードをそのままにして、抽象化レイヤーのみを変更できます。

セッションを使用してページ間でデータを渡し、ファクトリを使用して、セッションデータに基づいてエントリ時にページの状態を作成します。これにより、ページ、状態、およびユーザーデータ間のコンテキストが強化されます。

第1レベルのオブジェクト（ページが直接通信するオブジェクト）をページのコンテキストに保持します。これは、問題を診断するときに役立ちます。

最も重要なことは、抽象化レイヤーの一連のテストを作成して、すべてのオブジェクト、関数、および入出力のペアをテストし、アプリケーションが堅固であることを確認することです。

Answer 3

あなたはあなたのクライアントに一貫した変わらないインターフェースを提供しなければなりません。

あなたが考えている2つの異なるアプローチの例を見てみたいと思います。

API.find( PRODUCT, CATEGORIES_LIST )