De typescript à Java

Java a été présenté en 1995, Typescript en 2012, pourtant tu vas découvrir que ces deux langages ont une philosophie relativement proche. Cette quête sera l’occasion pour toi de voir les spécificités d’un langage, mais aussi de voir les concepts inhérents au paradigme orienté objet.

Objectifs

• Percevoir les nuances syntaxiques entre Java et TS
• Comprendre les différences philosophiques de ces deux langages
• Apprivoiser un changement de langage et entrevoir les éléments propres à un langage et les éléments inhérents à la programmation.

Ma première classe

Jusqu’ici, quand tu voulais créer un moule pour créer des objets (un patron), tu créais une classe. En java, c’est pareil.

Admettons qu’on travaille sur une application de gestion d’articles de presse. On cherche donc à donner une forme à notre article, pour faire de la POO (pour avoir les avantages qui en découlent : type checking / auto-complétion /gestion d’erreur).

1. L’enveloppe de ma classe

Pour rappel, en typescript, tu écrivais : article.ts

export class Article {
. . . 
}

En java :

Article.java En java le fichier commence par une majuscule

public class Article {
. . . 
}

Ici, le public indique que la classe est accessible de manière publique (c’est-à-dire partout). Il s’agit d’un modificateur d’accès.

En opposition à public, on aurait pu ne rien mettre, on aurait eu l’accesseur ‘default’, c’est-à-dire “package”, qui signifie : accessible dans le même package ≈ le même dossier (ou sous-dossier).

Les propriétés

Au niveau des propriétés, on peut dire qu’un article de presse a :

• un titre

• un texte

• une date de création

En typescript, le type (string, boolean, number, ..) vient à la suite du sujet et des ‘:’

1. Les types

export class Article {
    title: string;
    text: string;
    createAt: Date;
}

Le sujet peut être une propriété, une fonction, une variable

En Java le type se positionne juste avant le sujet

public class Article {
    private String title;
    private String text;
    private Date createAt;
}

Tu dois te demander quelle est l’utilité du mot “private”. C’est parce que les créateurs de Java ont jugé opportun d’avoir des objets, donc les propriétés ne sont pas accessibles par tout le monde. Un peu plus de détails dans la partie Getters et Setters.

Les subtilités pour le type String

Ici, les sujets sont exclusivement des propriétés, mais c’est une généralité également applicable aux méthodes de ma classe.

1. String: type complexe en Java, type primitif en TS

Tu as peut-être aussi remarqué qu’en java, chaque type commence par une majuscule (Date, String). On avait appris en typescript que le type complexe commençait par une Majuscule (comme la classe Article qu’on est en train d’écrire). Parallèlement, les types simples (primitifs) s’écrivaient en commençant par une minuscule ‘number’, ‘boolean’ et même ‘string’. Une des petites subtilités de Java réside dans le fait qu’une String n’est pas un type primitif en Java (c’est donc un type complexe qui a une classe pour le définir). Cela implique que “toto” == “toto” retourne false en java et true en Typescript. Parce qu’en java “toto” == “toto” ne correspond pas à une comparaison des valeurs, mais à une comparaison des références vers les valeurs toto. A la place, tu devras utiliser “toto”.equals(“toto”) et ceci est vrai pour tous les types complexes.

        boolean result = "toto".equals("toto"); // result = true
        boolean result1 = "toto".equals("tutu"); // result1 = false

Les méthodes des classes

Tu viens de découvrir les différences entre l’enveloppe Typescript et l’enveloppe Java d’une classe. Tu as pu remarquer que les mêmes concepts sont présents d’un côté comme de l’autre, mais il reste certaines différences de syntaxe ou d’approche philosophique. Il en est de même pour les méthodes d’une classe.

1. Getters et Setters

Jusqu’à maintenant, quand tu créais un objet du type Article, tu pouvais ensuite modifier ses propriétés :

const article = new Article();
article.title = ‘Super title’;
console.log(article.title); // Super title

Comme cela a été dit plus haut, le choix a été fait en Java d’encapsuler (de protéger) les mécaniques internes aux objets avec le modificateur d’accès “private”. Ce modificateur d’accès empêche le traitement effectué ci-dessus.

Java utilise ce qu’on appelle des Getters et Setters. Ce sont des méthodes très simples dont l’objectif est de get (récupérer) ou set (modifier) les propriétés des objets en question.

En java, on écrit donc :

import java.util.Date;

public class Article {
    private String title;
    private String text;
    private Date createAt;

    public String getTitle() {return this.title;}
    public void setTitle(String title) {this.title = title;}

    public String getText() {return this.text;}
    public void setText(String text) {this.text = text;}

    public Date getCreateAt() {return createAt;}
    public void setCreateAt(Date createAt) {this.createAt = createAt;}
}

Cette écriture succincte est, dans la majorité des cas, déconseillée, mais acceptable dans le contexte des getters/setters qui ne posent pas de pb de lecture/compréhension.

Comme tu peux le voir, pour chaque propriété, j’ai une méthode get et une méthode set avec respectivement la récupération de la valeur ou la modification.

L’exemple précédent en typescript s'écrit donc :

Article article = new Article(); // Plus de const let et var. Obligation de bien mettre le type dès le début 
article.setTitle(‘Super title’);
System.out.println(article.getTitle()); // Tu viens de découvrir au passage l’équivalent du console.log 

Alors que j’entends le vent souffler du : “C’est quand même contraignant de devoir écrire tout ça à chaque fois …”

• Il est de la philosophie du langage que de passer par ces accesseurs et mutateurs (getters/setters), tout le monde respecte cette règle et certains mécanismes internes reposent sur ce fonctionnement.

• Tous les IDEs (même vscode (avec extension)) proposent une génération automatique des Getters/Setters | constructor | toString | equals(la fameuse méthode equals vue plus haut)

Le constructeur

En typescript :

export class Article {
    title: string;
    text: string;
    createAt: Date;

    constructor(title: string, text: string, createAt: Date) {
        this.title = title; 
        this.text = text; 
        this.createAt = createAt; 
    }
}

En Java :

public class Article {
    private String title;
    private String text;
    private Date createAt;

    public Article(String title, String text, Date createAt) {
        this.title = title;
        this.text = text;
        this.createAt = createAt;
    }

    public String getTitle() {return title;}
    public void setTitle(String title) {this.title = title;}
    . . . 
}

La seule différence notable : en Typescript, le constructeur s’appelle grâce au mot-clé “constructor” alors qu’en java, il s’agit du nom de la classe.

Tu sais maintenant créer des objets (type complexe) en Java, exactement comme les types Date ou String, réfléchis à cela, ça t’aidera pour le challenge.

Challenge

Création d’objets

Clone ce répository

1. Lis le readme
2. Effectue les recherches nécessaires
3. Convertis l’ensemble des classes TS en Java
4. Envoie les modifications vers ton dépôt distant et partage le lien en solution

Critères de validation

• Tu n’utiliseras pas de tableaux java à la place des tableaux JS/TS
• javac User.java ne doit pas retourner d’erreur et créer 3 fichiers User.class, Photo.class et Address.class