vendredi 15 novembre 2013

Une pompe pour l'entretien

Dernièrement, un collègue a fait passer des entretiens techniques. Les questions ont l'air basiques au premier abord mais il est parfois difficile de répondre ou de prendre conscience de la réponse qu'attend l'interlocuteur.

J'ai moi même subi ce genre d'entretiens à distance, qui ne se sont pas tous passés de la meilleure des façons.

Alors je trouve assez intéressant de compiler des réponses ici, et surtout d'étayer car les réponses aux questions simples ne tiennent pas forcément en quelques mots...

Les réponses sont ciblées sur le langage Java.

Et c'est mon point de vue.

Allez, c'est parti.

Quel est le paradigme de programmation proposé par Java ?

Difficile à dire, Java est multi-paradigme pour moi. Il se traine des types primitifs qui ne sont pas des objets. Il serait possible de faire de la programmation procédurale en Java, en utilisant des méthodes statiques. Je vous rassure, la réponse attendue est que Java utilise le paradigme objet.

Quel est la différence entre les Objets et les types primitifs en Java ?

Les types primitifs sont passés par valeur et les objets par référence. Cela signifie que l'état d'un primitif ne peut pas être altéré par une méthode dont il est un paramètre, à la différence de l'objet.

Quels sont les apports de la programmation orientée objet ?

Certains diront que la programmation orientée objet permet de manipuler des abstractions proches des concepts métiers. Je ne le nie pas mais c'est plutôt du baratin d'architecte.

Pour le développeur, la POO permet de mutualiser du code d'une façon plus élégante que ce qu'il est possible de faire avec des langages procéduraux comme le C. L'intérêt de la POO vient du fait qu'elle est souvent associée aux caractéristiques suivantes :

  • Héritage : un objet peut être défini de façon à récupérer et enrichir des fonctionnalités d'un autre objet.
  • Polymorphisme : des objets remplissant une même fonction en utilisant des stratégies différentes peuvent être utilisés de façon transparente pour l'appelant.

Le cas extrême d'utilisation de ces deux caractéristiques se retrouvent dans le concept d'interfaces. Il s'agit entités ne définissant aucune fonctionnalité de façon concrète, qu'il est donc nécessaire d'enrichir par une forme d'héritage mais pouvant toutefois être utilisées dans la définition de nos traitements. Les fonctionnalités implémentées sont alors résolues à l'exécution grâce au polymorphisme.

Ces deux caractéristiques servent de base aux fameux design patterns.

Quelle est la différence entre une classe abstraite et une interface ?

Allez, deux pour le prix d'une :

  • L'interface ne peut pas définir de méthode concrète, la classe abstraite le peut.
  • L'interface ne peut pas définir de membre privé, la classe abstraite le peut.

Ces deux entités ne suivent pas le même objectif. Le but de l'interface est de définir un contrat de service attendu par ses clients. Une classe abstraite est là pour mutualiser du code, permettant aux classes concrètes qui les étendent de n'implémenter que le code nécessaire.

Dernière remarque : le concept d'interfaces est associé aux langages à typage statique, comme le C++, le Java ou le C# et n'a pas vraiment de sens dans les langages à typages dynamiques comme Python, Ruby ou PHP.

C'est quoi un design pattern, est-ce que vous en connaissez ?

Un design pattern, littéralement motif de conception est une approche élégante pour répondre à un problème courant. Vous voulez pouvoir appliquer un traitement aux éléments d'une arborescence, peut importe que l'élément soit un nœud ou une feuille : utilisez le pattern Composite. Vous voulez que des objets soient notifiés d'une modification dans le système : c'est le pattern Observer qu'il vous faut.

Les motifs les plus connus sont au nombre de 23 et ont été formalisés par 4 personnes décrites aujourd'hui comme le gang of four. Si vous voulez prospérer dans la programmation orientée objet, je vous conseille de faire l'achat d'un bouquin à lire et à garder près de vous.

C'est quoi la particularité de Java ?

C'est un langage produisant un programme exécuté dans une machine virtuelle, la JVM. Le principe est que seule l'implémentation de la JVM varie selon les systèmes d'exploitation. Ainsi, un même code compilé peut être exécuté sur tout environnement capable de faire tourner une JVM.

Une particularité moins connue est que le code n'est pas compilé sous forme d'instructions bas niveau exécutées par la VM, comme le serait du code assembleur. En effet, le compilateur Java traduit votre code source dans un format intermédiaire, le bytecode. Ce bytecode est ensuite interprété par la JVM qui utilisera diverses stratégies pour compiler les parties de votre bytecode en instructions natives executées par votre machine.

Pour éviter d'aller plus dans les détails, rappelez vous que javac traduit votre code en bytecode et que la jvm compile le bytecode en instructions machine.

C'est quoi JEE ?

C'est un standard regroupant un ensemble de spécifications visant à définir des applications d'entreprises reposant sur le langage Java. Les grosses boites d'informatiques comme Oracle et IBM peuvent ensuite vous proposer des implémentations de ces spécifications à prix d'or ! D'autres, comme la fondation Apache pense aux pauvres et fournissent des implémentations open source.

Contrairement à d'autres entreprise de l'IT, Sun (et maintenant Oracle) a décidé de partager la gouvernance sur la définition des standards liés à Java en mettant en place le principe de JCP. Cela permet à des entreprises comme des associations d'être parti prenante dans le contenu de ces spécifications.

Pêle-mêle et entre autre, JEE spécifie les façons pour les applications :

  • D'afficher du contenu via http (les servlets)
  • De communiquer entre les systèmes via des files de messages (JMS)
  • De pouvoir utiliser des objets en faisant abstraction des serveurs les hébergeant (EJB, JNDI)
  • De pouvoir faire persister des données (JPA)
  • De pouvoir communiquer entre applications sur le protocole HTTP (JAX RS, JAX WS) ...

Fin pour l'instant

J'espère que ces informations vont vous aider à retourner le crane de votre interrogateur zélé. J'en ai d'autres sous le coude, je prendrais peut-être le temps de les mettre dans un autre post.

Il y a pas mal de chose que l'on applique sans pour autant savoir l'expliquer, ou le nommer (comme pour le polymorphisme, les patterns ou JEE). Cela reste nécessaire de savoir expliquer ces concepts, d'une part car cela nous permet de nous affirmer en tant que professionnel, d'autre part parce que cela nous permet d'en avoir une connaissance plus précise. Comme disait Boileau :

« Ce qui se conçoit bien s'énonce clairement et les mots pour le dire viennent aisément »

Ou un truc du genre...

PS : j'ai certainement dit un peu de conneries, je laisse les sachants commenter.