Création et référencement de sites internet - centre de formation

Infogérance, intranets, sites web et formations: actualités et tutoriels

Forum PHP 2013 : nous y serons!

  • PHP
Pas moins de 3 membres de Pulsar seront présents pour cette édition 2013 du forum PHP qui s'annonce riche en perspectives!Il reste encore quelques places, si vous ne vous êtes pas...

Lire la suite

RDV AFUP sur les bases de données relationnelles : PostgreSQL et optimisations mySQL

L'antenne parisienne de l'AFUP, que j'anime avec Christophe et Amaury a organisé jeudi dernier un RDV sur les BDD relationnelles. Le dernier en date était celui sur les design pattern et anti pattern, et il faut avouer, qu'il date un peu ! On s'était un peu « endormis » (<=> surchargés de boulot), on va essayer de reprendre un rythme plus régulier. Si vous avez des idées de RDV, que vous voulez organiser une soirée, ou sponsoriser, surtout n'hésitez pas à nous contacter à ce sujet (sur twitter @afup_paris, ou par ce formulaire) !

La soirée de jeudi dernier quant à elle s'est très bien déroulée, une ambiance sympa comme toujours, des conférenciers dynamiques et un apéro barbecue offert par SkySQL avec Linagora dans une ambiance...euh ...rythmée ! En s'éloignant de la sono, ça allait ;)

Voici un bref retour des conférences :

Lire la suite

Retour sur la soirée design pattern et anti pattern en PHP

  • News

Présentation théorique des design pattern

La soirée a débuté par une présentation théorique des design pattern par Julien Pauli, avec définition de ce qu'est un design pattern :

Un patron de conception (design pattern) est un arrangement caractéristique de modules, reconnu comme bonne pratique en réponse à un problème de conception d'un logiciel. Il décrit une solution standard, utilisable dans la conception de différents logiciels.

Puis des principes SOLID sur lesquels sont basés les design pattern :

  • Single responsability : pas trop de responsabilité pour une seule classe
  • Open/Close Principle : ouvert à l’extension, fermé à la modification
  • Liskov Substitution : un objet peut utiliser le fils de A sans s’en rendre compte (Héritage strict, et type conservé)
  • Dependecy Injection : Si un objet A a besoin d’un objet B , ce dernier doit lui être injecté, il ne doit pas aller le chercher lui-même (donc pas de new Toto à l’intérieur d’une classe)
  • Interface aggregation : A ne doit pas utiliser B directement mais une interface de B

Lire la suite