Pourquoi COCOA est important ?

Manu

Membre expert
Club iGen
31 Mai 2000
1 744
205
56
Puteaux région parisienne
Salut,
Dans un article publié récemment, j'attirais l'attention des développeurs de s'interesser à cocoa. J'ai reçu beaucoup de mails me demandant ce qu'il apporte de plus par rapport aux outils tels que code warrior, et quels sont ses avantages.

Tout d'abord Cocoa est le nouveau nom des apis yellow box encore appelées openstep sous NeXT.
Le seul langage autrefois utilisé sous NeXT était Objectve-C qui est un langage objet plus proche de smalltalk et du langage C.
Comme Objective-C est également très proche de Java, Apple a crée une version java de ces apis.
C'est ainsi que dans cocoa, un objet cocoa-java peut envoyer un message à un objet cocoa-Objective-C. Le nom des apis est le même que l'on utilise Java ou Objective-C.
Le gros intérêt de ces apis, c'est leur maturité et leur puissance.
En effet, sorties depuis 1988, ces apis ont été maintes fois débuggées et soigneusement 'polies'.
A tel point que certaines classes très utilisées comme NSSting, NSArray, NSSet,..etc, qui sont des classes de haut niveau, ont été réadaptées pour être utiliser en lieu et place de fonctions C équivalentes, avec l'avantage de disposer de toutes les methodes très puissantes permettant de les manipuler. Apple les a appelées Core Foundation. Ils portent les noms CFArray, CFString, etc, et sont accessibles à toutes les applications Carbon, Cocoa, Quicktime,...etc.
Si Java est bien apprécié par les développeurs, c'est parce qu'ils retrouvent dans java tout ce que la programmation orienté objet est censé apporter, contrairement à C++.
Dans une échelle décroissante de la nature objet d'un langage on citerai dans l'ordre smalltalk, ObjectiveC, Java puis C++.
smalltalk réunissant les propriétés d'un meilleur langage objet.
Cocoa est formé de plusieurs frameworks (ensemble de classes). La Foundation Kit qui contient des classes de bases (NSString, NSNumber,..etc), l'Application Kit qui réuni l'ensemble de classes permettant de créer une interface graphique (NSButton, NSWindows, ..etc). EOF (entreprise object Framework) qui permet de créer des objets métiers en modélisant les tables de bases de données en objet.(j'en parlerai plus longuement dans un prochain article car c'est le framework phare de WebObjects).
tous ces frameworks regroupent des classes ou objets de base de très haut niveau et cela facilite grandement le travail du développeur dont la tâche principal est de se concentrer sur les fonctions vitales de son application et non sur la 'plomberie'.
L'exemple le plus cité pour démontrer la puissance de ces apis est la classe NSTextView de l'Application Kit qui est à elle seule un éditeur de texte très complet avec des fonctions très avancées comme le drag and drop, le correcteur orthographique, le changement de polices, et tant d'autres déjà implèmentées.
Les classes NSDocument, NSDocumentController et NSWindowsController par exemple constituent a elles trois l'ossature d'une application de gestion de documents; Comme le sont la majorité des applications. (Word, Excel, Photoshop, etc..).le seul code à ajouter dans l'appli c'est celui permettant de créer le contenu des documents. La gestion du contenant étant à 75% gérée par les 3 classes à quelques implémentations de méthodes prédifinies près.
D'autre part, le principe de développement le plus fréquemment adopté est le MVC pour Model, View, controller.
Quand on démarre une appli, la première question à se poser est : quelles sont les objets manipulés dans le domaine dans lequel se place mon application.
Si ton appli a pour domaine la gestion de comptes dans une banque, les objets seront les comptes, les chèques,..etc. C'est ce qu'on appelle les objets de bases du domaine ou encore les objets models.
Après on s'interesse à la partie visuelle permettant aux utilisateurs non informaticiens le plus souvent, d'effectuer les différentes opérations courantes.
C'est la View ou l'interface graphique de l'appli.
Seulement les données saisies dans la View doivent être controlées. c'est le Controller qui le fait. il assure également le lien entre les objets model et l'objet View. En règle général, il y a un objet Controller par objet View.
Des 3 objets, c'est l'objet model qui est important car c'est lui qui est souvent réutilisé, d'où le grand soin mis à le définir.
Dans cocoa, c"est l'outil Interface Builder qui permet de créer les objets View et Controller.
Les objets model sont codés directement dans Project Builder qui sert également à completer l'objet controller et à le tester et débugger.
A supposer que vous vouliez mettre cette appli sur le web, c"est le controller et surtout la View (page web) qui seront réadaptés.
Apple conseille fortement aux développeurs cocoa d'adopter ce principe MVC, c'est le moyen de permettre à leur application de bénéficier 'gratuitement' des possibilités comme la scriptabilité, l'Undo le redo,..etc.
En résumé, comme l'a souligné Steve Jobs dans sa Keynote à la dernière WWDC, avec cocoa on développe 10 fois plus vite qu'avec d'autres outils.
En fait développer sous cocoa est un jeu de Lego où il faut disposer judicieusement les divers composants.
Je vous y invite fortement car les utilisateurs mac gagneront de très bonnes applications, ou great apps comme le dit steve jobs.
A+
manu

 
Deux questions (par simple curiosité...)

1. Ces APIs sont elles utilisables en C++ ?

2. Quid de la portabilité du code (principal intérêt de Java) si on utilise ces APIs ?

...Et deus très humbles opinions :

1. C++ n'est peut-être pas le top des langages objets, mais cela reste le langage le plus puissant que je connaisse ;-)

2. (là, je vais en faire hurler quelques uns...) Ca fait plusieurs années que (beurk) MikoSoft propose un framework (pour Ouindoze, bien sur) basé sur le paradigme Document/View /Controler). On retrouve d'ailleurs la même chose dans l'API Java 2. Il était peut-être temps qu'Apple s'y mette ?

NB : j'ai l'air de critiquer, mais ton article est très intéressant, et me fait (une fois de plus) regretter de me faire c... avec Ouindaube (clientèle oblige...)



------------------
--
laosteu
[email protected]
--
 
Salut,
Content que le sujet vous interesse. C'était le but recherché.
1 - Les APIS sont accessibles en Objective-C ou en java. ce dernier étant utilisé comme langage de programmation.
C'est vrai C++ est puissant. Mais en tant que développeur, je privilégie le coté objet d'un langage et tous les avantages apportés à savoir dynamicité, réutilisabilité, ..etc.
J'ai appris Objective-C en une journée. Pour une personne connaissant le C, il est beaucoup plus facile à apprendre que le C++.
En un mot je dirai : C++ privilégie le programme, Objective-C privilégie le développeur.
2 - Ces APIS ont été portées sous Windows, Solaris, HP-UX. WebObjects qui utilise à fond ces APIS tourne sur ces plates-forme. D'aiileurs une grande partie de mon expérience je l'ai eue en développant sous Windows avec OpenStep devenue depuis YellowBox.
3 - Le paradigme Model/View/Controler vient de Smalltalk le "père" des langages orientés objets, et ce bien avant l'apparition de Windows. MicroSoft ne faisait pas encore de l'objet ni personne d'ailleurs.
A ce propos, l'histoire de l'informatique est assez bizzare. En effet l'interface graphique, ethernet et smalltalk qui a donné naissance aux autres langages objets sont à l'origine des technologies nées au PARC chez Rank Xerox.
D'ailleurs Steve Jobs dans une interview disait en parlant de sa visite au PARC qui par la suite lui inspira la création de Lisa puis le macintosh, qu'il n'avait pas pu apprecier les machines en réseau, le langage orienté objet, obnibulé qu'il était par la seule découverte de l'interface graphique.
Il se rattrapa d'ailleurs lorsqu'il lanca NeXTStep.
Sauf qu'au lieu de smalltalk il préféra Objective-C qui était le langage C avec les avantages de smalltalk.
Pour le réseau, il prit l'UNIX BSD qui avait la meilleure pile TCP/IP.
Les inventeurs de Java sont ceux qui avaient participé au portage des APIS sous Solaris. Certains d'entre eux voulaient d'ailleurs aller chez NeXT avant que le PDG de SUN ne les dissuade en leur demandant de développer un langage objet, leger, portable qui utilise le potentiel offert par internet.
Quand tu auras utilisé les outils de développement comme Project Builder et Interface Builder, tu comprendras.

A+
Manu
 
Merci pour toutes ces précisions... Il est vrai que d'un point de vue développeur, tout cela est bien tentant :)

Je me permettrai juste un petit point de polémique (enfin... disons une petite taquinerie) : pour ma part, j'aurais plutôt tendance à priviligier l'utilisateur et non le développeur... Après tout, c'est pour lui que j'écris une application ;-)

Mais c'est vrai que je ne m'amuse pas à ecrire en assembleur pour autant...

Bon, sérieusement, j'aime beaucoup Java en tant que langage, mais j'ai été généralement très déçu par les performances des applications, surtout sur des machines un peu agées... qui consistituent une bonne part du parc.

Quant à C++, je l'ai appris (enfin, je l'apprend !!! Mais peut-on un jour dire qu'on 'a appris' un langage ?) sans bases préalables en C, venant des Basic modernes (VB, RealBasic) et de Java...). De ce point de vue, ce n'est pas la partie Objet du langage qui me pose le plus de problèmes...

Voili voila. Merci encore pour ton article, et merci pour ce petit complément

Laotseu


PS : loin de moi l'idée de prétendre que MS ait inventé quoi que ce soit, à part l'art de faire croire qu'ils ont tout inventé ;-)

Je voulais juste signaler qu'ils avaient intégré le modèle Vue/Document/Controleur dans leur framework C++ depuis déjà quelques temps...
 

[[Je voulais juste signaler qu'ils avaient intégré le modèle Vue/Document/Controleur dans leur framework C++ depuis déjà quelques temps...]]

Code Warrior aussi avec PowerPlant...

Je pense que le language est un tout mais ne fait pas le tout: on aurai pu remplacer l'objective C par C++ l'outil de développement aurait été le meme.
En gros, ce qui est interessant, c'est le foudation kit et l'application kit qui nous permette de simplifier les taches de création de l'application par l'objet (!= de la toolbox, qui était linéaire), sans oublier Interface builder qui se raccorde au reste...

Dans le cas de cocoa, les utilisateurs sont des développeurs non? ->LaoTseu

PS : Super article de pro. Tu peux aller voir francois tonic pour qu'il te dégotte une place dans son nouveau magazine "programmez!"... [email protected]
wink.gif
 
Steg,

Merci pour tes observations. Pour faire avancer la discussion, je voudrais apporter une précision par rapport à ta reflexion sur Objective C et C++.

En fait le gros avantage d'Objective C, c'est qu'il est très faiblement typé. C'est à dire que le compilo n'est pas trop regardant sur le type des objets. Ce qui n'est pas du tout le cas pour C++ et même java où, si le type de l'objet ne correspond pas à l'action que tu veux lui faire faire, t'as un message d'erreur à la compile.
En Objective C grâce à une forte dynamicité, le type de l'objet est évalué à l'exécution c'est à dire au moment de l'exécution de la methode c'est à dire du message.

Ce dynamisme est très important dans cocoa et Apple l'exploite à merveille dans la plupart de ses technologies. WebObjects par exemple est né de ce principe à savoir que la page web demandée est véritablement construite sur le serveur au moment où la requête est prise en compte.

L'avantage me diras-tu ? Eh bien c'est qu'elle reflète exactement le contexte du moment. Ceci est d'autant plus important que la plupart de ces applis accèdent à des bases de données en temps réel.

C'est ainsi qu'en Objective C il existe un type id qui est générique.

Prenons l'exemple d'une appli de gestion de clients. Le fait de déclarer id un objet représentant une personne te donne une certaine flexibilité. Tu peux dans la même appli l'utiliser comme un objet de type Client puis dans un contexte différent comme un objet de type Membre pour indiquer qu'il apartient à un groupe de clients particuliers.

Ainsi le même objet répondra aux messages d'un objet Client puis aux messages d'un objet Membre et ce suivant le contexte à des moments différents lors de l'exécution de ton appli.

Ce mécanisme Apple l'appelle 'lazy binding'. Il est utilisé dans Mac OS X lors de l'utilisation des Bundles ou des plugins.

Supposons que tu ais développé un plugin Photoshop avec plein de fonctions différentes à l'intérieur du plugin.

Aujourd'hui Mac OS charge en mémoire tout le plugin. Alors que Mac OS X le fait à la demande et au dernier moment. En plus il ne charge en mémoire que la fonction demandée, pas tout le plugin. on gagne en performance, la mémoire est mieux gérée, etc.

En fait quand tu développes sous cocoa, avec l'expérience, tu utilises beaucoup cette flexibilité qui en outre te permets de mettre au point des prototypes de ton application c'est très très sympa.

A+

Manu


 
PS :

En fait c'est un peu comme dans le monde réel. En tant que personne tu es client quand t'es dans une banque ou une boutique, et tu es Membre d'un groupe d'utilisateurs mac quand t'es ici. Dans un cas comme dans l'autre, tu es la même personne mais avec des aptitudes différentes.
La programmation orientée objet n'est-ele-pas faite pour réfléter le monde réel? En outre on est là en présence d'un cas de réutilisabilité chose tant louée dans la technologie objet.

A+
 
Merci Manu...

J'avais pas vu ta réponse avant.

Aller j'insiste, moi qui suis débutant sur cocoa, et attends la beta (j'aime vraiment pas la DP4 pour 'travailler')j'ai besoin d'un manuel : va voir francois tonic, et envoie lui un article pour ses 2 mags, il en a besoin, et je pense que la prog sous macosx a une place importante dans login: et programmez!, il est présent dans les deux en tant que redacteur dans l'un et redacteur en chef dans l'autre....

Non?