| Prochaine révision | Révision précédente |
| boardz:design:designchoices [2019/05/07 09:34] – créée admin | boardz:design:designchoices [2025/12/10 16:16] (Version actuelle) – modification externe 127.0.0.1 |
|---|
| | | {{ :avignon-universite.jpg?nolink|}} | {{ :blocks:logo-apl.png?nolink&220|}} | |
| | |
| ===== Options de Design ===== | ===== Options de Design ===== |
| |
| Pour cela une "patternisation" de base du projet doit être mise en place, ainsi que des concepts de design forts et structurants. | Pour cela une "patternisation" de base du projet doit être mise en place, ainsi que des concepts de design forts et structurants. |
| |
| * Conception "Full Object" : Elle doit garantir, (aux librairies tierces opensource) la portabilité du projet dans d'autres langages plus performants. Pour les libriaires tierces qui ne peuvent garantir elles-mêmes le portage, le design pattern de **Façade** doit être utilisé. | * Conception "Full Object" : Elle doit garantir, (aux librairies tierces open source) la portabilité du projet dans d'autres langages plus performants. Pour les librairies tierces qui ne peuvent garantir elles-mêmes le portage, le design pattern de **Façade** doit être utilisé. |
| * Utilisation de design patterns classiques : | * Utilisation de design patterns classiques : |
| * Toute fonctionnalité ou "aspect" de traitement à vocation unique doit être encapsulé dans un pattern **Singleton"" et produire une classe statique ou quasi-statique. | * Toute fonctionnalité ou "aspect" de traitement à vocation unique doit être encapsulé dans un pattern **Singleton** et produire une classe statique ou quasi-statique. |
| * Toute utilisation d'un principe étant potentiellement voué à une augmentation, évolution ou alternative future devrait utiliser le principe de **Fabrique**. | * Toute utilisation d'un principe étant potentiellement voué à une augmentation, évolution ou alternative future devrait utiliser le principe de **Fabrique**. |
| * Le pattern d'**Inversion de Contrôle** (IOC) sera utilisé pour optimiser la répartition des responsabilités entre objetS. | * Le pattern d'**Inversion de Contrôle** (IOC) sera utilisé pour optimiser la répartition des responsabilités entre objets. |
| * Le pattern **Poids Mouche** (flyweight) sera utilisé pour minimiser l'impact mémoire lors de l'appel à des définitions partielles de données. | * Le pattern **Poids Mouche** (flyweight) sera utilisé pour minimiser l'impact mémoire lors de l'appel à des définitions partielles de données. |
| | |
| | ==== Principes et orientations du design technique ==== |
| | |
| | * **Adaptabilité** : |
| | * **Abstraction maîtrisée** : L'abstraction peut avoir de grandes qualité (factorisation importante du code, productivité importante de l'écriture), mais peut, si elle est poussée trop loin, peut avoir de gros inconvénients dans un projet (problème de performance dû à l'indirection d'accès aux données, opacité des données physiques relativement à leur destination, perte de maniabilité des données dans le modèle physique de données). Nous conserverons un "mi-chemin" permettant d'obtenir des gains "pragmatiques" de certaines décisions d'abstraction, en évitant une application dogmatique de la normalisation à outrance des structures de données. |
| | |
| | [[:boardz:design:boardzframework|Framework objet Boardz2]] |
| | |
| | |
| | ---- |
| | [[:boardz:design|Revenir au sommaire de la conception]] - [[:start|Revenir au sommaire général]] |
| | |
