Reprise du message précédent :
c'est quoi C.E. ?
 
nan, mais il y a des milieux et des comportements qui favorisent le fric rapide.
 
Le problème est le suivant : plus tu es en amont de la vente et plus y'a de fric. Donc une tonne de fric pour la pub, un peu moins pour les presales, un peu moins pour les vendeurs, encore moins pour le produit et la R&D (qaund il y en a) elle se démerde avec les universités et le fric de l'Europe.
 
Hors donc, une web agency ça bosse en avant-vente ou en vente (par rapport au client) donc personne n'a besoin d'une réelle rentabilité qui du reste n'est pas mesurable. Dans ce contexte, les web-agency reçoivent une tonne de thunes et ont des marges de manœuvres par rapport à leur clients que n'ont pas beaucoup d'autres industries. Ce qui ne conduit pas une certaine pression sur les résultats (par rapport aux autres industries, toujours), ce qui ne conduit personne à chercher de la qualité, que ce soit dans les relations humaines (bataille des égos, one minute management" ), ou dans le boulot accompli.
 
Par exemple, on ne surveille que la scalabilité des applis mais pas leur perf pure, les clients étant toujours prêt à doubler la taille du datacenter s'il le faut, ou encore on génère du code HTML de merde, tant que ça passe sur IE c'est bon, etc. etc.

C.E. = Canard Enchaîné

En quoi le contexte que tu décris implique qu'une boîte plus ou moins autogérée fera du (encore) moins bon taf qu'une autre ?

Au contraire, les employés ayant plus de poids, il accepteront moins de faire de la daube...

c'est quoi une boite autogérée ? un truc où ces qui bossent possèdent le capital style SCOP ou autre ?
 
J'en connais pas dans le web à part des travailleurs indépendant et des consultant en management.

Oui en gros.
Il y en a peu dans tous les domaines de toute façon, c'est pas tellement dans l'air du temps

y'en a surtout dans le batiment, mais avec les modes de l'agilité et de l'open-source ça pourrait venir dans le soft.

Or donc, putain

Yop (et bonne année toussa)
Question conception ( tombe bien que nraynaud traine par ici ):
J'ai:

• une classe Entreprise
• une classe abstraite Employé dont hérite une tétra-chié de classe ( Plombier, Charcutier, Boulanger ...)

Dans ma classe Entreprise je dois implémenter une methode qui me retourne la liste des employés de celle-ci.
J'ai donc fait une factory qui me retourne ma collection d'objets Employés (enfin de plombier, charcutier, boulanger ...)
 
Première question: Etait-ce la bonne solution ?
 
Deuxième chose: le constructeur de la classe Employé prend un id en paramètre. Cet id est utilisé pour faire une requête SQL qui remonte les différentes informations de l'employé  
Dans les classes héritant d'Employé la requête est modifiée ( jointure en plus sur d'autres tables, par exemple: spécialité médicale pour un medecin).
Le problème c'est que pour une Entreprise de 200 Employés, la factory fait une requête qui me remonte par exemple 200 ids, puis créé 200 objets héritant d'Employé ( et donc 200 requêtes).
Au final je fais donc 201 select et j'ai des perfs pourries.
Est-ce que j'ai merdé quelque part ou n'ai je pas vraiment d'autre choix ( sachant que oui j'ai vraiment besoin d'une collection car j'ai besoin d'utiliser une méthode de la classe Employé sur chacun d'entre eux)?
 
note: en fait je sais que je pourrais m'en sortir en une seule requête en faisant tout directement dans la méthode de la classe Entreprise mais ça me forcerait à reporter une partie d'Employé dans Entreprise et je trouve ça dégueu.
 
merci.

Bin déjà demande-toi si tu veux vraiment récupérer la spécialité de chacun à chaque fois que tu le crées. Si oui alors t'as pas le choix ; sinon, rajoute un constructeur qui ne fait pas la requête "spéciale" et fais-le appeler par ta factory.
La factory est une bonne idée mais effectivement, quand t'as des spécialisations pointues qui bouffent des perfs à chaque fois, tu te prends le revers de la médaille
Chu pas un spécialiste de la modélisation hein, c'est juste mon opinion de base sur le sujet

 
Si ça donne vraiment des perfs moisies, et que c'est une opération importante, tu peux p-e "tricher" en créant dans Employé un constructeur de copie, utilisable par ses fils, et dans chaque fils une méthode privée récupérant les propriétés supplémentaires, que tu n'appelles que lorsque tu as besoin d'une de ces propriétés la première fois.
 
Sinon tu crées pour chaque classe fille une méthode statique qui retourne tous les Employés de ce type, et dans Entreprise tu appelles toutes ces méthodes...

En fait ce que tu me dis c'est de pas faire d'Employé une classe abstraite et de retourner une collection d'employé et non pas de spécialisation
Mais j'ai besoin d'une méthode ( on va dire travaille() ) pour chaque employé et cette méthode est re-définie dans les classes spécialisées.

Je vois bien ce que tu veux dire, ce constructeur par copie ne prendrait pas un id mais le "detail" de l'employé, c'est ça?
Admettons, maintenant comment je m'assure que cette méthode ne peut-être appelée que via la factory (nan parce que j'ai aucune envie qu'elle soit utilisable par ailleurs)?

ça j'ai déjà tenté mais mais j'ai du rajouter une interface définissant cette méthode sur toutes les classes filles pour m'assurer que la-dite méthode était bien définie et pouvait être utilisée dans la factory. Je trouvais ça un peu lourdos...

 
constructeur protected dans Employé? Du coup Employé (et donc une méthode type "fetchAll"...) et ses fils peuvent l'utiliser, mais pas le reste?
 

 
pourquoi une nouvelle interface? C'est une méthode abstraite d'Employé, non?

Non, ce que je veux dire c'est : que veux-tu faire avec la liste d'employés de ton entreprise ? Si tu veux avoir toutes les spécialisations, alors avec ton design actuel, je pense pas que t'aies trop le choix au niveau des perfs (mais, je le rappelle, chu pas un pro de la modélisation).
Maintenant, si t'as juste besoin d'avoir une liste d'employés et de n'appeler que des méthodes non spécialisées, tu peux tout à fait ne récupérer que la classe abstraite (Employé, si j'ai bien suivi).

 
C'est un peu ma première solution, quoi.
Sauf qu'il lui faut un constructeur supplémentaire qui prend directement les valeurs des propriétés, sinon ça fait quand même autant de requêtes que d'objets.

Ah ba p'têt, ouais

sauf que j'en ai besoin dans la factory

Bin non vu que la méthode doit être spécialisé pour chaque classe fille.
Si je la mets dans Employé je suis effectivement sur qu'elle existera dans chaque fille, mais pas qu'elle aura été spécialisé.
Du coup j'avais mis une interface
 

C'est à peu la conclusion à laquelle j'étais arrivé... Si je maintiens la jolie conception j'aurai des perfs pourries.

Ok mais je pète la logique. Employé était définie abstraite justement pour ne pas pouvoir créer d'employé sans spécialisation. Pour faire ce que tu dis:

• soit Employé n'est plus abstraite et je peux ainsi retourner une collection d'Employé (mais du coup je peux aussi appeler le constructeur Employé de n'importe ou ( ce que je ne voulais pas)
• soit je créé une classe fille d'employé qui ne fasse strictement rien de plus qu'Employé ( et j'ai les mêmes problèmes que sur le point d'avant).

Mais de toute manière, ça ne resoudrai qu'une partie de mon problème car sur ma collection j'ai besoin d'utiliser une méthode "potentiellement" spécialisée dans les classes filles.
 

 
Bah si ta factory ne sert qu'à ça tu peux très bien la remplacer par une méthode de classe...
 

 
m'enfin quelle différence entre une méthode abstraite dans la classe mère et la même méthode dans une interface?

Ouais bon t'as raison... strictement aucune
(et du coup je trouve ça beaucoup plus propre )

edit:

Par une méthode de la classe Employé? La par contre je vois pas ou tu veux en venir!

 
bah voilà.
Et tu peux gicler ta factory et te contenter d'appeler en dur toutes les méthodes des différentes classes dans la méthode d'Entreprise qui doit tout te retourner...de toute manière c'est une notion qui appartient à l'entreprise, les différents types d'employés, non?

Pour les jointures tout ça, faudrait presque un espèce de binder qui sait comment récupérer une collection d'un type donné.
 
Genre les classes qui héritent d'employés devraient avoir une méthode statique pour fetcher tous les employés de ce type. Vite réfléchit, je ferais comme ça : Les classes ne font pas la requête dans le constructeur (beurk). Dans le constructeur, on doit filer les bonnes informations directes. Maintenant pour pas grêver les perfs, avec une classe "Boulanger extends Employé", je ferais une méthode statique qui récupère *tout* les boulangers, les construits, et les mets dans une collection qui sera retournée.
 
Donc le truc, c'est une classe qui demandent à toutes les spécialités de retourner la liste. Genre comme ça : (c'est du pseudo-code)

 
Dans le style.... Après évidemment c'est loin d'être idéal, la requête SQL ne devrait pas être dans la classe Boulanger, mais ailleurs, dans un modèle, un dataMapper, ou je-ne-sais quelle autre design-pattern qui mappe des données sur une classe...

Oui mais non
Le truc c'est que ma factory grosso modo elle fait "select salarie.id, salarie.type ...", puis en fonction du type appele les bonnes classes filles.
Du coup je trouverais un peu "bizarre" de déporter cette logique dans Entreprise.

Ce qui me gène la-dedans, c'est que les constructeurs des classes filles deviennent appelables "de partout" sans id mais avec le detail.

ce que disait Skeye

ce qui me gène dans cette solution, c'est que si j'ai 10 classes filles je vais faire 10 requêtes, alors que peut-être je n'ai qu'un seul type d'employé dans la-dite entreprise.
Mais sur l'idée tout le monde semble d'accord

Mieux vaut 10 requêtes, une pour chaque type, que 200, une pour chaque employé. Maintenant j'ai juste donné les grandes lignes, faudrait avoir une liste de type d'employés, avec le nombre dans l'entreprise, comme suffit de faire les requêtes où le type est présent

Rien ne t'empêche de faire d'abord un count(*) groupé par type d'employé et de n'aller chercher que ce qui ne retourne pas 0...

deHors les intégristes de l'orthographe qui utilisent des gros mots bordel
 
quand on prétend utiliser un registre, on s'y tient

Bah ça a plus vraiment de sens, ton histoire...ça donnerait un truc du genre :

Tout ce que fait l'entreprise c'est demander à toutes les classes d'employés de lui retourner tous leurs employés...une factory pour ça, je vois pas l'intérêt en fait...

Je suis d'accord, donc si tu veux utiliser "or donc", ortographie-le correctement

HORS donc ta gueule
 
on dirait un débat sur "autant pour moi"

"autant pour moi", c'est de la pinaillerie à 2 balles montée en épingle par une mode débile d'Internet Sur 10 types qui font cette "correction", y en a 9 qui savent pas quand utiliser l'infinitif ou le participe passé pour les verbes du 1er groupe
Alors que or/hors, c'est vraiment le truc de base que t'apprends en CE2 avec les autres conjonctions de coordination... C'est p'têt un des trucs qui me fait le plus chier, avec "connection"

D'ou ma 1ere question :

Bah t'as ma réponse.

mais t'es relou

et OK c'est 0 killed.

ça c'est satan à l'envers    
 
tu me veux du mal ?

 
T4AS BIEN RAISON

Non, chu gentil Schaos qui le dit

vos gueules

C'est vendreday !?  

Putain mais quelle bande de laids chez MySQL
Version GA : 5.0.51
Binaires downloadables : 5.0.45
"Stu veux la 5.0.51, tu te la compiles toi-même mais elle est en GA"

Ca serait pas grave si y avait pas un gros bug dans la 5.0.45 (le group_concat sait pas gérer les champs en UTF-8 ) qui est corrigé dans la 5.0.51.
Ce serait juste chiant si y avait bien les fichiers de projet Visual pour pouvoir compiler sous Windows. Mais non, ils y sont pas.
 
L'échec

par contre, je suis convaincu qu'il savent parfaitement épeler "or donc" chez MySQL, on a tous nos priorités

lol