ConceptionPackages.qmd

# Conception de packages

Le chapitre A36/F29\ {{< fa solid book >}}\ contient des directives pour la conception de packages. 
Notez que la notion de package n'existe pas en TypeScript (et en JavaScript), mais le principe de *namespace* (espace de nom) existe.
La @sec-NamespaceTypeScript explique quelques pratiques pour la gestion des *namespaces* en TypeScript.

Les points importants sont les suivants (les détails se trouvent dans le livre):

- La notation UML des diagrammes de packages;
- Organiser les packages par **cohésion**;
- Organiser les packages en une **famille d'interface** (convention Java);
- Créer un package par **tâche** et par **groupe de classes instables** (Branches);
- Les packages les plus responsables sont les plus stables;
- Factoriser (placer dans un package à part) les types indépendants;
- Utiliser **fabrique** (*factory*) pour limiter la dépendance aux packages concrets;
- Comment rompre les cycles dans les packages.

La @fig-DiagrammePackage est un exemple d'un diagramme de packages.

```{.plantuml genurl="true" #fig-DiagrammePackage caption="Diagramme de packages (tiré de la figure F12.6\ {{< fa solid book >}})."  }
@startuml
!include ecriture.pumlinclude
scale 0.8
allowmixing
package "Services Techniques" as ST <<Folder>> {
    package Persistance <<Folder>> {
    }
    package Sécurité <<Folder>> {
    }
    package Journalisation <<Folder>> {
    }
}
package Domaine as D <<Folder>> {
    package POS <<Folder>> {
    }
    package Stocks <<Folder>> {
    }
    package Taxes <<Folder>> {
    }
}

D -d[hidden]- ST

' skinparam legendfontsize 5
' legend center
' Filename: %filename()
' end legend

@enduml
```

## Absence de packages dans TypeScript {#sec-NamespaceTypeScript}

En effet, TypeScript n'a pas la notion de package comme dans C\# ou Java.
Cependant, il y a des pratiques pour organiser logiquement le code et pour éviter les conflits (les collisions) de noms.
Rappelons que la notion de package existe dans Java pour:

  1. **Organiser logiquement le code**: le type interface `java.util.List` est disponible dans la *bibliothèque* `java.util`);
  2. **Éviter les conflits de noms**: les classes `java.util.List` et `ca.etsmtl.log121.fuhrman.projet2.List` ont le même nom de base, mais puisqu'elles sont dans deux packages différents, elles peuvent être utilisées dans le même programme (leur "fully qualified name" est différent).

En TypeScript, on peut atteindre les mêmes objectifs.

### Organisation des éléments du code

L'organisation peut être réalisée grâce aux modules avec les mots-clés `export` et `import`. Par exemple:

```typescript
// maClasse.ts
export class MaClasse {
  // définition
}
```

```typescript
// client.ts
import { MaClasse } from './maClasse'
```

On organise les fichiers, par exemple `maClasse.ts`, dans les répertoires.

### Noms sans conflit

Dans l'exemple précédent, il ne serait pas possible d'avoir deux fichiers nommés `maClasse.ts` dans le même répertoire, alors il est impossible d'avoir une collision avec le nom du fichier.
Donc, on pourrait importer la classe `MaClasse` de `maClasse.ts` et la classe `MaClasse` de `lib/projet2/maClasse.ts` dans le même programme.
Cependant, pour éviter un conflit de noms, on emploie le mot-clé `as` pour renommer la classe (`MaClasseP2`) lorsqu'on l'importe:

```typescript
// client.ts
import { MaClasse } from './maClasse'
import { MaClasse as MaClasseP2 } from './lib/projet2/maClasse'
```

### Namespaces

TypeScript offre une autre manière pour organiser et éviter les conflits de noms avec les *[namespaces](https://www.typescriptlang.org/docs/handbook/namespaces.html)* (anciennement les *modules internes*).
L'[exemple de Validators](https://www.typescriptlang.org/docs/handbook/namespaces.html#namespaced-validators) est intéressant puisqu'il s'agit d'un *namespace* commun réparti dans plusieurs fichiers.
C'est à utiliser surtout lorsqu'on ne veut pas centraliser tout le code dans un seul (gros) fichier (avec `export`). 
Mais, comme vous le voyez dans l'exemple, on doit utiliser les commentaires dans le code de certains fichiers, par exemple  
`/// <reference path="Validation.ts" />`, et c'est plus compliqué à maintenir.