Après une discussion tout a fait cordiale avec un ami, v'la qu'il me dit qu'il ne comprends pas cet engouement pour le développement orienté objet et que finalement, il y a tout un historique avec la programmation procédurale, que ça a très bien fonctionné en son temps et que finalement, on peut tout aussi bien faire en procédural ce qu'on peut faire en objet.
Dans mon application, je souhaite vérifier que tous les objets que je stocke en session sont tous correctement initialisés. Si au moins l'un d'entre eux n'est pas initialisé correctement, je dois faire une redirection dans mon controller. Voyons comment je peux m'en sortir avec les tags du container de Symfony.
En français, on dit linéariser... Voyons comment on peut stocker un objet.
Crédit : Morguefile.com
To check out a tab, we only need one field in a form. If the amount paid is less than the invoice, it is impossible to checkout the tab. If the amount paid is more than the invoice, we count the difference as a tip.
Crédit : Morguefile.com
Pour encaisser la note, il n'y a qu'un seul élément de saisie de formulaire (input text). Si le paiement (donc le montant saisi) est inférieur, la note n'est pas soldée, on refuse de clore la note. Si le paiement est supérieur, on considère que la différence est le pourboire.
Crédit : Morguefile.com
Service is running. Prepared food is served. Ordered drinks are served. As they are served, the application is counting the bill. Our clients are done. They want to close the tab... pay the bill.
Crédit : Morguefile.com
Le service se fait. Les boissons commandées, les plats préparés sont servis les uns après les autres. Doucement, le total des éléments servis s'additionne. Maintenant, les clients souhaitent quitter la table... Et payer la note.
Crédit : Morguefile.com
Now our staff can see in one look the list of drinks and food to be served, per table number. We have two different events. Let's listen to them.
Crédit : Morguefile.com
Le staff peut à présent voir en un coup d'oeil la liste des boissons et des plats à servir, par table. On a vu ensemble que les plats servis et les boissons servies ne déclenchaient pas tout à fait le même événement. Voyons à quoi s'en tenir désormais dans nos observers.
Crédit : Morguefile.com
Food is prepared, drinks are ordered... all they are waiting for is to be served. This is the waiters job. And we do have several waiters in the cofffeebar. So we need to assign the right todo list to the right waiter. We wouldn't assign a tab to a waiter who are not in charge of that table, right ?
Crédit : Morguefile.com
Les boissons sont commandées, les plats sont préparés, il reste à les servir. C'est la tâche des serveurs. Cette fois-ci, l'équipe est composée de plusieurs serveurs. Il faut donc préparer une liste par serveur, toutes leurs tables confondues.
Crédit : Morguefile.com
Now food is prepared and ready to serve... The 'foodPrepared' event has been triggered. But we know it well by now, nothing will ever happen if nobody is listening to this event. So now, let's add some listeners... ok, we (almost) know which listeners, but what about callbacks ?
Crédit : Morguefile.com
Les plats sont préparés et prêts à servir. L'événement 'foodPrepared' a été déclenché. Voyons ce qu'il déclenche dans nos différents observers.
Crédit : Morguefile.com
The chef knows what he has to do. The list of items to prepare are now displaying on screen. Once the chef has prepared an item, he needs to advise the staff that the item can now be served.
Crédit : Morguefile.com
Maintenant que le chef accède à la liste des plats à préparer, il faut que le chef puisse marquer les plats qui ont été préparés et qui sont désormais prêts à servir.
Crédit : Morguefile.com
In our previous chapters, food and drinks have been ordered. Though a drink can be served immediately, food has to be prepared before being served. It is the chef job to prepare food. Today, let's see how to display the chef todo list : what food he has to prepare.
Crédit : Morguefile.com
Dans les articles précédents, les boissons et les plats ont été commandés. Une boisson peut être servie immédiatement mais un plat doit être adressé à la cuisine pour être préparé. Le plat pourra être servi uniquement lorsqu'il sera prêt. Dans l'article d'aujourd'hui, nous allons gérer la todo list du chef et afficher la liste des plats commandés.
Crédit : Morguefile.com
When we place an order, two events are triggered. One event advising the drinks have been ordered and the second event advising the food has been ordered. Based on the initial workflow, the food and drinks do not follow the same process. Let's see how to differentiate each process.
Crédit : Morguefile.com
Lorsqu'on place une commande, deux événements sont déclenchés. Un premier événement qui signale que les boissons sont commandées et un second événement qui signale que les plats sont commandés. Selon le workflow défini initialement, les plats et les boissons ne suivent pas le même traitement. L'article d'aujourd'hui mets en place - du moins pour le début - les deux traitements différents.
Crédit : Morguefile.com
We have now created our place order form, with that nice repeat-my-fields feature in the previous chapter. In today's chapter, we will process the form, binding it to an object and, of course, triggering our events.
Crédit : Morguefile.com
Le formulaire pour passer la commande est créé et fonctionne convenablement. Dans l'article d'aujourd'hui, nous verrons comment on va associer le formulaire avec un objet et de cet objet, comment on va réussir à déclencher nos événements.
Crédit : Morguefile.com
Our application is taking shape more and more. We have already built our main components and services. We have dumped unceremoniously the items from the cache. Now let's see if we can do better.
Crédit : Morguefile.com
Notre application se structure de mieux en mieux. Nous avons nos principaux éléments et services désormais en place. Nous avons effectivement triché en affichant les éléments du cache de manière un peu... violente. Mettons maintenant les choses en forme pour un rendu plus sérieux.
Grâce à la programmation orientée objet, combinée aux différents modèles de conception (Design patterns), il est aisé d’établir des séparations nettes entre les différents éléments d’une application. Toutefois, toute cette liberté me laisse perplexe.
Crédit : 20th century fox
En suivant les principes SOLID et en me basant sur les réflexions de Rob Allen et de Matthew Weier O'Phinney, je vais vous présenter le modèle objet que j'ai choisis de monter.
Crédit : 20th century fox
Quand j'ai commencé le développement orienté objet, notamment dans le cadre du modèle MVC, je me suis rapidement heurté à cette interrogation : qu'est ce que le MODELE ? Et au delà de sa définition, comment on construit un modèle ?
As you ought to know by now, i'm currently discovering the MVC pattern. For someone who wrote few php websites in procedural way, i can hold the Controller and the View concept. The View is the templating part. The Controller is the old index page I used to code with the switch case instruction which would include the correct php script depending on the HTTP request. Plus, the coding / relationship of the View and the Controller are obvious while using Zend Application. It’s maybe too obvious but we may want to see this bound later. But then : What is the third part of the MVC pattern ? What is a Model ??