C'est la pire solution de réutilisation que je connaisse : la maintenance sera affreusement répartie, pouf productivité en chute libre.
J'ai pas dit que c'était une méthode idéale; mais avoir cette possibilité tout à fait pragmatique est bien utile, cf mon exemple.
lequel est même déporté sur une autre machine, merci les DistributedObjects.
Mais dis donc c'est révolutionnaire tout ça à notr époque :)
Le principe d'avoir des objets répartis, ce n'est pas révolutionnaire. Par contre, j'ai pas vu plus simple qu'avec GNUstep (même RMI est plus lourdingue, même si java 1.5 va justement alléger ça) -- tu n'as besoin que de changer l'initialisation de ton objet, une ligne, et hop ensuite le reste fonctionne exactement comme si ton objet distant était local. Ceci dit, le fait que java permette des choses (style bean builder) très très proche d'ObjC/OpenStep n'est pas exactement une suprise -- java a été fortement inspiré par ObjC ! cf un mail fameux de Patrick Naughton (http://virtualschool.edu/objectivec/influenceOnJava.html(...)), un des architectes principaux de Java. D'ailleurs ce qu'on peut reprocher à java est en partie qu'ils n'aient pas été plus inspirés au niveau du framework !
Le seul truc que j'aime bien et qui sort du lot par rapport à la concurrence, c'est effectivement le fait de créer automatiquement un controller. Celà peut être sympa pour faire du RAD, mais dans le cadre d'une vraie application où le controller est INDEPENDANT de l'interface, ben c'est foutu : là tu es limité à utiliser les widgets de GNUStep, pour une autre interface ben faudra recoder ton controller : résultat question gain de temps ben c'est retour à la case départ, voir tu recules encore plus.
Ouaip là t'est un peu à côté de la plaque. Le truc, c'est pas juste "créer automatiquement un controller". Tu peux créer *n'importe* quelle classe et l'instancier, on est franchement pas limité aux contrôleurs; de la même façon tu peux simplement importer un source code existant, avoir la classe disponible, et instancier un objet de cette classe dans ton gorm !
Je vois pas ce que tu veux dire avec ton "faudra recoder ton contrôleur". Par *définition* un contrôleur est dépendant de ton interface graphique... c'est le modèle MVC -- modèle-vue-contrôleur. Ce qui est indépendant de ton UI, c'est ton modèle. La vue, c'est ton UI. Le contrôleur est là pour lier ta vue et ton modèle.
Ici, l'exemple de la vidéo est tellement simple (franchement, multiplier deux nombres..) que je n'ai pas pris la peine de créer une classe "contrôleur" séparée, et que je n'ai finalement qu'un objet "modèle" directement lié aux éléments de mon UI. Dans un vrai programme, j'aurait une classe "modèle" qui contiendrait ma logique métier, une vue (ici simplement créée avec Gorm), et une classe contrôleur liant le modèle et la vue. Je suis étonné de réexpliquer les principes du design pattern modèle-vue-contrôleur...
Moi je peux te faire une démo en Java ou VB identique qui te prends également 2 lignes de codes à écrire :)
Clair -- une calculette en VB sera encore plus courte à coder ! par contre, ton code sera liée à ton UI, ie, complètement pas scalable comme approche.
Enfin à part cette featurette (création automatique d'un controller) dont je t'ai montré les limites, je ne vois rien qui innove par rapport à la concurrence actuelle.
Comme je viens de l'expliquer plus haut, tu ne m'as en rien montré les limites de ce que tu appelle une "featurette" -- la possibilité de manipuler tes objets en live...
[^] # Re: trop génial
Posté par Nicolas Roard . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 4.
Ouaaaip bon je m'emporte ;-)
C'est la pire solution de réutilisation que je connaisse : la maintenance sera affreusement répartie, pouf productivité en chute libre.
J'ai pas dit que c'était une méthode idéale; mais avoir cette possibilité tout à fait pragmatique est bien utile, cf mon exemple.
lequel est même déporté sur une autre machine, merci les DistributedObjects.
Mais dis donc c'est révolutionnaire tout ça à notr époque :)
Le principe d'avoir des objets répartis, ce n'est pas révolutionnaire. Par contre, j'ai pas vu plus simple qu'avec GNUstep (même RMI est plus lourdingue, même si java 1.5 va justement alléger ça) -- tu n'as besoin que de changer l'initialisation de ton objet, une ligne, et hop ensuite le reste fonctionne exactement comme si ton objet distant était local. Ceci dit, le fait que java permette des choses (style bean builder) très très proche d'ObjC/OpenStep n'est pas exactement une suprise -- java a été fortement inspiré par ObjC ! cf un mail fameux de Patrick Naughton (http://virtualschool.edu/objectivec/influenceOnJava.html(...)), un des architectes principaux de Java. D'ailleurs ce qu'on peut reprocher à java est en partie qu'ils n'aient pas été plus inspirés au niveau du framework !
Le seul truc que j'aime bien et qui sort du lot par rapport à la concurrence, c'est effectivement le fait de créer automatiquement un controller. Celà peut être sympa pour faire du RAD, mais dans le cadre d'une vraie application où le controller est INDEPENDANT de l'interface, ben c'est foutu : là tu es limité à utiliser les widgets de GNUStep, pour une autre interface ben faudra recoder ton controller : résultat question gain de temps ben c'est retour à la case départ, voir tu recules encore plus.
Ouaip là t'est un peu à côté de la plaque. Le truc, c'est pas juste "créer automatiquement un controller". Tu peux créer *n'importe* quelle classe et l'instancier, on est franchement pas limité aux contrôleurs; de la même façon tu peux simplement importer un source code existant, avoir la classe disponible, et instancier un objet de cette classe dans ton gorm !
Je vois pas ce que tu veux dire avec ton "faudra recoder ton contrôleur". Par *définition* un contrôleur est dépendant de ton interface graphique... c'est le modèle MVC -- modèle-vue-contrôleur. Ce qui est indépendant de ton UI, c'est ton modèle. La vue, c'est ton UI. Le contrôleur est là pour lier ta vue et ton modèle.
Ici, l'exemple de la vidéo est tellement simple (franchement, multiplier deux nombres..) que je n'ai pas pris la peine de créer une classe "contrôleur" séparée, et que je n'ai finalement qu'un objet "modèle" directement lié aux éléments de mon UI. Dans un vrai programme, j'aurait une classe "modèle" qui contiendrait ma logique métier, une vue (ici simplement créée avec Gorm), et une classe contrôleur liant le modèle et la vue. Je suis étonné de réexpliquer les principes du design pattern modèle-vue-contrôleur...
Moi je peux te faire une démo en Java ou VB identique qui te prends également 2 lignes de codes à écrire :)
Clair -- une calculette en VB sera encore plus courte à coder ! par contre, ton code sera liée à ton UI, ie, complètement pas scalable comme approche.
Enfin à part cette featurette (création automatique d'un controller) dont je t'ai montré les limites, je ne vois rien qui innove par rapport à la concurrence actuelle.
Comme je viens de l'expliquer plus haut, tu ne m'as en rien montré les limites de ce que tu appelle une "featurette" -- la possibilité de manipuler tes objets en live...