Les pro­to­coles et la pro­blé­ma­tique de la confor­mi­té

L'Informaticien - - DÉVELOPPEM­ENT / IOS -

Les pro­to­coles en Ob­jec­tive-C re­pré­sentent une ma­nière dif­fé­rente et bien spé­ci­fique à ce lan­gage de faire hé­ri­ter une classe, en se fo­ca­li­sant uni­que­ment sur les mé­thodes. L’or­ga­ni­sa­tion des ob­jets entre eux dans les fra­me­works Foun­da­tion et AppKit n’est pas tout à fait si­mi­laire à celle des autres bi­blio­thèques orien­tées ob­jet telles que Qt ou autres .Net. Dans ces der­nières, le dé­ve­lop­peur donne en quelque sorte des ordres aux ob­jets. C’est lui qui va dire à un ob­jet de s’af­fi­cher, qui va af­fec­ter la va­leur d’une case à un ta­bleau, etc. Les classes créées par le pro­gram­meur vont com­man­der les autres ob­jets. Dans le fra­me­work Co­coa ain­si que dans GNUs­tep, son équi­valent Open Source, c’est l’in­verse qui se pro­duit. La plu­part des ob­jets de ce fra­me­work pos­sèdent une va­riable de­le­gate de type id. C’est cet ob­jet qui va ai­der les autres ob­jets à exé­cu­ter la tâche qui leur est dé­vo­lue. Un pro­to­cole est donc, en fait, une liste de mé­thodes qu’une classe doit im­pé­ra­ti­ve­ment im­plé­men­ter. C’est presque l’équi­valent des in­ter­faces en Ja­va. C’est dans l’in­ter­face – au sens Ob­jec­tive-C, bien sûr – que vous de­vez spé­ci­fier l’ap­pli­ca­tion d’un pro­to­cole à une classe, comme ce­la : @in­ter­face RSSC­han­nel : NSOb­ject < NSXMLPar­serDe­le­gate > Cette ligne im­plique que la classe RSSC­han­nel, en plus d’hé­ri­ter de la classe NSOb­ject, doit se confor­mer au pro­to­cole NSXMLPar­serDe­le­gate et, par consé­quent, im­plé­men­ter les mé­thodes qui y sont dé­cla­rées.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.