◎ Introduction : Paradigmes de programmation
01 L'ère des paradigmes
02 Paradigme de programmation

◎ Chapitre 1 : Objets, Conception
01.
Mise en œuvre d'une application de vente de billets
02.
Quel est le problème ?
___code qui s'écarte des attentes
Code vulnérable aux changements ___
03.
Améliorer la conception
Accroissons l'autonomie
___Ce qui a été amélioré
___Comment avez-vous fait ?
___Encapsulation et cohésion
___Procédural et orienté objet
___Changement de responsabilité
___peut être amélioré davantage
___Ouais, c'est un mensonge !
04.
conception orientée objet
Pourquoi le design est-il nécessaire ?
conception orientée objet

◎ Chapitre 2 : Programmation orientée objet
01.
système de réservation de billets de cinéma
___ Examiner les exigences
02.
Vers la programmation orientée objet
___ collaboration, objet, classe
Structure du programme qui suit la structure du domaine ___
Implémentation de la classe ___
___ une communauté d'objets coopérants
___ Une courte histoire sur la collaboration
03.
Bénéficiez d'un tarif réduit
___ Commencez à travailler ensemble pour calculer les taux d'escompte
Politique et conditions de réduction
___ Configurer une politique de réduction
04.
Hérédité et polymorphisme
Dépendances à la compilation et dépendances à l'exécution
Programmation par différence
___ Héritage et interfaces
___ polymorphisme
___ Interfaces et polymorphisme
05.
Abstraction et flexibilité
___ Le pouvoir de l'abstraction
Conception flexible
Compromis entre classes abstraites et interfaces
Réutilisation du code
___ héritage
___ synthèse

◎ Chapitre 3 : Rôles, responsabilités et coopération
01.
coopération
___ Retour sur le système de réservation de billets de cinéma
___ coopération
La collaboration détermine le contexte de la conception
02.
responsabilité
Qu'est-ce que la responsabilité ___ ?
___ Attribution des responsabilités
Conception axée sur la responsabilité
Le message ___ détermine l'objet
Les actions ___ déterminent le statut
03.
rôle
___ Rôles et collaboration
___ Collaboration flexible et réutilisable
___ Objets vs. Rôles
___ Rôles et abstractions
___ acteurs et rôles

◎ Chapitre 4 : Qualité de la conception et compromis
01.
Système de réservation de billets de cinéma basé sur les données
Préparons les données ___
Réservons des billets pour le film ___
02.
Compromis de conception
___ encapsulation
Cohésion et couplage
03.
Les problèmes des systèmes de billetterie de cinéma basés sur les données
___ Violation de l'encapsulation
___ couplage élevé
___ faible cohésion
___ Conserver l'encapsulation
04.
Vers des objets autonomes
___ Objets responsables de leurs propres données
___ Violation de l'encapsulation
05.
Mais ce n'est toujours pas suffisant
___ couplage élevé
___ faible cohésion
La conception axée sur les données se concentre sur l'état des objets plutôt que sur leur comportement.
06.
Les défis de la conception axée sur les données
La conception centrée sur les données vous oblige à définir des opérations sur des objets isolément.

Chapitre 5 : Attribution des responsabilités
01.
Vers une conception axée sur la responsabilité
Décidez d'agir avant de traiter les données.
Déterminer les responsabilités dans le cadre de la collaboration
Conception axée sur la responsabilité
02.
Modèle GRASP pour l'attribution des responsabilités
Partant du concept de domaine ___
___ Attribuer la responsabilité aux professionnels de l'information
___ forte cohésion et faible couplage
___ Attribuer la responsabilité de la création de l'objet au créateur
03.
Vérification par la mise en œuvre
___ Améliorer les conditions de remise
Séparer les types ___
___ Séparation par polymorphisme
Protéger des changements
___ Améliorer le cours de cinéma
___ Changement et flexibilité
04.
Alternatives à la conception axée sur la responsabilité
méthode de cohésion
Rendons les objets ___ autonomes

◎ Chapitre 6 : Messages et interfaces
01.
Collaboration et messages
Modèle client-serveur
Messages et transmission des messages
___ messages et méthodes
___ Interface publique et opérations
___ Signature
02.
Qualité de l'interface et du design
___ Ne posez pas de questions, commandez simplement
___ Une interface qui révèle l'intention
___ En résumé
03.
Le piège des principes
La règle de Déméter n'est pas une règle qui impose un seul point (.).
___ Conflit entre couplage et cohésion
04.
Principe de séparation des commandes et des requêtes
___ Séparation des commandes et des requêtes des planifications récurrentes
___ Séparation des commandes et des requêtes et transparence référentielle
___ Mettre l'accent sur la responsabilité

◎ Chapitre 7 : Décomposition d'objets
01.
Abstraction des procédures et abstraction des données
02.
Abstraction procédurale et décomposition fonctionnelle
___ Le système comme fonction principale
Système de gestion de la paie
___ Mise en place d'un système de gestion de la paie
___ Problèmes liés à la décomposition fonctionnelle descendante
___ Quand la décomposition descendante est-elle utile ?
03.
module
___ Masquage d'informations et modules
Avantages et limites du module ___
04.
Abstraction des données et types de données abstraits
___ type de données abstrait
05.
classe
La classe ___ est-elle un type de données abstrait ?
___ Conversion d'un type de données abstrait en classe
Choisissez en fonction des changements de ___
La coopération est importante

Chapitre 8 : Gérer les dépendances
01.
Comprendre les dépendances
___ Changements et dépendances
Transition de dépendance
Dépendances d'exécution et dépendances de compilation
___ indépendance du contexte
Résolution des dépendances ___
02.
Conception flexible
___ Dépendance et couplage
___ Le savoir crée l'union
___ S'appuyer sur des abstractions
___ dépendances explicites
___ nouveau est nocif
___ Parfois, il est acceptable de créer
Le recours aux classes standard n'est pas nuisible.
___ Développer le contexte
___ actions combinables

◎ Chapitre 9 : Conception flexible
01.
Principe ouvert-fermé
___ Corriger les dépendances à la compilation et modifier les dépendances à l'exécution
L'abstraction est la clé
02.
Création et utilisation séparées
Ajouter ___ USINE
___ Attribuer la responsabilité aux artefacts purs
03.
Injection de dépendances
Les dépendances cachées sont mauvaises
04.
Principe d'inversion de dépendance
___ Abstraction et inversion de dépendance
___ Principe d'inversion des dépendances et paquets
05.
Conseils sur la flexibilité
___ Un design flexible n'est approprié que lorsque la flexibilité est nécessaire.
La coopération et la responsabilité sont importantes.

Chapitre 10 : Héritage et réutilisation du code
01.
Héritage et code en double
Principe DRY
___ Duplication et modification
Éliminer le code dupliqué grâce à l'héritage
___ Fortement couplé Téléphone et NightlyDiscountPhone
02.
Problème de classe de base vulnérable
___ Problème d'héritage d'interface inutile
Problème de comportement anormal de la surcharge de méthode ___
___ Problème lié à la modification simultanée des classes parentes et enfants
03.
Regardez à nouveau votre téléphone.
S'appuyer sur l'abstraction ___
___ Extraire la différence à l'aide d'une méthode
Déplacer le code dupliqué vers la classe parente
L'abstraction est la clé
Choisissez un nom qui révèle vos intentions.
Ajouter une taxe ___
04.
Programmation par différence

Chapitre 11 : Synthèse et conception flexible
01.
Remplacer l'héritage par composition
Problème d'héritage d'interface inutile : java.util.Properties et java.util.Stack
Problème de comportement anormal lors de la surcharge de méthode : InstrumentedHashSet
Problème lié à la modification simultanée des classes parentes et enfants : PersonalPlaylist
02.
Augmentation explosive des combinaisons due à l'hérédité
___ Combinaison de polices de base et de polices supplémentaires
___ Mise en œuvre de politiques de base par héritage
___ Combiner les politiques fiscales avec les politiques de base
___ Combinez la politique de réduction du tarif de base avec la politique de base
___ Tombez dans le piège du code dupliqué
03.
Passage à une relation composite
___ Synthétiser les politiques de base
Appliquer ___ Politique supplémentaire
___ Synthétiser les politiques de base et supplémentaires
___ Ajouter une nouvelle politique
La composition d'objets est une meilleure approche que l'héritage de classes.
04.
mélange
___ Mise en œuvre des politiques de base
Mise en œuvre de politiques supplémentaires avec des caractéristiques ___
___ Mélange de caractéristiques de politique supplémentaire
___ changements cumulables

◎ Chapitre 12 : Polymorphisme
01.
polymorphisme
02.
La dualité de l'héritage
Évaluation de cours utilisant l'héritage
___ Perspective de l'héritage des données
___ Héritage de la perspective comportementale
03.
Conversion ascendante et liaison dynamique
Même message, méthode différente
___ Upcasting
___ liaison dynamique
04.
Exploration dynamique des méthodes et polymorphisme
___ Délégation automatique des messages
___ contexte dynamique
Message incompréhensible
___ soi vs. super
05.
Héritage vs. Délégation
___ Délégation et auto-références
___ langage orienté objet basé sur des prototypes

◎ Chapitre 13 : Sous-classement et sous-typage
01.
Taper
___ type de perspective conceptuelle
___ Types du point de vue d'un langage de programmation
___ Type du point de vue du paradigme orienté objet
02.
Hiérarchie des types
Relation d'inclusion entre les types ___
Programmation orientée objet et hiérarchie des types
03.
Sous-classement et sous-typage
___ Quand dois-je utiliser l'héritage ?
___ est une relation
Compatibilité comportementale
___ Séparer les couches selon les attentes du client
___ Sous-classement et sous-typage
04.
Principe de substitution de Liskov
___ Client et substituabilité
Revisiter la relation ___ est-une
Le principe de substitution de Liskov est le fondement de la conception flexible.
Hiérarchie des types et principe de substitution de Liskov
05.
Conception et sous-typage par contrat
Contrat avec sous-type ___

◎ Chapitre 14 : Coopération constante
01.
Modifier votre système de facturation mobile
Extension de la police d'assurance de base
___ Mise en œuvre d'un système à taux fixe
Mise en œuvre d'une approche basée sur le temps
Mise en œuvre d'une méthode du jour de la semaine
Mise en œuvre de la méthode section par section
02.
Assurer la cohérence de votre design
Logique conditionnelle vs. navigation par objet
___ Revisiter l'encapsulation
03.
Mise en œuvre de politiques de base cohérentes
___ Modifications séparées
___ Encapsuler les modifications
___ Concevoir des modèles de collaboration
Mise en œuvre de modèles de collaboration au niveau d'abstraction ___
___ Mise en œuvre concrète de la coopération
___ S'intégrer au modèle de collaboration
___ Trouvez le modèle

◎ Chapitre 15 : Modèles de conception et cadres de travail
01.
Modèles de conception et réutilisation de la conception
___ modèle logiciel
___ classification des modèles
Modèles et conception axée sur la responsabilité
___ Encapsulation et modèles de conception
___ motif est le point de départ
02.
Cadres de référence et réutilisation du code
Réutilisation du code vs. réutilisation du design
___ Séparer les contrats en contrats parents et contrats enfants
Principe d'inversion de contrôle

◎ En conclusion : Pour aller de l'avant

◎ Annexe A : Conception par contrat
01.
Coopération et contrat
___ effets secondaires explicitement
___ contracter
02.
Conception sur contrat
Prérequis
___ postcondition
___ invariant
03.
Conception et sous-typage par contrat
___ Règles contractuelles
Règle de variabilité
___ Types de fonctions et sous-typage

◎ Annexe B : Implémentation de la hiérarchie des types
Mise en œuvre d'une hiérarchie de types à l'aide de classes ___
Implémentation de la hiérarchie des types à l'aide d'interfaces ___
___ Implémentation de la hiérarchie des types à l'aide de classes abstraites
___ Classes abstraites et interfaces ? Les combiner
Utilisation de la typographie Duck Typing
___ Mixins et hiérarchies de types

◎ Annexe C : Collaboration dynamique, code statique
01.
Modèles dynamiques et statiques
___ actions déterminent le code
Considérez les changements ___
02.
Modèle de domaine et implémentation
À propos du modèle de domaine ___
___ Concevoir des monstres
Modèle de domaine prenant en compte le comportement et le changement
Modèle d'analyse, modèle de conception et modèle de mise en œuvre

◎ Annexe D : Références
___ Références

Ce livre aborde les sujets suivants :

◎ Comment concevoir et mettre en œuvre des programmes orientés objet basés sur les rôles, les responsabilités et la collaboration
◎ Comment optimiser la conception en utilisant la cohésion et le couplage
◎ Diverses techniques de gestion des dépendances qui rendent la conception flexible
◎ Le concept d'héritage pour la hiérarchie des types et la composition pour la réutilisation du code
◎ Divers principes et modèles de conception