サブクラスvsエクステンションvsインナークラス

Question

私はQuizlet APIとやりとりしています。私は自分のコードを構造化する最良の方法を議論してきました。 Quizlet APIには、Sets,Classes、Userなどの複数の機能があります。私はこのためにAPIClientsを作成しようとしていますが、私はクライアントをモデリングするためのより良いソリューションを見つけたり、これらの潜在的なソリューションの中から最良のソリューションを選択するのに苦労してきました。

解決方法1： はsuperclassと呼ばれるQuizletManagerを作成し、すべてのサブクラス全体に便利ですclientID、access codesなどの基本情報、および関連情報を格納します。次に、QuizletSet、QuizletClassなどの個別のsubclassesを作成して、セット、クラス、および関連情報の取得を処理できます。実際にデータを取得する必要があるときは、恐らくQuizletManagerと呼ぶことはありません。しかし、私はQuizletSetの新しいインスタンスと関連するクラスを作成してネットワーキングを行います。

解決方法2： その関連サブクラスのすべてに再びQuizletManagerスーパークラスを作成します。しかし、今回は、Setに関連するすべてのサブクラスとそのすべてをQuizletManagerクラスでインスタンス化し、情報を取得するときにサブクラスを呼び出すQuizletManager内のメソッドを使用しました。 この場合、私はいつもQuizletManagerとQuizletManagerと呼ばれ、実際に情報を取得するためにサブクラスを使用します。

解決策3： 拡張機能は、基本的にSetsを取得する機能と関連情報を追加する機能が含まれているだろうなど、QuizletManagerクラスを作成し、Setsをフェッチする機能を追加し、それより読み使用拡張するために、Classes 。

解決策4： このソリューションでは、クラス内にクラスがあります。

あなたの前の例のそれぞれにおいて

class QuizletManager { 
    var clientID: String 
    // Other related properties important for sets, classes, etc. 
    class SetClient: APIClient { 
     // Fetch related info for sets. 
    } 
} 

Answer 1

、あなたは階層に結合された、または単一クラスの拡張機能として、すべてのAPI関連の呼び出しを配置し​​ている。基本的に、私はちょうどこのような何かを持っていると思います。これにより、コードの柔軟性が低下し、保守が困難になる可能性があります。あなたのために働くかもしれない1つの解決策は依存性注射を使用することです。

ここでコードを構造化する方法の例を示します。

struct QuizletAPICredentials { 
    var clientID: String 
    var accessCodes: [String] 
    //etc... 
} 

class QuizletSetClient { 
    var credentials: QuizletAPICredentials 

    init(credentials: QuizletAPICredentials) { 
     self.credentials = credentials 
    } 

    func fetchSets(...) { 
     //get data... 
    } 
} 

この情報が役立ちますようお願いいたします。 ： - ]