J'essaie d'apprendre une architecture propre dans le développement Android. J'ai lu cet article: RecyclERView Multi Type sans casting
Tout va bien, mais dans mon projet, je dois obtenir la réponse d'une API, puis je dois créer une liste d'objets à plusieurs types P>
Ceci est mon code actuel: P>
val type = api.response.member.type
if (type == "secretary") {
createSecretaryDepartmentInstance()
} else if (type == "head") {
createHeadDepartmentInstance()
} else if (type == "security") {
createSecurityInstance()
} else if (type == "teacher") {
createTeacherInstance()
} else if (...) {
...
}
and so on ...
...
..
.
3 Réponses :
Son ignenclipe non affecté. Pretty Optimize peut-on faire du code ci-dessus comme
Je ne sais pas pourquoi votre réponse a eu un vote en bas. J'ai fait un peu de modifier à ma question pour le rendre plus clair. Merci
Autant que je sache, votre code traite une réponse de certaines API, qui peut être n'importe laquelle du "secrétaire", "Head", "Sécurité", "Sécurité" et quiconque sera ajouté à l'avenir. Il agit comme une usine qui crée un objet de type spécifique basé sur les données de la réponse.
Qu'est-ce que cela signifie être ouvert? Cela signifie que vous pouvez soutenir des types de réponses supplémentaires sans mettre à jour et reconstruire ce morceau de code. En fait, la partie "fermée" du principe dit que le code devrait décourager activement les modifications en tant que moyen d'extension.
La partie qui empêche l'extension sans modification est la connaissance des types spécifiques. Si vous le voulez bien fermé - éloignez-vous de ces connaissances. Vous pouvez le modifier pour savoir une certaine abstraction que tous les types spécifiques satisfaient.
Pour chaque type spécifique, vous pouvez fournir une usine avec deux méthodes: Ensuite, vous pouvez conserver une collection de telles usines d'instances individuelles. À chaque réponse, il ira sur cette collection et trouvera celui qui correspond.
Comment obtenez-vous une telle collection?
Dans votre application, il devrait y avoir une pièce de code centrale qui (généralement au démarrage) file toutes les pièces ensemble. Ce code connaît toutes les dépendances de l'application, sur des implémentations et une configuration spécifiques et sur la séquence de démarrage. Donc, cela dépend à la fois de l'élément de code abstrait et de types de réponses spécifiques. Pendant le démarrage, il peut enregistrer toutes les usines de type spécifiques avec le code ouvert fermé. Pour remplir cette collection à l'intérieur.
Une autre façon d'enregistrer ces "extensions" spécifiques est de leur donner l'instance de code ouvert et de leur permettre d'enregistrer une méthode.
Alors, il y a trois partis ici. Le module "ouvert", le module de câblage d'application et un module d'extension. Vous pouvez choisir la question de savoir si des modules d'extension connaissent l'une "ouverte", ou non - et ensuite le module de câblage fait un peu plus.
Mais retour à mon premier commentaire. Je me demande si vous avez besoin d'adhérer au principe ouvert fermé dans ce code. Si vous maintenez et distribuez à la fois tout le code dans un seul artefact et n'exposez pas cette partie «ouverte» à certains autres développeurs à utiliser ... I.e. S'il s'agit juste de votre mise en œuvre interne détail - que votre exemple original est en réalité plus simple et plus lisible. Parce qu'à partir d'un seul écran, vous pouvez voir tout de suite à quelles parties de code le contrôle ira ensuite. Il est plus facile de déboguer et de raisonner. Dotresponsematches (réponse) et CreateInstance (réponse) . Ensuite, la responsabilité de construire une instance spécifique à partir d'une réponse sera entre des mains de ce type spécifique lui-même.
Ce que vous voulez réaliser si un modèle commun à Android nommé Délégateadapter: ( https://android.jlelse.eu/keddit-part-4-RecyClerView-Delegate-Adapters-Data-Classes-with-kotlin-9248f44327f7
Pour cela, vous devrez créer une interface: puis vos membres doivent s'étendre de cette interface: maintenant Vous pouvez utiliser un modèle de conception commune, l'usine pour créer des instances de la vue en fonction de la pageDId: Vous pouvez désormais créer une liste de vitypes: < Pré> xxx
La question est de savoir si le code doit être ouvert du tout. L'exposez-vous comme une API à certains troisième développeurs et code client?
Ce code n'est pas ouvert, car vous devez modifier le code pour gérer plus de cas. Mais cela ne signifie pas que vous devez introduire un système de plugin pour soutenir ce principe. Ce code est lisible: vous voyez toute la logique dans la seule place. Vous pouvez ajouter une affaire de capture pour la robustesse. Vous savez, quels cas sont pris en charge et qui ne sont pas, juste en regardant ce code.
@itollu je ne comprends pas ton premier commentaire
@iollu merci de me faire remarquer que ce n'est pas ouvert. Pouvez-vous me dire comment la rendre ouverte?