|
08-04-08 / 00:08 : Objective-C / Java / Groovy (cjed) | Voici quelque uns des avantages majeurs d'Objective-C (base de Cocoa et WebObjects) par rapport à Java :
Java ne respecte pas le concept de message, et l'associe à un appel de méthode sur un objet (et à priori connu). Pourtant le concept de message (commande) et d'appel de méthode (résultat de la commande) sont bien dissociés en objet.
Le runtime Objective-C possède un mécanisme de délégation de message implicite (Responder Chain, chaîne d'objets delegates), et le destinataire du message (pouvant le traiter) n'est pas connu à l'avance. Les frameworks Cocoa (AppKit, etc.) utilisent la définition d'objets delegate (binding dans InterfaceBuilder par exemple) afin de redéfinir les comportements sans avoir besoin de sous-classer. En Java rien n'est prévu à l'origine, on doit connaître le destinataire à l'avance (et au moins son interface, même si réflection, sauf si le nom de la classe est précisé dans un fichier de configuration et dans le code client - cas par exemple des couches de mapping O/R). Il faudrait mettre en place un bus de message (comme la Responder Chain), mais la syntaxe deviendrait lourde.
La notion de selector en Objective-C est bien plus élégante que la reflection Java, et on peut également vérifier immédiatement (simplement) si un objet peut répondre à tel ou tel message, sans même connaître son type. Il est possible aussi d'enrichir les classes au runtime (ou les remplacer), et une notion de proxy est incluse nativement.
Quant à Groovy, il n'apporte rien par rapport à Objective-C, mis à part la compatibilité avec les JVM Java (mais exige une phase de compilation additionnelle, qui casse le rythme de développement). | | Commentaires | Poster un commentaire | |
|