🧱 Architecture applicative

Cette partie est largement inspirée des concepts et exemples présentés dans le livre :

Clean Architecture, A Craftsman’s Guide to Software Structure and Design. Robert C. Martin 2017.

Architecture applicative : une définition

L’architecture applicative désigne l’organisation structurelle d’une application logicielle, englobant ses composants, leurs interactions et les principes sous-jacents à leur conception. Elle établit une feuille de route qui guide le développement, le déploiement, et l’évolution de l’application en fonction des besoins techniques, fonctionnels et stratégiques.

En d’autres termes c’est une organisation proposée des sources de nos programmes qui permet ensuite une bonne évolution de celui ci.

Mais pour quel but?

The goal of software architecture is to minimize the human resources required to build and maintain the required system.

Priorisation, matrice d’Eisenhower

La réalisation de travaux et de programmes est consommatrice de temps et de ressources humaines, il est donc important d’identifier les tâches a faire et les ordonner selon leur importance et leur criticité.

Urgence et Importance	Action a faire
Urgent et Important	À faire rapidement.
Urgent et non important	Déléguer si possible : Ces tâches sont urgentes mais ont un impact moindre. Exemple : répondre à certains e-mails ou résoudre des problèmes mineurs.
Non Urgent mais important	À planifier : Ces tâches doivent être intégrées dans votre emploi du temps pour garantir leur réalisation sans pression.
Non Urgent et non important	Éliminer ou minimiser : Ces activités n’apportent pas de valeur ajoutée et peuvent être une perte de temps. Exemple : les distractions inutiles ou les tâches peu significatives.

Pour utiliser cette matrices:

Listez toutes vos tâches.
Classez-les dans l’un des quatre quadrants.

Vous pouvez ensuite affiner la difficulté des différentes tâches a effectuer pour vous permettre d’identifier des priorités a la réalisation de ces tâches. Puis enfin organiser vos équipes pour réaliser ces tâches dans des délais raisonnables.

Dans l’évolution des méthodes de travail, l’émergence des méthodes agiles propose une organisation du travail autour de cette planification au plus proche du besoin.

Pour aller plus loin : https://fr.wikipedia.org/wiki/M%C3%A9thode_agile

Modules et fonctions

Un module en Python est un fichier contenant du code Python. Il peut inclure des fonctions, des classes, des variables, et même des instructions exécutables. Un module permet de regrouper des fonctionnalités spécifiques dans un fichier distinct afin de rendre le code plus réutilisable, organisé et lisible.

En Python, les modules sont simplement des fichiers avec l’extension .py. Vous pouvez créer votre propre module ou utiliser des modules standard fournis avec Python. Pour utiliser un module, vous devez l’importer dans votre programme avec la commande import.

Voir aussi: https://peps.python.org/pep-0002/

Les fonctions permettent de regrouper des instructions pour accomplir une tâche spécifique. Elles favorisent la réutilisabilité et l’organisation du code.

def battre_oeufs():
    """Simule le fait de battre les œufs."""
    print("Battre les œufs jusqu'à ce qu'ils soient bien mousseux.")

def faire_fondre_beurre():
    """Simule le fait de faire fondre le beurre."""
    print("Faire fondre le beurre dans une casserole.")

def faire_fondre_chocolat():
    """Simule le fait de faire fondre le chocolat."""
    print("Faire fondre le chocolat au bain-marie.")

def preparer_mousse_au_chocolat():
    """Prépare la mousse au chocolat en appelant les autres fonctions dans l'ordre."""
    print("Préparation de la mousse au chocolat :")
    battre_oeufs()
    faire_fondre_beurre()
    faire_fondre_chocolat()
    print("Mélanger tous les ingrédients pour former une mousse délicieuse!")

# Appel de la fonction principale pour préparer la mousse au chocolat
preparer_mousse_au_chocolat()

Bilan : Les modules et fonctions permettent ainsi de créer des programmes bien structurés, organisés autour de blocs logiques qui favorisent la réutilisation et la compréhension du code.

Programmation orientée objet : principes de l’objet

La programmation orientée objet (POO) repose sur plusieurs principes fondamentaux, parmi lesquels : polymorphisme, encapsulation et héritage. Ces concepts permettent de structurer le code de manière modulaire, réutilisable et extensible.

1. Polymorphisme

Le polymorphisme permet à une même méthode ou fonction d’avoir des comportements différents selon le contexte ou le type de données.

Exemple concret : Système de paiement

Imaginons un système de paiement qui accepte plusieurs méthodes de paiement (carte bancaire, PayPal, Bitcoin). Chaque méthode a sa propre logique, mais toutes doivent implémenter une méthode pay().

class PaymentMethod:
    def pay(self, amount):
        pass

class CreditCard(PaymentMethod):
    def pay(self, amount):
        print(f"Payment of {amount} made using Credit Card.")

class PayPal(PaymentMethod):
    def pay(self, amount):
        print(f"Payment of {amount} made using PayPal.")

class Bitcoin(PaymentMethod):
    def pay(self, amount):
        print(f"Payment of {amount} made using Bitcoin.")

# Polymorphisme : utilisation de différentes méthodes de paiement
def process_payment(payment_method, amount):
    payment_method.pay(amount)

# Utilisation
credit_card = CreditCard()
paypal = PayPal()
bitcoin = Bitcoin()

process_payment(credit_card, 100)  # Payment of 100 made using Credit Card.
process_payment(paypal, 200)       # Payment of 200 made using PayPal.
process_payment(bitcoin, 300)      # Payment of 300 made using Bitcoin.

2. Encapsulation

L’encapsulation consiste à restreindre l’accès direct aux données internes d’une classe et à les protéger contre les modifications non contrôlées. Cela est réalisé en définissant des attributs privés ou protégés et en utilisant des méthodes d’accès (getters et setters).

Exemple ici avec la gestion des paiements dans un SI bancaire :

class BankAccount:
    def __init__(self, owner, balance, credit_limit):
        self.owner = owner
        self.__balance = balance  # Attribut privé
        self.__credit_limit = credit_limit  # Attribut privé

    # Getter pour accéder au solde
    def get_balance(self):
        return self.__balance

    # Méthode pour savoir si l'utilisateur peut payer une certaine somme
    def can_pay(self, amount):
        return amount <= self.__balance + self.__credit_limit

    # Dépôt d'argent
    def deposit(self, amount):
        if amount > 0:
            self.__balance += amount
        else:
            raise ValueError("Le montant doit être positif.")

    # Retrait d'argent (avec vérification de la possibilité de paiement)
    def withdraw(self, amount):
        if amount <= self.__balance:
            self.__balance -= amount
        elif amount <= self.__balance + self.__credit_limit:
            # Utilisation du crédit autorisé si le solde est insuffisant
            self.__credit_limit -= (amount - self.__balance)
            self.__balance = 0
        else:
            raise ValueError("Solde insuffisant et limite de crédit atteinte.")

# Utilisation
account = BankAccount("Alice", 1000, 500)  # Alice a un solde de 1000 et une limite de crédit de 500

# Vérifier si Alice peut payer
print(account.can_pay(1200))  # True, car 1000 (solde) + 500 (crédit) = 1500, suffisant pour 1200
print(account.can_pay(1700))  # False, car 1000 + 500 = 1500, insuffisant pour 1700

# Retrait
account.withdraw(1200)  # Utilisation du crédit de 200, il reste 100 dans le solde
print(account.can_pay(100))  # True, car 0 (solde) + 500 (crédit) suffisant pour 100

On remarque qu’on a pas besoin de connaître le montant du compte en banque d’alice pour réaliser l’opération, mais que cela est fait de manière intrinsèque a l’opération de consommation et de “can_pay”.

3. Héritage

L’héritage permet de créer de nouvelles classes (sous-classes) en réutilisant le code d’une classe existante (classe parente). Cela favorise la réutilisabilité et l’organisation du code. En Python, une sous-classe hérite de toutes les méthodes et attributs de la classe parente, mais peut aussi redéfinir des comportements spécifiques.

Exemple avec une classe d’un site de reservation proposant plusieurs services

# Classe parente : Reservation
class Reservation:
    def __init__(self, name, date, price):
        self.name = name  # Nom de la personne qui réserve
        self.date = date  # Date de la réservation
        self.price = price  # Prix de la réservation

    def display_info(self):
        print(f"Réservation pour {self.name} à la date du {self.date}. Prix: {self.price}€")

    def confirm(self):
        print(f"La réservation pour {self.name} est confirmée.")

# Classe enfant : HotelReservation (hérite de Reservation)
class HotelReservation(Reservation):
    def __init__(self, name, date, price, num_nights):
        super().__init__(name, date, price)  # Appel au constructeur de la classe parente
        self.num_nights = num_nights  # Nombre de nuits réservées

    def display_info(self):
        super().display_info()  # Appel de la méthode de la classe parente
        print(f"Nombre de nuits: {self.num_nights}")

    def confirm(self):
        super().confirm()  # Appel de la méthode de la classe parente
        print(f"Réservation de l'hôtel pour {self.num_nights} nuit(s) confirmée.")

# Classe enfant : FlightReservation (hérite de Reservation)
class FlightReservation(Reservation):
    def __init__(self, name, date, price, flight_number):
        super().__init__(name, date, price)  # Appel au constructeur de la classe parente
        self.flight_number = flight_number  # Numéro de vol

    def display_info(self):
        super().display_info()  # Appel de la méthode de la classe parente
        print(f"Numéro de vol: {self.flight_number}")

    def confirm(self):
        super().confirm()  # Appel de la méthode de la classe parente
        print(f"Réservation du vol {self.flight_number} confirmée.")

# Utilisation des classes

# Création d'une réservation d'hôtel
hotel_reservation = HotelReservation("Alice", "2023-12-25", 200, 3)
hotel_reservation.display_info()
hotel_reservation.confirm()

# Création d'une réservation de vol
flight_reservation = FlightReservation("Bob", "2023-12-25", 150, "AF1234")
flight_reservation.display_info()
flight_reservation.confirm()

Programmation orientée objet : Principes SOLID

1. SRP : Principe de Responsabilité Unique (Single Responsibility Principle)

Un module logiciel (classe, fonction, etc.) ne doit avoir qu’une seule raison de changer.

# Mauvaise pratique : une seule classe gère plusieurs responsabilités.
class Order:
    def calculate_total(self):
        pass  # Calcul du total
    def print_order(self):
        pass  # Imprime la commande
    def save_to_db(self):
        pass  # Sauvegarde dans la base de données

# Bonne pratique : chaque classe gère une seule responsabilité.
class Order:
    def calculate_total(self):
        pass

class OrderPrinter:
    def print_order(self, order):
        pass

class OrderRepository:
    def save_to_db(self, order):
        pass

Cela implique donc qu’il faut séparer fonctionnellement les implémentations entre des couches bien distinctes => Vues, Business_object, …

2. OCP : Principe Ouvert-Fermé (Open-Closed Principle)

Les modules logiciels doivent être ouverts à l’extension, mais fermés à la modification.

# Mauvaise pratique : modification du code existant pour ajouter un comportement.
class Discount:
    def apply_discount(self, price, discount_type):
        if discount_type == "percentage":
            return price * 0.9
        elif discount_type == "fixed":
            return price - 10

# Bonne pratique : extension via des classes dérivées.
from abc import ABC, abstractmethod

class Discount(ABC):
    @abstractmethod
    def apply_discount(self, price):
        pass

class PercentageDiscount(Discount):
    def apply_discount(self, price):
        return price * 0.9

class FixedDiscount(Discount):
    def apply_discount(self, price):
        return price - 10

Cela vous permet de définir autant de versions différentes par extensions plutôt que de créer des chaines de if.

3. LSP : Principe de Substitution de Liskov (Liskov Substitution Principle)

Les sous-types doivent être substituables à leurs types parents.
=> Les enfants doivent respecter le contrat d’interface des parents.

# Mauvaise pratique : la classe dérivée casse le contrat de la classe parent.
class Bird:
    def fly(self):
        pass

class Penguin(Bird):
    def fly(self):
        raise Exception("Les pingouins ne volent pas!")

# Bonne pratique : refactorisation pour respecter le contrat.
from abc import ABC, abstractmethod

class Bird(ABC):
    @abstractmethod
    def move(self):
        pass

class FlyingBird(Bird):
    def move(self):
        print("Je vole!")

class NonFlyingBird(Bird):
    def move(self):
        print("Je marche!")

4. ISP : Principe de Ségrégation des Interfaces (Interface Segregation Principle)

Un client ne doit pas être forcé de dépendre d’interfaces qu’il n’utilise pas.

Ce principe prône la conception d’interfaces spécifiques à un usage précis, évitant les dépendances inutiles.

Il faut donc séparer lorsqu’il y a des dépendances non pertinentes pour définir un objet en plusieurs sous dépendances.

# Mauvaise pratique : une interface trop large.
class Animal:
    def eat(self):
        pass
    def fly(self):
        pass
    def swim(self):
        pass

class Dog(Animal):
    def eat(self):
        pass
    def fly(self):  # Non pertinent pour un chien.
        raise NotImplementedError()
    def swim(self):
        pass

# Bonne pratique : des interfaces spécifiques.
from abc import ABC, abstractmethod

class Eater(ABC):
    @abstractmethod
    def eat(self):
        pass

class Swimmer(ABC):
    @abstractmethod
    def swim(self):
        pass

class Dog(Eater, Swimmer):
    def eat(self):
        print("Je mange!")
    def swim(self):
        print("Je nage!")

5. DIP : Principe d’Inversion des Dépendances (Dependency Inversion Principle)

Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau.

Les détails doivent dépendre des abstractions, et non l’inverse. Cela permet une séparation claire entre la logique métier et les détails d’implémentation.

# Mauvaise pratique : dépendance directe sur une implémentation.
class Database:
    def connect(self):
        print("Connexion à la base de données...")

class UserRepository:
    def __init__(self):
        self.db = Database()
    def get_user(self, user_id):
        self.db.connect()
        print(f"Récupération de l'utilisateur {user_id}")

# Bonne pratique : dépendance sur une abstraction.
from abc import ABC, abstractmethod

class Database(ABC):
    @abstractmethod
    def connect(self):
        pass

class MySQLDatabase(Database):
    def connect(self):
        print("Connexion à MySQL...")

class UserRepository:
    def __init__(self, db: Database):
        self.db = db
    def get_user(self, user_id):
        self.db.connect()
        print(f"Récupération de l'utilisateur {user_id}")

# Utilisation
db = MySQLDatabase()
repo = UserRepository(db)
repo.get_user(1)

Il faut ici noter qu’on injecte des interfaces plutôt que des implémentations et donc cela permet de changer l’implémentation sans avoir a toucher a la classe fille

Importance des Principes SOLID

Ces principes permettent :

Une meilleure maintenabilité : le code est plus facile à comprendre, tester et modifier.
Une meilleure évolutivité : les modifications ou extensions du logiciel n’affectent pas ses parties stables.

Il faudra donc isoler les couches applicatives indépendantes, en ne faisant pas de calculs dans les parties d’affichage, en ne partageant pas d’accès aux bases de données avec les calculs mais bien en isolant les différents modules applicatifs dans le code.

Architecture d’une application multi couches

L’architecture multi-couches permet de séparer les différentes responsabilités d’une application en plusieurs couches. On parle aussi d’architecture n tiers. Dans le modèle classique client-serveur, nous avons trois couches principales :

Couche Client (ou présentation) : Interagit avec l’utilisateur, collecte ses données, et affiche les résultats.
Couche Serveur (ou logique métier) : Traite les données envoyées par le client, applique la logique métier, et communique avec la base de données.
Couche Base de Données (ou stockage des données) : Stocke et gère les données de l’application, et répond aux requêtes envoyées par le serveur.

Chaque couche est responsable d’une partie spécifique de l’application, ce qui facilite la maintenabilité, la scalabilité, et la flexibilité du système.

Lors de la réalisation de vos projets, il vous sera demandé d’effectuer un diagramme uml de séquence de vos systèmes pour des fonctionnalités. Cela permettra de mettre en exergue les interactions au sein de votre système.

Modules et couches : Organisation du code

Cette partie vous présente des propositions d’organisation du code en modules cohérents. Il faudra que votre code puisse être accessible par un néophyte n’ayant pas travaillé sur le projet.

Python - fastapi/flask

Un dossier pour l’application : app
Un sous dossier de app pour chaque couche applicative : router/controller dao business_object …

/app
/app/main.py #(ou autre mais point d'entrée)
/app/requirements.txt #(ou poetry)
/app/README.md #(documentation de l'app avec comment la lancer)
/app/business_object/ #(modèle de données)
/app/dao/ #(accès au données)
/app/controller/ #(ou controller c'est selon)
/app/service/ #(classes et méthodes de service)

Python - django

/app
/app/manage.py
/app/README.md
/app/config/ # application principale (exemple mysite)
/app/config/settings.py
/app/config/urls.py
/app/config/...
/app/requirements.txt
/app/.env/
/app/apps/monappli/ # django gère sur un même serveur plusieurs applis
/app/apps/monappli/models.py # Modèles de données (ORM)
/app/apps/monappli/dao.py # Accès aux données (Data Access Layer)
/app/apps/monappli/services.py # Logique métier
/app/apps/monappli/controllers.py   # Gestion des requêtes HTTP
/app/apps/monappli/urls.py          # Routing de l’application
/app/apps/monappli/views.py         # Vues Django classiques
/app/static/                  # Fichiers statiques (CSS, JS, images)
/app/static/css/
/app/static/js/
/app/static/images/

IHM (voir cours 4-5)

Suivre l’architecture proposée par vite pour les application React :

site/
site/package.json
site/package-lock.json
site/src/main.jsx # composant démarrant l'application
site/src/App.jsx # Composant principal de l'application.  
site/src/assets/ # Fichiers statiques comme les styles globaux, images, polices, etc.  
site/src/components/ # Composants UI réutilisables.  
site/src/pages/ #Pages principales de l'application.  
site/src/services/ # Fonctions liées aux appels API et logique métier. api, web, .. convient.
site/src/utils/ # Fonctions utilitaires globales.  
site/public/ # Contient les fichiers accessibles directement dans le navigateur (ex: `favicon.ico`).

Site statique simple : séparer html, css, js et documentation propre au site

/mon-site
/mon-site/index.html # (page principale) 
/mon-site/about.html # (autres pages du site)
/mon-site/assets/ # (ressources) 
/mon-site/assets/css/ # (fichiers CSS)
/mon-site/assets/css/styles.css 
/mon-site/assets/js/ # (scripts JavaScript) 
/mon-site/assets/images/ # (images et icônes)
/mon-site/README.md # (documentation du sous projet site)
/mon-site/package.json # (si utilisation de npm)