book/fr/introduction/GeoAPI.html - sis-site - Git at Google

 <?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE html>

 <!--
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   "License"); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.
 -->

 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
   <head>
     <title>GeoAPI</title>
     <meta charset="UTF-8"/>
     <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
   </head>
   <body>
     <!--
       Content below this point is copied in "../../content/book/fr/developer-guide.html"
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
     <section>
       <header>
         <h2 id="GeoAPI">Des modèles conceptuels vers des interfaces Java: GeoAPI</h2>
       </header>
       <p>
         Le projet <a href="http://www.geoapi.org">GeoAPI</a> offre un ensemble d’interfaces Java pour les applications géo-spatiales.
         Dans une séries de paquets <code>org.opengis.*</code>, GeoAPI définit des structures représentant des méta-données,
         des systèmes de référence des coordonnées, ainsi que des opérations effectuant des projections cartographiques.
         Dans une partie qui n’est pas encore standardisée — dénommée <i>pending</i> — GeoAPI définit des structures
         représentant des images géo-référencées, des géométries, des filtres pouvant s’appliquer à des requêtes, et d’autres fonctionnalités.
         Ces interfaces suivent de très près les spécifications de l’<abbr>OGC</abbr>, tout en les interprétant et en les adaptant
         de manière à répondre aux attentes des développeurs Java — par exemple en se conformant aux conventions de nommage.
         Ces interfaces bénéficient à la fois aux applications clientes et aux bibliothèques:
       </p>
       <ul>
         <li><p>
           Les développeurs des applications clientes bénéficient d’une plus grande base de connaissances disponible sur internet
           (due aux nombreuses publications en lien avec les standards de l’<abbr>OGC</abbr>), ainsi que d’une interopérabilité accrue.
           L’interopérabilité est facilitée par une meilleure séparation entre les applications qui <em>appellent</em> les fonctions de GeoAPI,
           et les bibliothèques qui <em>implémentent</em> GeoAPI. Il s’agit d’une séparation similaire à celle qu’offrent les interfaces
           <a href="http://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/"><abbr>JDBC</abbr></a> (<i>Java Database Connectivity</i>) du Java standard.
           En utilisant l’<abbr>API</abbr> des interfaces, les développeurs peuvent faire abstraction de l’implémentation sous-jacente.
           Par exemple ils peuvent effectuer des projections cartographiques à l’aide des bibliothèques
           <a href="http://www.geoapi.org/geoapi-proj4/index.html">Proj.4</a> ou Apache <abbr>SIS</abbr>,
           sans changer leurs programmes lorsqu’ils changent de bibliothèque.
         </p></li>
         <li><p>
           Les développeurs des bibliothèques héritent de l’expertise des auteurs des spécifications, via les modèles que représentent les interfaces.
           GeoAPI fournit aussi un cadre dans lequel les développeurs peuvent implémenter en priorité les fonctionnalité qui leurs sont le plus nécessaires,
           tout en ayant des points où raccrocher les développements futurs.
           Par exemple les clients peuvent appeler une fonction de GeoAPI même si elle n’est pas encore supportée par la bibliothèque,
           quitte à obtenir une valeur nulle en attendant qu’une nouvelle version de la bibliothèque retourne une valeur intéressante.
         </p></li>
       </ul>

       <details>
         <summary>Pour en savoir plus sur les origines du projet GeoAPI</summary>
         <article id="GeoAPI-history">
           <header>
             <h2>Historique du projet GeoAPI</h2>
           </header>
           <p>
             En 2001, le consortium <i>Open GIS</i> (l’ancien nom du consortium <i>Open Geospatial</i>) publia la spécification d’implémentation
             <a href="https://www.ogc.org/standards/ct"><abbr>OGC</abbr> 01-009: <cite>Coordinate Transformation Services</cite></a>.
             Cette spécification, élaborée par <i>Computer Aided Development Corporation</i> (Cadcorp),
             était accompagnée d’interfaces <abbr>COM</abbr>, <abbr>CORBA</abbr> et Java.
             À cette époque, la vague des services web n’avait pas encore éclipsé les interfaces de programmation classiques.
             Les interfaces de l’<abbr>OGC</abbr> anticipaient tout de même un monde connecté en réseau,
             mais misaient plutôt — dans le cas du Java — sur la technologie <abbr>RMI</abbr> (<i>Remote Method Invocation</i>).
             Bien que le projet GeoAPI n’existait pas encore, nous désignons rétrospectivement ces interfaces historiques sous le nom de
             « <a href="http://www.geoapi.org/0.1/index.html">GeoAPI 0.1</a> ».
             Ces interfaces utilisaient déjà le nom de paquet <code>org.opengis</code>, qui sera adopté par GeoAPI.
           </p><p>
             En 2002, des développeurs de projets libres ont lancé un
             <a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">appel à la création d’un <abbr>API</abbr> géo-spatial</a>.
             La proposition initiale suscita l’intérêt d’au moins cinq projets libres.
             Le projet fut créé sur <a href="http://sourceforge.net/projects/geoapi/">SourceForge</a>,
             qui héberge depuis lors le code source dans un <a href="http://www.geoapi.org/source-repository.html">dépôt Subversion</a>.
             Le projet pris le nom de « GeoAPI » à ce moment là, et utilisa les interfaces de la spécification <abbr>OGC</abbr> 01-009 comme point de départ.
           </p><p>
             Quelques mois plus tard, l’<abbr>OGC</abbr> lança le projet
             <a href="https://www.ogc.org/standards/go"><abbr>GO-1</abbr>: <i>Geographic Objects</i></a>,
             qui poursuivait des buts similaires à ceux de GeoAPI.
             Entre-temps, l’<abbr>OGC</abbr> avait abandonné certaines de leur spécifications en faveur des normes <abbr>ISO</abbr>.
             GeoAPI et <abbr>GO-1</abbr> ont joint leurs efforts pour une refonte des interfaces de GeoAPI en les basant sur ces nouvelles normes <abbr>ISO</abbr>.
             La première mouture, <a href="http://www.geoapi.org/1.0/index.html">GeoAPI 1.0</a>, a servit de point de départ
             aux premières ébauches de la spécification <abbr>OGC</abbr> 03-064 du groupe de travail <abbr>GO</abbr>-1.
             La version finale de cette spécification est devenue un standard <abbr>OGC</abbr> en 2005, et
             <a href="http://www.geoapi.org/2.0/index.html">GeoAPI 2.0</a> a été publiée à cette occasion.
           </p><p>
             Le projet <abbr>GO</abbr>-1 était porté essentiellement par une compagnie nommée <i>Polexis</i>.
             Son rachat par <i>Sys Technology</i> et le changement de priorité des nouveaux propriétaires
             ont causé l’arrêt des travaux de <abbr>GO</abbr>-1, et par ricochet un ralentissement des développements de GeoAPI.
             Afin de reprendre les développements, un nouveau groupe de travail « GeoAPI 3.0 » a été créé à l’<abbr>OGC</abbr>.
             Ce groupe a réduit les ambitions par rapport à GeoAPI 2.0 en se concentrant sur les interfaces les plus stables,
             et en plaçant les autres — notamment les géométries — dans un module nommé « <a href="http://www.geoapi.org/geoapi-pending/index.html">pending</a> »,
             pour considérations futures. <a href="http://www.geoapi.org/3.0/index.html">GeoAPI 3.0</a> est devenu un
             <a href="https://www.ogc.org/standards/geoapi">standard <abbr>OGC</abbr></a> en 2011.
             Cette version a été la première à être déployée dans le <a href="http://search.maven.org/#search|ga|1|geoapi">dépôt central de Maven</a>.
           </p>
         </article>
       </details>

       <p id="GeoAPI-core">
         GeoAPI est constitué de plusieurs modules.
         Les modules <code>geoapi</code> et <code>geoapi-pending</code>
         fournissent les interfaces dérivées des schémas <abbr>UML</abbr> des standards internationaux.
         Le modèle conceptuel sera expliqué en détails dans les chapitres décrivant l’implémentation Apache <abbr>SIS</abbr>.
         On peut toutefois avoir un aperçu de son contenu en consultant la page listant les
         <a href="http://www.geoapi.org/3.0/javadoc/content.html">types et méthodes de GeoAPI et les standards d’où ils proviennent</a>.
         Ces modules ainsi que la correspondance entre GeoAPI et les standards internationaux sont décrits plus en détails
         <a href="#SpecificationToInterfaces">en annexe</a>.
       </p>


       <h3 id="GeoAPI-implementation">Implémentations fournies par Apache SIS</h3>
       <p>
         Apache SIS implémente la plupart des interfaces de GeoAPI avec une classe du même nom que l’interface,
         mais préfixée de « <code>Abstract</code> », « <code>Default</code> » ou « <code>General</code> ».
         Les classes de Apache SIS qui sont préfixées par « <code>Default</code> » peuvent être instanciées directement
         par une instruction <code>new DefaultXXX(…)</code> ou par la méthode <code>createXXX(…)</code> correspondante d’une fabrique.
       </p>
       <div class="example"><b>Example:</b> pour représenter un système de référence de coordonnées projetées (Mercator, Lambert, <i>etc</i>):
         <ul>
           <li><code>org.opengis.referencing.crs.ProjectedCRS</code> est l’interface définie par GeoAPI sur la base du standard ISO 19111, et</li>
           <li><code>org.apache.sis.referencing.crs.DefaultProjectedCRS</code> est l’implémentation fournie par Apache SIS.</li>
         </ul>
         Une instance peut être créée par:
         <ul>
           <li><code>ProjectedCRS crs = new DefaultProjectedCRS(…)</code>, ou</li>
           <li><code>ProjectedCRS crs = CRSFactory.createProjectedCRS(…)</code>.</li>
         </ul>
         Les deux approches attendent les mêmes arguments (omis dans cet exemple).
       </div>
       <p>
         Dans la configuration par défaut de Apache SIS,
         utiliser <code>FooFactory.createXXX(…)</code> ou <code>new DefaultXXX(…)</code> revient presque au même
         excepté que les <code>FooFactory</code> peuvent retourner des instances existantes
         plutôt que de créer systématiquement de nouvelles instances,
         et que les exceptions en cas d’arguments invalides sont de types différents.
         Dans des configurations plus avancées, l’usage des <code>Factory</code> permet de
         <a href="#ServiceLoader">réduire la dépendance directe d’une application envers SIS</a>
         et de permettre une inversion de contrôle.
       </p><p>
         Le préfix « <code>General</code> » est parfois utilisé à la place de « <code>Default</code> »
         afin de signaler que des implémentations alternatives existent pour des cas spécifiques.
         Par exemple l’interface <code>Envelope</code> est implémentée par au moins deux classes de Apache SIS:
         <code>GeneralEnvelope</code> et <code>Envelope2D</code>.
         La première implémentation peut représenter des enveloppes de n’importe quelle dimension
         alors que la seconde implémentation est spécialisée pour les enveloppes à deux dimensions.
       </p><p>
         Les classes de Apache SIS qui sont préfixées par « <code>Abstract</code> » ne doivent pas – en principe – être instanciées.
         Il faut plutôt instancier une sous-classe non-abstraites.
         Toutefois plusieurs classes de SIS ne sont abstraites que conceptuellement,
         sans que la définition de la classe ne contienne le mot-clé <code>abstract</code> du Java.
         Ces classes peuvent être instanciées par l’instruction <code>new AbstractXXX(…)</code>
         – mais pas par les <code>Factory</code> – malgré qu’elles soient conceptuellement abstraites.
         Mais ces instanciations ne devraient être faites qu’en dernier recours,
         lorsqu’il n’est vraiment pas possible de déterminer le sous-type exact.
       </p>
     </section>
   </body>
 </html>
	<?xml version="1.0" encoding="UTF-8" ?>
	<!DOCTYPE html>

	<!--
	Licensed to the Apache Software Foundation (ASF) under one
	or more contributor license agreements. See the NOTICE file
	distributed with this work for additional information
	regarding copyright ownership. The ASF licenses this file
	to you under the Apache License, Version 2.0 (the
	"License"); you may not use this file except in compliance
	with the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing,
	software distributed under the License is distributed on an
	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	KIND, either express or implied. See the License for the
	specific language governing permissions and limitations
	under the License.
	-->

	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
	<head>
	<title>GeoAPI</title>
	<meta charset="UTF-8"/>
	<link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
	</head>
	<body>
	<!--
	Content below this point is copied in "../../content/book/fr/developer-guide.html"
	by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
	-->
	<section>
	<header>
	<h2 id="GeoAPI">Des modèles conceptuels vers des interfaces Java: GeoAPI</h2>
	</header>
	<p>
	Le projet <a href="http://www.geoapi.org">GeoAPI</a> offre un ensemble d’interfaces Java pour les applications géo-spatiales.
	Dans une séries de paquets <code>org.opengis.*</code>, GeoAPI définit des structures représentant des méta-données,
	des systèmes de référence des coordonnées, ainsi que des opérations effectuant des projections cartographiques.
	Dans une partie qui n’est pas encore standardisée — dénommée <i>pending</i> — GeoAPI définit des structures
	représentant des images géo-référencées, des géométries, des filtres pouvant s’appliquer à des requêtes, et d’autres fonctionnalités.
	Ces interfaces suivent de très près les spécifications de l’<abbr>OGC</abbr>, tout en les interprétant et en les adaptant
	de manière à répondre aux attentes des développeurs Java — par exemple en se conformant aux conventions de nommage.
	Ces interfaces bénéficient à la fois aux applications clientes et aux bibliothèques:
	</p>
	<ul>
	<li><p>
	Les développeurs des applications clientes bénéficient d’une plus grande base de connaissances disponible sur internet
	(due aux nombreuses publications en lien avec les standards de l’<abbr>OGC</abbr>), ainsi que d’une interopérabilité accrue.
	L’interopérabilité est facilitée par une meilleure séparation entre les applications qui <em>appellent</em> les fonctions de GeoAPI,
	et les bibliothèques qui <em>implémentent</em> GeoAPI. Il s’agit d’une séparation similaire à celle qu’offrent les interfaces
	<a href="http://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/"><abbr>JDBC</abbr></a> (<i>Java Database Connectivity</i>) du Java standard.
	En utilisant l’<abbr>API</abbr> des interfaces, les développeurs peuvent faire abstraction de l’implémentation sous-jacente.
	Par exemple ils peuvent effectuer des projections cartographiques à l’aide des bibliothèques
	<a href="http://www.geoapi.org/geoapi-proj4/index.html">Proj.4</a> ou Apache <abbr>SIS</abbr>,
	sans changer leurs programmes lorsqu’ils changent de bibliothèque.
	</p></li>
	<li><p>
	Les développeurs des bibliothèques héritent de l’expertise des auteurs des spécifications, via les modèles que représentent les interfaces.
	GeoAPI fournit aussi un cadre dans lequel les développeurs peuvent implémenter en priorité les fonctionnalité qui leurs sont le plus nécessaires,
	tout en ayant des points où raccrocher les développements futurs.
	Par exemple les clients peuvent appeler une fonction de GeoAPI même si elle n’est pas encore supportée par la bibliothèque,
	quitte à obtenir une valeur nulle en attendant qu’une nouvelle version de la bibliothèque retourne une valeur intéressante.
	</p></li>
	</ul>

	<details>
	<summary>Pour en savoir plus sur les origines du projet GeoAPI</summary>
	<article id="GeoAPI-history">
	<header>
	<h2>Historique du projet GeoAPI</h2>
	</header>
	<p>
	En 2001, le consortium <i>Open GIS</i> (l’ancien nom du consortium <i>Open Geospatial</i>) publia la spécification d’implémentation
	<a href="https://www.ogc.org/standards/ct"><abbr>OGC</abbr> 01-009: <cite>Coordinate Transformation Services</cite></a>.
	Cette spécification, élaborée par <i>Computer Aided Development Corporation</i> (Cadcorp),
	était accompagnée d’interfaces <abbr>COM</abbr>, <abbr>CORBA</abbr> et Java.
	À cette époque, la vague des services web n’avait pas encore éclipsé les interfaces de programmation classiques.
	Les interfaces de l’<abbr>OGC</abbr> anticipaient tout de même un monde connecté en réseau,
	mais misaient plutôt — dans le cas du Java — sur la technologie <abbr>RMI</abbr> (<i>Remote Method Invocation</i>).
	Bien que le projet GeoAPI n’existait pas encore, nous désignons rétrospectivement ces interfaces historiques sous le nom de
	« <a href="http://www.geoapi.org/0.1/index.html">GeoAPI 0.1</a> ».
	Ces interfaces utilisaient déjà le nom de paquet <code>org.opengis</code>, qui sera adopté par GeoAPI.
	</p><p>
	En 2002, des développeurs de projets libres ont lancé un
	<a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">appel à la création d’un <abbr>API</abbr> géo-spatial</a>.
	La proposition initiale suscita l’intérêt d’au moins cinq projets libres.
	Le projet fut créé sur <a href="http://sourceforge.net/projects/geoapi/">SourceForge</a>,
	qui héberge depuis lors le code source dans un <a href="http://www.geoapi.org/source-repository.html">dépôt Subversion</a>.
	Le projet pris le nom de « GeoAPI » à ce moment là, et utilisa les interfaces de la spécification <abbr>OGC</abbr> 01-009 comme point de départ.
	</p><p>
	Quelques mois plus tard, l’<abbr>OGC</abbr> lança le projet
	<a href="https://www.ogc.org/standards/go"><abbr>GO-1</abbr>: <i>Geographic Objects</i></a>,
	qui poursuivait des buts similaires à ceux de GeoAPI.
	Entre-temps, l’<abbr>OGC</abbr> avait abandonné certaines de leur spécifications en faveur des normes <abbr>ISO</abbr>.
	GeoAPI et <abbr>GO-1</abbr> ont joint leurs efforts pour une refonte des interfaces de GeoAPI en les basant sur ces nouvelles normes <abbr>ISO</abbr>.
	La première mouture, <a href="http://www.geoapi.org/1.0/index.html">GeoAPI 1.0</a>, a servit de point de départ
	aux premières ébauches de la spécification <abbr>OGC</abbr> 03-064 du groupe de travail <abbr>GO</abbr>-1.
	La version finale de cette spécification est devenue un standard <abbr>OGC</abbr> en 2005, et
	<a href="http://www.geoapi.org/2.0/index.html">GeoAPI 2.0</a> a été publiée à cette occasion.
	</p><p>
	Le projet <abbr>GO</abbr>-1 était porté essentiellement par une compagnie nommée <i>Polexis</i>.
	Son rachat par <i>Sys Technology</i> et le changement de priorité des nouveaux propriétaires
	ont causé l’arrêt des travaux de <abbr>GO</abbr>-1, et par ricochet un ralentissement des développements de GeoAPI.
	Afin de reprendre les développements, un nouveau groupe de travail « GeoAPI 3.0 » a été créé à l’<abbr>OGC</abbr>.
	Ce groupe a réduit les ambitions par rapport à GeoAPI 2.0 en se concentrant sur les interfaces les plus stables,
	et en plaçant les autres — notamment les géométries — dans un module nommé « <a href="http://www.geoapi.org/geoapi-pending/index.html">pending</a> »,
	pour considérations futures. <a href="http://www.geoapi.org/3.0/index.html">GeoAPI 3.0</a> est devenu un
	<a href="https://www.ogc.org/standards/geoapi">standard <abbr>OGC</abbr></a> en 2011.
	Cette version a été la première à être déployée dans le <a href="http://search.maven.org/#search\|ga\|1\|geoapi">dépôt central de Maven</a>.
	</p>
	</article>
	</details>

	<p id="GeoAPI-core">
	GeoAPI est constitué de plusieurs modules.
	Les modules <code>geoapi</code> et <code>geoapi-pending</code>
	fournissent les interfaces dérivées des schémas <abbr>UML</abbr> des standards internationaux.
	Le modèle conceptuel sera expliqué en détails dans les chapitres décrivant l’implémentation Apache <abbr>SIS</abbr>.
	On peut toutefois avoir un aperçu de son contenu en consultant la page listant les
	<a href="http://www.geoapi.org/3.0/javadoc/content.html">types et méthodes de GeoAPI et les standards d’où ils proviennent</a>.
	Ces modules ainsi que la correspondance entre GeoAPI et les standards internationaux sont décrits plus en détails
	<a href="#SpecificationToInterfaces">en annexe</a>.
	</p>



	<h3 id="GeoAPI-implementation">Implémentations fournies par Apache SIS</h3>
	<p>
	Apache SIS implémente la plupart des interfaces de GeoAPI avec une classe du même nom que l’interface,
	mais préfixée de « <code>Abstract</code> », « <code>Default</code> » ou « <code>General</code> ».
	Les classes de Apache SIS qui sont préfixées par « <code>Default</code> » peuvent être instanciées directement
	par une instruction <code>new DefaultXXX(…)</code> ou par la méthode <code>createXXX(…)</code> correspondante d’une fabrique.
	</p>
	<div class="example"><b>Example:</b> pour représenter un système de référence de coordonnées projetées (Mercator, Lambert, <i>etc</i>):
	<ul>
	<li><code>org.opengis.referencing.crs.ProjectedCRS</code> est l’interface définie par GeoAPI sur la base du standard ISO 19111, et</li>
	<li><code>org.apache.sis.referencing.crs.DefaultProjectedCRS</code> est l’implémentation fournie par Apache SIS.</li>
	</ul>
	Une instance peut être créée par:
	<ul>
	<li><code>ProjectedCRS crs = new DefaultProjectedCRS(…)</code>, ou</li>
	<li><code>ProjectedCRS crs = CRSFactory.createProjectedCRS(…)</code>.</li>
	</ul>
	Les deux approches attendent les mêmes arguments (omis dans cet exemple).
	</div>
	<p>
	Dans la configuration par défaut de Apache SIS,
	utiliser <code>FooFactory.createXXX(…)</code> ou <code>new DefaultXXX(…)</code> revient presque au même
	excepté que les <code>FooFactory</code> peuvent retourner des instances existantes
	plutôt que de créer systématiquement de nouvelles instances,
	et que les exceptions en cas d’arguments invalides sont de types différents.
	Dans des configurations plus avancées, l’usage des <code>Factory</code> permet de
	<a href="#ServiceLoader">réduire la dépendance directe d’une application envers SIS</a>
	et de permettre une inversion de contrôle.
	</p><p>
	Le préfix « <code>General</code> » est parfois utilisé à la place de « <code>Default</code> »
	afin de signaler que des implémentations alternatives existent pour des cas spécifiques.
	Par exemple l’interface <code>Envelope</code> est implémentée par au moins deux classes de Apache SIS:
	<code>GeneralEnvelope</code> et <code>Envelope2D</code>.
	La première implémentation peut représenter des enveloppes de n’importe quelle dimension
	alors que la seconde implémentation est spécialisée pour les enveloppes à deux dimensions.
	</p><p>
	Les classes de Apache SIS qui sont préfixées par « <code>Abstract</code> » ne doivent pas – en principe – être instanciées.
	Il faut plutôt instancier une sous-classe non-abstraites.
	Toutefois plusieurs classes de SIS ne sont abstraites que conceptuellement,
	sans que la définition de la classe ne contienne le mot-clé <code>abstract</code> du Java.
	Ces classes peuvent être instanciées par l’instruction <code>new AbstractXXX(…)</code>
	– mais pas par les <code>Factory</code> – malgré qu’elles soient conceptuellement abstraites.
	Mais ces instanciations ne devraient être faites qu’en dernier recours,
	lorsqu’il n’est vraiment pas possible de déterminer le sous-type exact.
	</p>
	</section>
	</body>
	</html>