Version imprimable
On peut toujours se passer de tout, et alors on programme en assembleur.Citation:
[*]Je demande juste à voir un cas concret où on ne peut pas se passer d’héritage multiple dans une conception.
Mais si tu veux un bon exemple d'utilisation d'héritage multiple, regarde la classe iostream de la stl.
Les langages comme c# et java peuvent hériter d'une seule classe mais peuvent implémenter une multitude d'interface (je crois que c'est 60 la limite en c#) donc tu peux te passer de l'héritage multiple en utilisant des interfaces pour ces langages.
Mais comment rejoindras tu les besoins que j'ai exposé dans mon intervention précédente :question:Citation:
Envoyé par youtpout978
Tu peux avoir comme classe de base turbine et une interface IGenerateur, tout ça il faut y penser à la conception et pas s'amuser a créer ses classes au fur et à mesure et se dire merde comment je vais faire pour un turbo-générateur.Citation:
Envoyé par koala01
et donc, tous les générateurs devront implémenter IGénérateur, plutot qu'en hériter, et donc tu va dupliquer tout ce code...
Déjà, j'avais prévu la classe IGenerateur, meme si je l'avais nommé ProducteurDeCourent ;)Citation:
Envoyé par youtpout978
Ensuite, le besoin de turbo-générateur peut arriver lors d'une énieme itération de travail, bien après avoir constaté le besoin d'une turbine et d'un générateur :aie:
De plus, ton interface turbo-generateur ne résoudra, à mon sens, absolument pas le problème, simplement parce que tu dois passer des classes et non des interfaces comme argument re:aie: (bon, mes souvenirs à ce sujets sont anciens, ca a peut etre changé ;) )
Enfin, en ayant une classe Generateur, une classe Turbine, une troisième classe manipulant un Generateur et une une quatrième manipulant une Turbine, si tu veux pouvoir faire évoluer ces deux dernières classes pour qu'elles puissent toutes les deux manipuler des turob-generateurs, tu devras avoir:
une classe GenerateurTurbo, héritant de Generateur, implémentant les interfaces DebitVolumétrique et Rotatif (en fait, les interface de Turbine, mais comme tu hérites de Generateur, tu ne peux plus hériter de Turbine :aie:)
une classe TurboGenerateur, héritant de Turbine, implémentant l'interface ProducteurDeCourent (ou IGenerateur, quoi qu'il en soit, l'interface de Generateur dont tu ne peux plus hériter vu que tu hérites déjà de Turbine)...
Pour évoluer, ta classe manipulant un Generateur devra utiliser... GenerateurTurbo, et ta classe manipulant une Turbine devra utiliser... TurboGenerateur.
Et comme TurboGenerateur et GenerateurTurbo font en définitive la même chose, il faudra s'assurer de donner le moyen de convertir l'un en l'autre (et inversement) :aie:
Moralité :
- Tu duplique le code
- tu te trouves dans l'obligation de complexifier ton code pour permettre la transition entre les deux parties dupliquées.
Chapeau, les gars qui ont pensé java :D :aie:
En partant du même principe, en sachant que les interfaces en C++ sont des classes "comme les autres" (bien que j'aime l'idée de les faire sous la forme de template, en leur donnant "juste assez" pour qu'elles puissent fournir les comportement de base),
Il te suffirait alors de faire hériter TurboGenerateur de Turbine et de Generateur (sans besoin de créer une classe GenerateurTurbo !!!) d'éventuellement modifier tes deux fabriques pour qu'elles puissent toutes les deux renvoyer un TurboGenerateur (c'est finalement assez facile, et tu aurais aussi du le faire en java ;) ), et les deux classes qui utilisent l'une un Generateur, l'autre une Turbine peuvent parfaitement évoluer "à leur guise" pour utiliser un TurboGenerateur, sans avoir besoin de quoi que ce soit d'autre ;)
- tu pourrais très bien avoir les trois interfaces que j'ai citées :
- ProducteurDeCourent (IGenerateur, si tu préfères ;)),
- DebitVolumétrique et
- Rotatif,
- avoir ta classe Generateur qui hérite de ... ProducteurDeCourent<Generateur> (je l'ai dit, je créerais les interfaces sous forme de template ;) ),
- et avoir ta classe Turbine qui hériterait de DebitVolumétrique<Turbine> et de Rotatif<Turbine>.
Justement tu peux passer des interfaces comme argument, ce qui permet de créer une certaine couche d'abstraction entre tes classes (tu sais ce qu'elle fait mais tu n'as pas besoin de savoir comment elle le fait), c'est justement ce qui est utilisé pour faire de l'IOC, des webservices ...
Donc tu peux avoir une classe Generateur (qui implémente IGenerateur) et TurboGenerateur(qui hérite de Turbo et qui implémente IGenerateur) et passer comme argument un IGenerateur à une troisième classe qui fonctionne avec ça.
Tu as aussi des classes générique en c# et en java (enfin je crois).
Au temps pour moi ;)Citation:
Envoyé par youtpout978
Et tu fais comment pour la classe qui mainipule une turbine en interne, vu que tu ne peux qu'implémenter un interface et non en hériter :question: Tu crées une classe GenerateurTurbo (vu que TurboGenerateur est déjà pris), qui hérite de Turbine et implémente IGenerateur :question:Citation:
Donc tu peux avoir une classe Generateur (qui implémente IGenerateur) et TurboGenerateur(qui hérite de Turbo et qui implémente IGenerateur) et passer comme argument un IGenerateur à une troisième classe qui fonctionne avec ça.
N'est-ce pas ce que l'on appelle dupliquer du code :question:
La puissance des génériques en C# ou en java est loin de valoir celle des templates en C++, si on en crois l'avis général ;)... Mais c'est un autre débat ;)Citation:
Tu as aussi des classes générique en c# et en java (enfin je crois).
Si tu hérites d'une classe qui implémente une interface, tu hérites aussi des méthodes de l'interface qu'elle implémente (et donc tu peux la passé comme argument à une classe qui attend cette interface).Citation:
Envoyé par koala01
Tu peux même avoir une interface qui implémente d'autre interface.
Pour les templates c++ je connais pas du tout leur fonctionnement et donc je connais pas leur limite et leur possibilité par rapport à c#.
Après les performances d'une application ça vient rarement du langage utilisé en lui même mais plutôt du codage et donc des personnes qui ont travaillées dessus (quand on atteint la limite d'un langage managé je suis d'accord qu'un langage compilé peut apporté un +).
Oui, mais tu bloques sur le principal: tu dois créer deux classes (TurboGenerateur pour l'un, GenerateurTurbo pour l'autre) là où une seule aurait pu suffire si tu avais eu l'occasion d'utiliser l'héritage multiple...Citation:
Envoyé par youtpout978
Tant que tu t'entêteras à ne pas comprendre que j'ai fixé un cadre bien précis pour répondre à un problème bien précis, et qu'il faut donc trouver une solution globale à l'ensemble, on peut discuter cent vingt ans sans avancer sur le problème ;)
Serais tu en train de me conseiller de casser l'existant en cassant la classe qui manipule la turbine ou celle qui manipule le générateur en interne :question:
Tu demandais un cas où l'héritage multiple est absolument nécessaire.
Je te dis : voilà, on a une base de code composée (entre autres) de trois interfaces :
- ProducteurDeCourent (IGenerator) qui est une interface qui fournit tout ce qu'il faut pour gérer la génération de courent (la puissance maximale, la puissance actuelle, les pointes de puissance éventuelles, ...)
- DebitVolumétrique qui permet, en gros, de savoir quel volume (de fluide, pour etre générique) est déplacé en un temps T
- Rotatif qui permet de gérer les vitesses de rotations, de manière générale
J'ai deux classes (utilisées par ailleurs) auxquelles il ne faut pas toucher (mais qu'on peut réutiliser / dont on peut hériter:
- Générateur, qui implémente l'interface ProducteurDeCourent,
- Turbine qui implémente les interfaces DebitVolumétrique et Rotatif
j'ai deux fabriques qui ne demande qu'à évoluerEt, enfin, j'ai deux classes "utilisatrices" qui ne demandent qu'à évoluer (être dérivées)
- FabriqueDeTurbine qui fabrique des turbines
- FabriqueDeGenerateur qui fabrique des générateur
- UtilisateurDeTurbine qui manipule une Turbine en interne
- UtilisateurDeGenerateur qui manipule un Generateur en interne
Tu entre dans la boite comme développeur, et tu es face à cette situation de base, qui s'étend sur un développement de plusieurs années (et qu'il est donc impensable de casser pour le remplacer par du neuf).
Au moment où tout ceci a été mis au point, cela correspondait parfaitement à mes besoins.
Mais, maintenant, j'ai un besoin supplémentaire: celui de disposer de TurboGenerateurs, et il faut que mes deux classes utilisatrices puissent travailler avec, comment fais tu :question:
La réponse en C++ est simple : double héritage de Turbine et de Generateur, adaptation des fabriques et héritage des classes utilisatrices en fonction des besoins.
Quelle est la réponse que tu peux donner en java :question: Et, plus important, réponds honnêtement aux défauts de cette réponse ;)
J'avoue ne pas avoir toujours compris tes explications (limite mal de crâne en faite :aie:).
Je pense que tu devrais dupliquer le code d'au moins une des 2 classes, après si tes méthodes attendais une interface en argument et non une classe tu n'auras rien à casser (sinon ça fait du code à modifier).
Après je suis pas un pro en conception mais je pense que d'autres ont eu des problématique similaire et s'en sont très bien sortie.
En tout cas j'ai jamais vu de cas ou quelqu'un n'a pas pu développer en c# ou java parce que ces langages ne proposent pas d'héritage multiple.
Je pense que le problème c'est plus une façon de penser, quelqu'un qui développe en c++ essentiellement utilisera naturellement l'héritage multiple dans certains alors que le développeur c#/java utilisera héritage et interface sans que ça soit un frein au développement de l'application.
PS: Vous avez pas Linq en c++ c'est pas pour autant que ça vous empêche de développer.
Attends, tu demandais un cas où l'héritage multiple est utile voire indispensable.
Je te mets face à une situation (hypothétique, je te l'accorde, mais qui tient parfaitement la route) qui représente un cas concrèt et clairement défini, avec son histoire, ses besoins, son besoin d'évolution et ses impératifs.
Rien de plus que ce à quoi tu serais confronté si tu entrais demain dans une société développe son propre logiciel depuis 3 ans.
Je te dis qu'en C++, avec l'héritage multiple, je n'ai pas à dupliquer la moindre ligne de code et que tout "roule comme sur des roulettes".
Si tu le veux, je peux parfaitement t'écrire le code de chacune des classes et interfaces que j'ai cité aujourd'hui meme ;)
Je te demandes, dans la situation telle qu'elle apparait (et qui pourrait très bien se présenter à toi demain !!!) comment tu ferais, et tu viens me répondre "Après je suis pas un pro en conception mais je pense que d'autres ont eu des problématique similaire et s'en sont très bien sortie." ou pire "En tout cas j'ai jamais vu de cas ou quelqu'un n'a pas pu développer en c# ou java parce que ces langages ne proposent pas d'héritage multiple."???
Mais alors, ne viens pas parler de ce que tu ignores, et avoue simplement que "en effet, je ne sais pas" !!!
Je te dis, par expérience, que cela me prendra une demi heure pour coder toutes les évolutions sans avoir rien à casser en C++ grace à l'héritage multiple, et je t'affirmes qu'il faudra trois fois plus de temps pour répondre à toutes les exigences en C# ou en java, avec des solutions qui feraient blêmir un étudiant de première année.
Quant à Linq, il ne faut pas confondre : Linq n'est jamais que l'équivalent d'une bibliothèque, et la présence ou l'absence d'une bibliothèque n'a jamais empêché le développement : Dans le meilleur des cas, la présence d'une bibliothèque va faciliter le développement ;)
Mais là, on parle d'un principe de base du développement OO (l'héritage multiple, ce n'est jamais que de l'héritage malgré tout, hein ?) Et l'interdiction d'un principe de conception, ca, oui, c'est grandement de nature à empêcher un développement, ou du moins un développement optimal ;)
[EDIT]Peut etre voudrais tu un diagramme de classes pour comprendre ce la situation telle qu'elle se présente :question:
[EDIT2] Comprenons nous bien, je ne dis pas que c'est impossible en java ou en C#, je dis juste que tu vas dupliquer du code et que tu n'auras aucune autre solution que d'avoir deux classes qui font, au final, strictement la meme chose, l'une adaptée à l'usage de UtilisateurDeTurbine et l'autre adaptée à l'usage de UtilisateurDeGenerateur, avec, sans doute, le moyen de convertir l'un en l'autre.
Et je dis également clairement que cette situation ne pourra qu'empirer au fur et à mesure que de nouveaux besoins se feront sentir (comme par exemple, le fait de distinguer un TurboGenerateur à courent continu d'un TurboGenerateur à courent alternatif) ;)
Quand je parlais des explications je parlais pas de l'héritage multiple (j'ai très bien compris le concept) mais de ton premier exemple du turbogenerateur, le second je l'ai un peu mieux compris, après la solution que je t'expose est celle que j'ai trouvé en réfléchissant 10 minutes d'autre aurais surement de meilleur solution.
Après je ne déments pas son utilité dans certains cas mais on peut s'en passer (tu ne vas pas tirer un trait sur d'autre langage parce qu'il ne l'implémente pas mais qui laisse d'autre possibilité permettant de s'en passer c'est surtout ce que je voulais dire).
PS: j'ai toujours voulu faire du c++ pour ses possibilités bas niveau mais je suis trop flemmard pour l'apprendre et c# m'a toujours suffit dans tout ce que j'ai fais jusqu'à présent.
Pourtant, mon deuxième exemple n'était qu'une redite de mon premier...Citation:
Envoyé par youtpout978
Au pire, le premier était un peu succin comme explication ;)Honnêtement, j'attends avec impatience la solution qu'un pro en java ou en C# pourrait donner à ce problème sommes toutes "si simple ;)Citation:
après la solution que je t'expose est celle que j'ai trouvé en réfléchissant 10 minutes d'autre aurais surement de meilleur solution.
Il n'est pas question non plus de "jeter" les autres langages, je te rassures ;)Citation:
Après je ne déments pas son utilité dans certains cas mais on peut s'en passer (tu ne vas pas tirer un trait sur d'autre langage parce qu'il ne l'implémente pas mais qui laisse d'autre possibilité permettant de s'en passer c'est surtout ce que je voulais dire).
J'ai ma préférence personnelle pour le C++, et j'en fais état sans crainte ni honte ;)
Mais si j'émets cette préférence, c'est parce que j'estime que C# ou java permettent d'obtenir beaucoup trop facilement un résultat "qui semble pas si mal" à n'importe quel incompétent crasse (ce qui ne veux absolument pas dire que tous les développeur C# ou java sont incompétents, hein ;))
Honnêtement, la syntaxe, ca doit tourner autour d'une cinquantaine de mots cles, à peu de chose près, les même qu'en C#, à leur signification près (certains ont une signification différentes).Citation:
PS: j'ai toujours voulu faire du c++ pour ses possibilités bas niveau mais je suis trop flemmard pour l'apprendre et c# m'a toujours suffit dans tout ce que j'ai fais jusqu'à présent.
A part cela, la grosse difficulté tient sans doute à "désapprendre" une ou deux choses, comme le fait de se fier au boulot du GC, ou que tout hérite d'office d'Object (principale raison de l'interdiction de l'héritage multiple et obligation rendue nécessaire par l'utilisation du Garbage collector ;))
Pour une utilisation avancée, il faudra aussi recommencer à penser en "multi paradigme", car c'est une autre interdiction de java et de C#, mais ca, on s'y fait vite :D
Si tes classes manipule des interfaces tu n'as rien à toucher pour tes classes Utilisateur, par contre si elle manipule des classes il faudra surement remplacer les références aux classes par des références à des interfaces donc pas besoin de créer 2 classes une seule classe suffit à partir du moment qu'elle implémente ces 2 interfaces.Citation:
Envoyé par koala01
J'espère bien, je ne veux absolument pas qu'on y touche !!! Elles sont utilisées, ces classes, et il est pas question de "tout casser" hein :question:Citation:
Envoyé par youtpout978
J'ai dit :on n'y touche pas !!! Elle contient une référence sur une classe, ce n'est pas pour la remplacer par une référence sur une interface.Citation:
par contre si elle manipule des classes il faudra surement remplacer les références aux classes par des références à des interfaces
Tu peux la dériver autant que tu veux, mais tu ne peux en aucun cas la modifier, sauf si c'est pour lui rajouter une fonctionnalité qui lui manque ;) (respect de l' OCP ;))
[EDIT]
La situation est claire: mes classes utilisateurs utilisent en interne une référence sur un objet prévu pour etre polymorphe (en C++, ça aurait été un pointeur ;)), elles obtiennent cette référence (ce pointeur, en C++) au travers d'une fabrique, qui ne demande qu'à leur renvoyer un objet polymorphe sans même que la classe utilisateur n'ait besoin de savoir si c'est un objet de base ou un objet dérivé, car elle n'utilise en interne que l'interface de la classe de base.
Mais cette classe utilisateur fournit un tas de services pour lesquels le moindre changement signifie casser une multitude de fonctions qui ont été prévus pour fonctionner avec des référence sur objet de type Generateur (ou Turbine)...
Vouloir remplacer la référence (en C++, le pointeur) sur l'objet de type Generateur (ou Turbine), revient à devoir revoir toutes ces fonctions, et c'est inacceptable, tu seras d'accord avec moi, hein :question:
Et donc, à part éventuellement rajouter un constructeur avec un paramètre supplémentaire (qui permettra à la fabrique de renvoyer un objet dérivé), on ne modifie en rien le code existant (il y a des dizaines de milliers de lignes de code qui utilise les services de la classe utilisateur depuis 5 ans et le type qui les a écrites est parti à la retraite ;))
Absolument pas d'accord avec ce chef de produit... c'est même très étonnant de lire cela alors que toute la profession(mobile) forme des développeurs sur l'ensemble des technos, un peu sur le web et html5/javascript (qui n'est malheureusement pas encore au niveau des performances d'une application native...).
Pour faire de la mobilité depuis les années 2000, (et oui, je suis un dinosaure, je sais... ), C++ n'a jamais été présent...ou alors peu. Allez, on peut noter à la rigueur QT et nokia... même si le client à la fin voulait que ce soit disponible sur tous les terminaux, et qu'il fallait très vite repasser à du J2ME... :-)
J'entends parler de Android et du NSDK... les gens qui en parlent l'ont t'ils déjà utilisés ?? franchement...
J'entends parler de C++ pour l'iPhone, même question ?
et je ne parle même pas des autres plate-formes, Blackberry, Windows 7 et 8, etc...
Nous avons eu un espoir à un moment avec Flash (flex, air et autres..)
Mais c'était beaucoup trop lourds et beaucoup trop gourmand en batterie pour les utilisateurs. Même chose avec Java... sauf pour les téléphone nativement en java ou avec des outils de développement prévue pour (blackberry et Android).
Pour l'iPhone, il n'y a même pas à discuter, l'environnement xCode et objectifC reste le seul viable. (si vous voulez faire autre chose que des pages de catalogues qui mettent trois heures à se recharger parce que vous utiliser une webview...).
Pour android, avec la problèmatique des écrans, des interfaces, des terminaux, il ne reste que l'environnement SDK en Java. Qui est plutôt pas mal d'ailleurs pour une plate-forme aussi jeune.
Pour Blackberry, c'est exactement la même chose, java reste la solution la plus adéquate.
Pour Windows, pourquoi donc vouloir changer C# ??? Vous avez vu ce qu'offre à un développeur l'environnement de développement ???
Alors certes, l'environnement mobile reste complexe parce que chacun à son outil. Mais, paradoxalement, c'est tellement simple. N'importe quel développeur peu prendre en compte un outil de développement natif (java, objectif-C, windows...) en deux semaines. Il suffit de bien le guider au départ.
Maintenant, comme dirait l'autre, le meilleur outil reste celui qu'on maîtrise...
Je pense très sincèrement que prendre un code C++, avoir 3000 routines et bidouilles de compilation pour le porter (quand c'est possible...) et contourner sans arrêt les nouveaux sdk et leur fonctionnalités, restera toujours plus long et plus coûteux que de prendre 3 développeurs, chacun une techno, et en avant... :-)
alors si quelqu'un aime C++, qu'il arrive à développer sur Android en gardant tous les terminaux cibles, etc.. que son code fonctionne également sur iPhone et blackberry, et windows.. whaouu.. chapeau !!! Mais bon, depuis plusieurs année de mobilité, j'ai encore jamais vu... Mais je suis prêt à voir un exemple réel... :-)
Rien qu'en projet scolaire en java on se retrouvait avec du code dupliquait parce que les interfaces cest mignon, mais cest un peu naze point de vue factorisation du code. Ca ne couvre que la factorisation de service a rendre.
Alors en entreprise... ^^
Perso, j'ai toujours vu le choix de l'interdiction d'héritage multiple, mais pouvoir implémenter autant d'interface que souhaité comme le plus gros bullshit des langages java et .net
Alors certes, ca évite de rencontrer un "problème d'héritage en diamant", mais la solution retenue pour éviter ce problème aux développeurs est un leurre et une belle arnaque amha
Eh ben t'as pas du faire des masses d'applications gourmandes hein. Moi j'ai fait 1 appli Android an Java et 4 en C++ (des jeux).Citation:
Envoyé par oliverparis
Comme quoi faut pas se fier a son experience sur ce genre de chiffres...
Oui oui, et meme que le NDK a ete largement ameliore dans ses dernieres versions puisque de plus en plus de devs voulaient faire du natif mais le SDK etait un peu pourri au debut. La situation a bien evolue. Tu as aussi par exemple des outils pour integrer le NDK a Visual Studio.Citation:
J'entends parler de Android et du NSDK... les gens qui en parlent l'ont t'ils déjà utilisés ?? franchement...
J'en ai fais 4, je connais au moins 10 jeux qui sont implementes en C++ sur IOS et sans compter les jeux exclusivement iPad donc.Citation:
J'entends parler de C++ pour l'iPhone, même question ?
Tu plaisantes j'espere? Blackberry on pouvait pas faire du natif jusque recemment, mais les autres plateformes ont toujours incite a faire du natif. Notemment Windows 8...Citation:
et je ne parle même pas des autres plate-formes, Blackberry, Windows 7 et 8, etc...
... mais t'es au courant qu'XCode supporte le C++ et qu'en fait Objectitve-C et C++ sont tres facilement melangeable? Parceque ya plein de gens qui font ca et ca a rien de difficile...Citation:
Pour l'iPhone, il n'y a même pas à discuter, l'environnement xCode et objectifC reste le seul viable. (si vous voulez faire autre chose que des pages de catalogues qui mettent trois heures à se recharger parce que vous utiliser une webview...).
Il n'y a strictement aucun rapport entre la resolution de l'ecran et le language utilise pour developper une app.Citation:
Pour android, avec la problèmatique des écrans, des interfaces, des terminaux, il ne reste que l'environnement SDK en Java. Qui est plutôt pas mal d'ailleurs pour une plate-forme aussi jeune.
Et donc dans leur dernier SDK ils ont tout fait pour inciter a faire du natif juste pour le plaisir?Citation:
Pour Blackberry, c'est exactement la même chose, java reste la solution la plus adéquate.
Il ne sagit pas de "changer C#" voyons. Il sagit d'un rapport cross-platform performance. Si tu n'as pas senti le besoin pour un language comme C++, ya pas de souci. Note que Windows 8 est a fond dans le natif... essentiellement parce que ses derives vont tourner sur tablettes ou smartphone donc faut quand meme inciter a faire des appli peu gourmandes.Citation:
Pour Windows, pourquoi donc vouloir changer C# ??? Vous avez vu ce qu'offre à un développeur l'environnement de développement ???
Apple a fait de meme d'ailleurs en limitant autant que possible les appli a du natif.
C'est clair! J'ai fait mon premier jeu iPhone en 2 semaines. En C++.Citation:
Alors certes, l'environnement mobile reste complexe parce que chacun à son outil. Mais, paradoxalement, c'est tellement simple. N'importe quel développeur peu prendre en compte un outil de développement natif (java, objectif-C, windows...) en deux semaines. Il suffit de bien le guider au départ.
C'est un paramettre, mais parfois ce n'est pas le seul.Citation:
Maintenant, comme dirait l'autre, le meilleur outil reste celui qu'on maîtrise...
Vu comme ca je suis d'accord. Le fait est qu'un dev C++ suffisamment forme a faire de code cross-platform va avoir tres peu de boulot a faire entre les plateformes. En particulier si il a un bon framework qui isole bien son code. Moi j'ai utilise un tel framework, il a fallu une journee pour porter le code de iPhone a android, moins pour faire tourner la meme appli sous windows.Citation:
Je pense très sincèrement que prendre un code C++, avoir 3000 routines et bidouilles de compilation pour le porter (quand c'est possible...) et contourner sans arrêt les nouveaux sdk et leur fonctionnalités, restera toujours plus long et plus coûteux que de prendre 3 développeurs, chacun une techno, et en avant... :-)
Mais... yen a plein.... t'en connais vraiment aucun???Citation:
alors si quelqu'un aime C++, qu'il arrive à développer sur Android en gardant tous les terminaux cibles, etc.. que son code fonctionne également sur iPhone et blackberry, et windows.. whaouu.. chapeau !!! Mais bon, depuis plusieurs année de mobilité, j'ai encore jamais vu... Mais je suis prêt à voir un exemple réel... :-)
Bein là tu es dans le cas du c++, si tu développes en c# ou java et que tu ne veux pas tout casser par la suite en cas de modification tu références des interfaces et non des classes donc tu ne touches en rien à tes classes existantes.Citation:
Envoyé par koala01