[JAVA] refactoring d'odeur de code [classe paresseuse]

Le quatrième refactoring est la classe paresseuse.

Quelle est la classe paresseuse

Classe paresseuse. Un état dans lequel la classe est paresseuse avec peu de comportement. (Je ne comprends pas ce que signifie exister)

Pourquoi mauvais

Il n'y a pas besoin. Soyez redondant.

Modèles communs

Une structure courante consiste à créer la classe de service suivante pour le moment et à y lancer le processus.

package study.lazyclass

class PaymentController {
  def payment(amount: Int) = {
    val service = new Service
    service.pay(amount)
  }
}

class PaymentService {
  def pay(amount: Int): Unit = {
    paymentRepository.save(amount)
  }
}

Seule la méthode de paiement est définie dans la classe PaymentService. La classe Service n'a que le comportement d'une méthode de paiement.

Solution

La solution elle-même est très simple.

Fonction en ligne Vous pouvez le faire quand vous en avez besoin. Le seul moment pour créer une classe est lorsque vous avez besoin d'une classe qui organise des fonctions, par exemple lorsqu'elle est appelée à partir de deux ou plusieurs endroits.

class PaymentController {
  def payment(amount: Int) = {
    paymentRepository.save(amount)
  }
}

Je change pour appeler paymentRepository directement depuis PaymentController.

Cela suit également la loi YAGNI bien connue.

[https://ja.wikipedia.org/wiki/YAGNI:embed:cite]

Façon de penser

Voici le point de vue important de cette odeur de code.

La factorisation de classe paresseuse Reda elle-même est très facile, mais ** le fait de faire ou non le refactoring dépend de la méthode de développement. ** **

Si vous pensez à une architecture qui s'adapte dès le début, par exemple en pensant à la configuration d'une application avec une architecture en couches, il n'est pas nécessaire de refactoriser comme décrit ci-dessus.

Même si vous n'avez qu'une seule fonction, vous devez séparer et définir correctement les calques.

Par exemple, si vous utilisez une architecture en couches, vous devez concevoir les dépendances pour qu'elles soient unidirectionnelles de haut en bas, comme illustré dans la figure ci-dessous. Il n'est pas possible d'appeler le référentiel (couche infrastructure) à partir du contrôleur (couche présentation) comme du code pour le refactoring.

Par conséquent, il est nécessaire de procéder au développement tout en permettant une certaine odeur de code.

Cependant, ** Si vous pensez à l'architecture depuis le début, vous devez suivre les règles de cette architecture, donc l'écriture de code devient exiguë, donc fondamentalement, vous devriez penser à l'architecture dès le début du développement. Certains développeurs disent que non. ** **

Par conséquent, l'équipe doit réfléchir au type de méthode de développement à adopter et décider des règles de développement.

Résumé

La classe paresseuse a été refactorisée.

Merci jusqu'à la fin.

référence

• clean code
• Refactoring