Technology Management & Leadership

J’aime beaucoup le refactoring. Ça n’a pas toujours été le cas! Pendant longtemps, j’ai cru que la façon la plus efficace d’écrire du code était de parfaitement conceptualiser l’ensemble de l’application. Un jour, pourtant, je me suis rendu compte qu’il était peut-être sage de commencer à écrire du code tôt. En effet, on peut ainsi mitiger certains risques, avoir un feedback fonctionnel plus rapide, et permettre d’établir certaines bases de travail pour une équipe.

D’un autre côté, je ne peux pas dire avoir complètement abandonné l’espoir de voir une conception solide, suivie d’un développement qui ne change vraiment qu’en surface. J’ai vu et revu le coût monstrueux d’une mentalité dans laquelle le refactoring est la réponse à tout. Écrire du code de mauvaise qualité dans la seule optique de le réécrire différemment (pardonne-moi Martin Fowler, je sais que ce n’est pas le réel esprit du refactoring) est peu productif et démotivant. Comment donc arriver à rallier résultats rapides et bonne conception? Laissez-moi présenter les racines d’une approche qui n’est ni particulièrement nouvelle ou impressionnante, mais qui fait ses preuves. Appelons ça, si vous le voulez bien, la programmation organique.

Pourquoi “programmation organique”? Simplement parce qu’on fait en sorte que l’évolution du code dans le temps se comporte comme lorsqu’on plante un arbre. La structure interne de l’arbre reste invisible et relativement stable, mais de l’extérieur la taille et la forme changent. Quant à nous, nous ne pouvons que sélectionner l’endroit où le planter et lui donner des guides.

L’élément technique central de la programmation organique est l’interface. Oui, je parle des interfaces de programmation! Celles-ci n’ont rien de nouveau et rien d’extraordinaire; je vous avais averti! Ces interfaces délimitent l’espace de chacune des plantes que composent un ensemble de classes. En tout temps, le code est écrit de la manière la plus agile qui soit, mais les interfaces seront toujours incluses dans un processus de conception solide. Quels sont les impacts d’une telle approche?

• La structure de l’application sera toujours solide
• Les impacts d’un code de mauvaise qualité ou temporaire sera mitigé
• Une liberté de développer en mode brouillon dans un contexte carré de sable

Les motifs de conception Pont et Fabrique sont beaucoup utilisés dans cette approche. Voici un exemple simple démontrant comment appliquer cette pratique.

Vous désirez développer une interface utilisateur dans laquelle on utilisera un champ texte pour entrer un chemin vers un dossier. Si le dossier existe, un bouton sera activé. La manière facile de faire ce formulaire est de placer un TextBox et un Button dans un Form, d’attacher un comportement OnTextChanged au TextBox qui modifiera simplement le Button.Enabled en fonction de l’existence du dossier. Cette approche, quoique fonctionnelle et rapide, causera certains problèmes si, en aval dans le développement:

• Le champ texte est séparé en deux (Dossier de base, et dossier relatif)
• Il y a plusieurs boutons à activer (un dans le formulaire et un dans une boîte à outils)
• On désire afficher un message qui décrit pourquoi le dossier est invalide
• On désire remplacer le TextBox par un autre type de contrôle
• On désire enlever le TextBox et utiliser directement une variable (boîte de dialogue)
• On désire ajouter d’autres validations spécifiques
• etc.

Toutes ces situations causent un changement de structure qui finit généralement par dégénérer. Voici donc comment la programmation organique peut réduire les impacts de tels changements.

Premièrement, on désire cacher le TextBox. Celui-ci peut changer, et de toute façon tout ce qui nous intéresse de celui-ci, c’est sa valeur finale. Voici donc l’interface:

public interface ITextBridge
{
  string Text {get; set;}
}

Voici l’implémentation de cette interface dans notre contexte:

public class TextBoxTextBridge : ITextBridge 
{
  private TextBox _textBox;

  public TextBoxTextBridge(TextBox textBox)
  {
    _textBox = textBox;
  }

  public string Text
  {
    get { return _textBox.Text; }
    set { _textBox.Text = value; }
  }
}

Il n’y a rien de très compliqué, mais notez qu’on a complètement découplé le champ texte de son utilisation. Si les besoins changent, on peut très bien remplacer l’implémentation pour utiliser deux champs texte concaténés, deux champs texte utilisés selon une condition ou une variable sans modifier l’interface. Faisons la même chose avec le bouton à valider:

public interface IValidationTarget
{
  void Success();
  void Failed();
}

Notez que cette interface aurait pu être différente. On aurait pu passer un message aux méthodes Success et Failed, ou n’avoir qu’une méthode qui prend un ValidationResult mais pour le moment ça sera suffisant. Pour mieux visualiser comment l’utiliser, voici l’implémentation:

public class ButtonValidationTarget : IValidationTarget
{
  private Button _button;

  public ButtonValidationTarget(Button button)
  {
    _button = button;
  }

  public void Success()
  {
    _button.Enabled = true;
  }

  public void Failed()
  {
    _button.Enabled = false;
  }
}

Maintenant on est prêts à utiliser ces deux classes ensemble. On veut pouvoir changer la source et la cible, mais aussi la validation elle-même! Voici donc l’interface qui nous intéresse:

public interface IMyActionValidator
{
  void Validate();
}

Plutôt simple, n’est-ce pas? Voici, encore une fois, l’implémentation:

public class DirectoryExistsMyActionValidator
  : IMyActionValidator
{
  private ITextBridge _textBridge;
  private IValidationTarget _validationTarget;

  public DirectoryExistsMyActionValidator(
    ITextBridge textBridge,
    IValidationTarget validationTarget
    )
  {
    _textBridge = textBridge;
    _validationTarget = validationTarget;
  }

  public void Validate()
  {
    if (Directory.Exists(_textBridge.Text))
      _validationTarget.Success();
    else
      _validationTarget.Failed();
  }
}

Jusqu’ici tout va bien? Si c’est le cas, on a presque terminé! Tous nos éléments sont en place, et on est prêts à intégrer le tout. Je n’utiliserai pas de Fabrique ici pour démontrer l’impact direct de l’utilisation massive des interfaces. Il nous faut premièrement un membre dans le Form, comme celui-ci:

private IMyActionValidator _validator;

Quelque part dans l’initialisation du Form, il faudra simplement créer la validation de cette manière:

_validator = new DirectoryExistsMyActionValidator(
  new TextBoxTextBridge(textBox1),
  new ButtonValidationTarget(button1)
  );

Il ne manque plus que l’appel! Dans l’événement TextChanged du TextBox, appellons directement:

_validator.Validate();

Évidemment, nous pourrions pousser plus loin cet article pour utiliser des fabriques qui attacheraient automatiquement le TextChanged à un module de gestion d’événements, mais je crois que l’exemple démontré ci-dessus décrit bien comment développer une structure malléable, mais toutefois solide, qui permet de facilement “coder comme ça vient” sans mettre en jeu le coût de maintenance à long terme.

Quoique cette exemple soit simpliste, son application représente bien la méthode qu’est la programmation organique. De plus, on peut appliquer cette théorie récursivement! Pour un groupe d’interfaces, il est toujours possible de cacher l’ensemble derrière une facade, qui jouerait le même rôle que le pont avec le TextBox. Je répète que malgré le drôle de nom que je lui ai affublé, il n’y a rien de nouveau dans cette technique. C’est une approche, munie de ses avantages et ses inconvénients, que j’ai eu l’occasion d’expérimenter avec succès plusieurs fois par le passé.

Si vous avez des commentaires, positifs ou non, sur cet article, ou si vous avez eu l’occasion de l’essayer et voulez me donner votre avis, je vous invite à laisser un commentaire!