Java: MVC et classe anonyme pour le contrôleur

Deuxième option

Si vous utilisez vos contrôleurs en tant que classes internes anonymes, comment allez-vous tester votre couche de contrôleur? Si vous ne séparez pas vos contrôleurs, vous ne pourrez pas vous moquer à des fins de test.

Même si vous ne voulez pas écrire de tests, la première option va créer un couplage très dur entre les Vues et le Contrôleur. Il n'y a pas de séparation du tout!

Préférez créer explicitement vos contrôleurs et créer le interfaces pour puis avant l'implémentation. Cela rendra TDD beaucoup plus facile, et vous ferez également une meilleure conception de code dans votre projet.

, Mais rappelez-vous, c'est juste mon avis. Étudiez toujours pour vous assurer que votre décision de projet est correcte et fonctionne pour vous.

Jetez un oeil dans cet article, il a une implémentation très simple du modèle: https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm

Modifier

Comparons les deux approche.

1. la Testabilité

Classes internes : Vous ne pouvez pas tester la couche de contrôle. Tous vos contrôleurs sont des classes internes anonymes. Vous n'avez donc pas accès à then, ce qui rend impossible le test. Dans l'architecture MCV, il est vraiment important de tester vos contrôleurs. Conclusion: Vraiment mauvais pour les tests.

Explicitement classes : Vous pouvez vous moquer de la vue et du modèle afin de tester les contrôleurs. Même logique va quand test de la Vue et du modèle. Conclusion: Facile à tester.

1. la Maintenabilité

Classes internes : Toute votre logique de contrôleur est à l'intérieur de vos classes internes anonymes (ou lambdas). Faites-moi confiance, vous ne voulez pas que. Toute la complexité de votre application sera à l'intérieur d'une classe qui n'était pas destiné à devenir gros. Un exemple simple:

//I need to get the people older than 50 years old, present to the user and wait for a click. If the list is empty, do something, if it's not do something else.

      buttonRefresh.onClickListener(() -> {
          List<Person> people = model.requestPeople();

          people = people.stream()
                      .filter(p -> p.getAge > 50) 
                      .collect(Collectors.toList())

          [code to create an adapter]

          if(people.isEmpty()){
             [do something...]
          } else{
             [do something else...]
          }

      })

C'est un code très simple et cela devient déjà déroutant. Et si j'ai un autre lambda dans mon if et else?? Le plus votre code grossit à l'intérieur d'une classe interne anonyme, le pire. Conclusion: C'est mauvais pour la maintenabilité car votre code va se développer au mauvais endroit.

Explicitement classes : Vous pouvez coder à l'intérieur d'une classe. Vous pouvez y ajouter des dépendances, créer des méthodes, avoir des classes internes...

1. la Séparation des responsabilités

Classes internes : Il n'y a pas de couche de contrôleur, pour être vrai. Tout le code du contrôleur est à l'intérieur vos classes de vue, donc la Vue et le Contrôleur et fondamentalement les mêmes classes. En conséquence, vous allez avoir des classes de vue vraiment énormes avec beaucoup de code désordonné. Conclusion: Mauvais, presque tout le code de votre application va être dans les classes View.

Explicitement classes : Le contrôleur et la Vue ont une séparation très claire. Votre vue n'aura que des méthodes pour la mettre à jour.

(je sais que vous allez créer beaucoup de méthodes essentiellement 1-3 lignes de code dans les classes de vue. Mais c'est mieux que d'énormes méthodes avec une logique de vue et de contrôle au même endroit.)

C'est ce que je pense. Mais vous pouvez toujours essayer les deux approches et comparer les résultats!