barmic a écrit 10455 commentaires

Je voudrais quand même calmer les esprits. J'ai parlé de ma préférence et de comment ça devrait être selon le paradigme objet (ce dont parlait l'auteur du journal). J'ai pas dis qu'une méthode ou l'autre était particulièrement nulle.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Non sur le lien wikipedia on a un objet metier , un DAO et un contrôleur. Dans le code plus haut il n'y en a pas besoin.

Et dans le contrôleur il y a quoi ? Simplement l'usage du DAO, l'exemple ne prends même pas la peine de mettre ça dans une fonction. Le contrôleur c'est juste le bout de code qui a besoin des objets, il instancie le DAO et récupère (ou sauve) des objets.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

En python, c'est très facile de fournir une API simple qui réponde à ton problème. Cf [SQLAlchemy http://www.sqlalchemy.org/] qui rends l'utilisateur d'un SGDB aussi simple que d'utiliser un objet. Que ton objet soit persistent ou non ne doit pas changer ta manière d'interragir avec. Sinon, tu te fais des nœuds au cerveaux !

En regardant vite fait sa documentation il semble que c'est précisément ce qu'il fait : vois. Il utilise un objet session qui gère les interactions avec la base et tu l'appel avec de simples objets, comme avec hibernate par exemple. La différence entre les deux c'est que chacun s'adapte au langage qu'il utilise (typage statique ou non).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Peut-être que derrière c'est écrit avec un DAO surement, mais dans ce cas on a quand même une méthode d'objet. Du coup, c'est quoi l'intêret ?

Elles utilisent l'héritage pour faire le boulot du DAO (ce n'est pas toi qui écris la méthode save(), ni les constructeurs qui prennent une requête SQL en paramètre). Je dis juste que d'un point de vu « philosophie objet », ce n'est pas à l'objet de savoir comment se persister, mais à la base de savoir comment persister un objet. De la même manière que c'est à la console de savoir comment afficher et pas à l'objet. Ça ne te viendrais pas à l'esprit d'écrire ça :

My_Object.print();

au lieu de ça :

Console.print(My_Object);
// ou
Console.print(My_Object.str());

Personnellement, je n'ai jamais utilisé d'ORM comme tu le dis, je ne sais pas comment ils gèrent les transactions d'ailleurs.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Tout a fait et dans le lien que tu pointes, on se retrouve avec un contrôleur encore en plus qui fait appel à un DAO … 2 objets en plus.

1. Tu n'a qu'une seule classe de plus. On présente 3 parties car il y a la classe de ton modèle, le DAO et le code qui utilise ton DAO. Dans le cas où tu n'utilise pas de DAO, tu as la classe de ton modèle et le code qui l'utilise. Bref, il y a une classe en plus * ;
2. Pour moi dire que c'est nulle parce que tu as une classe en plus c'est un peu comme dire qu'écrire 2 fonctions au lieux d'une c'est mal. Ça dépend de ton besoin. Dans le cas présent ça me semble être une bonne idée dans la majorité des cas.

Les ORM qui utilisent une fonction dans les objets du modèle utilisent soit un proxy soit de l'héritage (ou les deux) et éventuellement de l'introspection. Je ne suis pas sur qu'avoir des classes triviales soient de la sur conception.

Tout ça pour s'abstraire du mécanisme de stockage alors qu'on a juste à modifier une ligne* le jour oû on change de methode.

• : une ligne dans n classes (n étant le nombre d'objets du modèle)

C'est aussi agréable quand tu veut faire du cache, tu as une classe qui va pouvoir s'occuper du cache sans influencer le reste du code.

Note que j'ai parlé de ma préférence, c'est tout à fait discutable.

Bienvenue dans la sur conception des langages mono paradigme objet.

J'ai parlé de conception objet parce que Guillaume Camera expliquait :

Bref, la notion d'objet n'est plus trop bien respectée, question philosophie objet on n'est pas super là.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Alors les spécialistes diront sans doute que l'absence de typage statique est un problème, sans doute mineur.

« des spécialistes » car il y a un paquets de spécialistes vraiment excellents qui sont aussi des intégristes d'un truc ou d'un autre (la POO c'est pourri, le typage statique il y a que ça de vrai, l'inférence de type est la seule solution acceptable,…). C'est d'ailleurs une des raisons du nombre de langages.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Tout n'est pas rose non plus, le fait de ne pas déclarer les variables peu rendre la lecture compliquée (cette donnée membre est elle héritée ? Par exemple).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

class MonObjet(object):
     def meth1(self):
         # du code ici...
def ajoutEnBase(mabase, monobjet):
    # Code qui ajoute mon objet en base

Bref, la notion d'objet n'est plus trop bien respectée, question philosophie objet on n'est pas super là.

Je préfère ce que tu présente à ça :

class MonObjet(object):
     def meth1(self):
         # du code ici...
     def ajoutEnBase(mabase):
         # Code qui ajoute mon objet en base

Car ce n'est pas la responsabilité de MonObjet de savoir comment s'enregistrer en base. Généralement on utilise un objet par exemple session qui permet de persister des objets. C'est le DAO.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

C'est deux choses l'une à coté de l'autre.

D'une part ça réduit la propagation (amesys ne seras pas de la partie).

D'autre part ça permet de savoir que ça existe c'est publique et pas des mails qui sortent d'on ne sait où.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

…par les petits acteurs. Tu penses bien que les grosses entreprises qui ont de quoi dissuader ou contre-attaquer avec des portefeuilles de brevets gigantesques (ou même payer) ne seront pas beaucoup gênées par un tel dépôt.

Ça représente combien d'entreprises ? 4 ou 5 et toutes américaines et comme tu le montre elle doit peser de tout son poids. Bref c'est un peut différent que de le partager sous licence RABL.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Une autre possibilité serait d'avoir des macros pour compiler avec CC ou avec CXX, mais c'est beaucoup moins élégant.

Tu veut dire que la solution que je présente plus haut n'est pas élégante ? Je m'en sert souvent (pas pour redéfinir CC, mais pour redéfinir LDFLAGS et/ou CFLAGS quand j'utilise make sans makefile).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Désolé, j'ai mal lu j'ai surtout voulu montrer que même si on ne peut peut être pas sur charger les règles, on peut tout de même les influencer pour correspondre à ce dont parle le journal.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Quand je le faisais, je n'utilisais pas le code généré par g++. Une fois que je n'avais plus de warning g++, je compilais en gcc et j'utilisais ce dernier.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ça m'est déjà arrivé, mais aujourd'hui c'est plutôt vers de l'analyse statique de code que je me tournerais pour avoir le même résultat en mieux et plus propre.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Sauf que si c'est possible :

CC=g++ make

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Imaginez une manifestation sans tweete, sans photo, sans vidéos… autres que celles que la presse accréditée aura bien voulu vous servir.

OH MON DIEU ! On faisait comment avant ?

Avant, la presse était un peu plus indépendante et n'était pas dirigée par des commerciaux et des financiers.

Non. Mais faut voir comment ça se passait en mai 68 (les médias n'étaient pas libres à l'époque). Il n'y avait aucune information diffusait. Il fallait écouter Europe1 qui émettait depuis l'étranger pour savoir ce qui se passait.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Par contre, Apple brevette aussi ce genre de trucs. Et ça, ça m'inquiète.

Au contraire je trouve plutôt bien qu'ils posent ce genre de brevets, ça freine l'usage de ces technos et ça évite de se retrouver comme pour paladium à imaginer sans vraiment avoir quelque chose de concret.

Bref que la techno existe n'est pas un bien, mais le dépôt de brevet permet de limiter la casse.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

• Les prévisions météo sont passées de 5 à 7 il y a quelques années
• On sait faire des batiments antisismiques (pas facile de tester grandeur nature, la simu numérique est la seule solution pour ça)
• On concoit des voitures plus solides en les modélisant numériquement (et en les crash-testant numériquement)

Même pour des choses qui paraissent plus simples. Quasiment toute création industrielle passe par de la simulation numérique.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Par exemple, imaginons qu'on ait une base de clients avec une table client. Si on souhaite juste faire une recherche du nom du client en fonction de son identifiant dans la table, ce n'est pas une fonction pure (puisque son résultat dépend de l'état de la base). Donc comment séparer ce qui est "impur" (dépendant de l'état de la base de données) de ce qui peut être codé en fonctions "pures" ?

Tu peut par exemple créer une fonction qui va faire la récupération des données (donc impure) et tu lui fait utiliser une fonction pure pour les traiter. L'avantage c'est que tu va pouvoir faire des tests unitaires simples et complets sur ton traitement (il gère les valeurs nulles ? comment se comporte il si l'utilisateur n'existe pas ? etc). S'il s'agit du traitement que tu parle c'est très (trop ?) trivial, mais dès que ton traitement est un peu évolué, tu y gagne.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Les langages de programmation font tous la même chose (à part ceux non "Turing-complet") donc ils sont applicable à tous les domaines (à part les problèmes de performance des implémentations).

Les langages qui ne gèrent pas de portée d'identifiants (imagine un shell sans mot-clef local) ne permettent pas d'écrire des fonctions pures.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Seulement, est-ce que cela découle du type d'architecture (SOA et langage objet) ou bien de la manière dont c'est implémenté ?

Je pense que ça découle de la manière dont s'est implémenté en partie et une autre bonne partie viens de l'écosystème (je pense à Java EE). Dans les technologies Java EE (je ne sais pas ce qu'il en est de .Net par exemple) beaucoup de choses se bases sur le contexte et il faut produire un effort particulier pour réduire le couplage entre ton code et le reste du système qui n'est pas forcément fait (pour pleins de raison).

De plus (en tout cas dans les contextes où j'ai travaillé) dans ce genre de programme, on réfléchis plus au niveau module (ou composants) que par fonction et (en principe) un composant doit pouvoir travailler tout seul et ce dernier a les même propriétés qu'une fonction pure (à quelques exceptions près).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Oui, l'idée était surtout de dire que ce n'est pas parce qu'il écris du logiciel qui reste propriétaire quelques années qu'il ne contribue pas au libre.

[…] plutôt du bon.

Il a révolutionné la manière d'écrire une fonction racine carré par exemple et l'a libéré. C'est un peu plus créatif que le fameux « checkrange » d'Apple.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Si on enlève la subordonnée relative, il reste :

Tu as raison, j'ai toujours ce problème quand je fais des subordonnées trop longues, je me perd dans mes phrases. Comme on m'a toujours dis, quand ça arrive, on coupe la phrase :

Je viens aujourd'hui vous parler d'un billet de blog de John Carmack. Pour ceux qui ne le connaîtraient pas, c'est ce développeur de renom chez IdSoftware, qui a participé à la création de titres phares du jeu vidéo PC avec la série des Doom, des Wolfenstein et des Quake.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

La version web correspondrait à ton besoin, non ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ça fait toujours une bonne pub de pouvoir annoncer avoir construit le n° X du Top 500.

Ça fait aussi une bonne pub pour le client (« Venez travaillez avec nous on a du super matos ! »).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)