Qu'est ce qu'un bon code objet?

A moins de vivre dans une grotte souterraine, retenu par un troll exhibitioniste à la recherche d'une vierge, vous devez actuellement avoir adopté la poo (programmation orientée objet) dans vos applications php ou autres.

Adopter la poo c'est bien, mais, au fil de mon expérience, je me suis rendu compte que très peu de développeurs, même après 10 ans d'expérience savent réellement décrire ce qu'est un bon code objet.

Pour preuve, prenons l'exemple de php, dans ce langage (et d'autres aussi), il est traditionnellement admis (à tord), qu'un objet est une classe regroupant un ensemble de méthodes, et que pour utiliser cet objet, il suffit de le construire et de faire appel à ses méthodes!
Monumentale erreur cher philosophique, ceci est une vision unilatérale abstraite de la poo.

Un objet en programmation est identique à un objet de la vie réelle.
Pour bien coder objet, il est nécessaire de comprendre l'intéraction avec les objets du quotidien qui nous sont utiles.

Cas concret : notre téléphone portable.

Un téléphone portable n'est rien d'autre qu'un ensemble de composants dont l'utilité première est de nous permettre de communiquer avec autrui, à distance.
L'intéraction entre humains, à distance, est donc le but de l'existence de notre objet. Sans intéractions il n'y a pas de notion d'objet, et celà doit être pareil en programmation (une classe qui ne communique qu'avec elle même n'est pas un objet).

Mais comment notre téléphone portable intéragit-il avec nous?

Notre téléphone portable peut avoir une taille et une forme variables, il peut avoir un clavier physique ou non, une antenne externe ou non, c'est ce qu'on va appeler les propriétés de notre objet.
Par contre, il va implémenter ce qu'on appelle, une interface graphique (visuelle) qui va nous permettre d'utiliser ses composants pour mieux communiquer.
Dans nos smartphones modernes, cette interface va prendre la forme d'un os (Android, Ios, Windows phone etc...). Il peut y avoir des milliards d'interfaces différentes, mais toutes auront le même objectif final... communiquer.
Une interface implémente elle même x interfaces pour communiquer avec ses interfaces.

Un bon code objet est donc, un ensemble de méthodes (classe) implémentant des interfaces, pour communiquer dans un seul objectif.

Ce qui nous ramène aux principes de bon sens SOLID, que je vous invite à découvrir ici http://philippe.developpez.com/articles/SOLIDdotNet/.

Edouard Kombo

Pourquoi vous ne devez plus accéder directement aux variables superglobals en php?

Un jour, j'ai été reçu en entretien par un acteur majeur de la communauté open-source, celui-ci m'a posé une question particulière qui est restée gravée dans ma mémoire...

"Quelle est la principale alternative d'accès aux variables superglobales en php?".
Et là, blanc total, suivi d'un humble "je ne sais pas", après quoi il ajoute "si vous ne savez pas, ce n'est pas grave, peu de gens savent que l'accès direct aux superglobales tend à être déprécié depuis php 5.3.".

Et hop, plus tard sur google, quasiment rien sur la dépréciation des superglobales, mais, une info resurgit, et là je saisis mieux pourquoi il ne faut plus accéder directement aux variables superglobales.
Je vous fais donc partager mon expérience.

Pourquoi vous ne devez plus accéder directement aux variables superglobals en php?

Pour ceux qui ne savent pas ou plus (on ne sait jamais), ce qu'est une variable superglobal, voici un excellent tuto ici: http://php.net/manual/fr/language.variables.superglobals.php

L'un des points faibles de php se pose sur la sécurisation des variables transmises par un utilisateur, c'est aussi un passage obligé pour tout développeur à chaque conception d'application, et, parfois un casse-tête qui nous coûte un temps précieux.
Il existe même une pléthore de classes partagées, utilisant des filtres d'échappement de caractères spéciaux et j'en passe.

Le seul problème est que, chaque développeur a sa propre méthode de sécurisation des superglobales, quand par exemple PDO dispose d'une méthode unique de sécurisation des variables, totalement transparente du point de vue utilisateur.

Depuis php 5.2, a été introduit une fonction native qui fait le travail pour nous (pas totalement, mais presque), filter_input.
Oui, depuis php 5.2 me direz-vous, çà date, mais tout le monde ne le sait pas forcément, et j'en faisais parti.

Cette fonction permet de:

1. Valider (FILTER_VALIDATE), s'assurer que la donnée transmise correspond aux critères spécifiés.
2. Sécuriser (FILTER_SANITIZE), supprimer les caractères non désirés, appliquer des contraintes spécifiques. retourner l'intégrité des variables superglobales.

Par exemple, pour récupérer une variable post transmise par un formulaire, on écrira ceci:

<?php $my_string = filter_input(INPUT_POST, ‘my_string’, FILTER_SANITIZE_STRING); ?>

On pourra aussi choisir de ne pas protéger la variable en écrivant ceci:

<?php $my_string = filter_input(FILTER_POST, ‘my_string’, FILTER_UNSAFE_RAW); ?>

Ca paraît plus complexe de prime abord, mais les avantages à utiliser cette fonction sont très nombreux:

1. Rapidité d'exécution, php sécurise et valide pour vous.
2. Uniformisation des méthodes.
3. Refactoring simplifié sur des projets à fort turnover.
4. Centralisation des processus de sécurisation, validation/non validation.
5. Validation multi-critères et personnalisée avec fonctions de callback.

... 

Pour plus d'infos, rendez-vous sur la doc http://fr.php.net/filter_input

Maintenant que vous connaissez les nombreux avantages de filter_input, rendez cette méthode obligatoire tant que possible, c'est une question de logique et de bonne pratique :).

Edouard kombo.

TDD, BDD, DIRTI, quelle méthode de programmation adopter?

Ces dernières années, de nouvelles méthodologies révolutionnent notre manière de penser l'architecture de nos programmes (java, php etc).

Pour en citer quelque uns, nous avons vu apparaître:
- le développement piloté par les tests (Test Driven Development), introduit par les tests unitaires (phpUnit, Atoum...).
- le développement piloté par le comportement (Behavior Driven Development) avec entre autres Behat.

Sans ré-expliquer ces concepts, ce que d'autres ont excellement déja fait, le premier nous incite à développer nos tests avant nos méthodes, ce qui implique une excellente compréhension de l'architecture finale de l'application, quand le second nous permet de générer du code à travers les spécifications (comportement) de l'application, ce qui a pour avantage de faciliter le dialogue entre tous les intervenants du projet (les stakeholders).

Toutes ces méthodes sont aujourd'hui reconnues comme de bonnes pratiques de développement, mais, elles ont pour inconvénient de se concentrer plus sur la valeur du code (code value), que sur la valeur métier (business value).
Traduction, avec ces méthodes, mon code sera propre, standard, mais il ne fait pas encore ce pourquoi je le crée.

Vous l'aurez compris, dans certaines situations, notamment lors de short deadlines, ce qui arrive ne nous mentons pas, très souvent, ces méthodes peuvent devenir contre productives, ou, il peut simplement arriver que l'architecture de notre application soit si complexe que nous ne savons pas quelles fonctionnalités, méthodes exactes devront être utilisées dans notre application.

Pour pâlier à ce problème, je vais vous présenter la méthode DIRTI, (introduite par Anthony Ferrara) prononcer comme dirty.

D pour develop.
I pour isolate.
R pour refactor.
T pour test.
I pour integrate.

La méthode dirti, signifie littéralement s'entraîner comme un cowboy pour tirer comme un sniper... on code d'abord, on pose les questions ensuite.

Dans la pratique cela se traduit ainsi:
1. On code ce que l'on peut coder du moment qu'on a quelque chose de fonctionnel rapidement (la valeur métier).
2. On relit notre code, pour isoler les points d'abstractions.
3. On refactorise notre code en séparant les différentes couches isolées précédemment.
4. On refait ce process autant que nécessaire jusqu'à compréhension parfaite de l'architecture de l'application.
5. Une fois, les couches d'abstraction isolées, on écrit nos tests unitaires.
6. Une fois les abstractions testées, on les intègre dans notre application.

Vous l'aurez donc bien compris, la méthode dirti ne remplace ni les tdd, ni les bdd, mais vient en complément dans certains cas de figure.
Elle a pour avantage de produire du code fonctionnel d'abord, pour mieux affiner sa vision de l'application, avant de correctement refactoriser et normaliser son code.

Edouard kombo.