DDD (Domain-Driven Design)

SOLID

Principe de conception

Architecture

Références

L'actualité

Parcours & Expérience





Librairie

L'information

Principe de conception > AOP (Aspect Oriented Programming)

La programmation orientée aspect, ou POA est un paradigme de programmation qui permet de traiter séparément les préoccupations transversales (en anglais, cross-cutting concerns), qui relèvent souvent de la technique, des préoccupations métier, qui constituent le coeur d'une application.

Un exemple classique d'utilisation est la journalisation, mais certains principes architecturaux ou modèles de conception peuvent être implémentés à l'aide de ce paradigme de programmation, comme l'inversion de contrôle.

La programmation orientée aspect est bien une technique transversale (paradigme) et n'est pas liée à un langage de programmation en particulier mais peut être mise en oeuvre aussi bien avec un langage orienté objet comme Python qu'avec un langage procédural comme le C, le seul pré-requis étant l'existence d'un tisseur d'aspect pour le langage cible.

  

Principe de conception > OOP (Object-Oriented Programming)

La programmation orientée objet (POO), ou programmation par objet, est un paradigme de programmation informatique élaboré par les Norvégiens Ole-Johan Dahl et Kristen Nygaard au début des années 1960 et poursuivi par les travaux de l'Américain Alan Kay dans les années 1970.

Il consiste en la définition et l'interaction de briques logicielles appelées objets ; un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une personne ou encore une page d'un livre. Il possède une structure interne et un comportement, et il sait interagir avec ses pairs.

Il s'agit donc de représenter ces objets et leurs relations ; l'interaction entre les objets via leurs relations permet de concevoir et réaliser les fonctionnalités attendues, de mieux résoudre le ou les problèmes.

Dès lors, l'étape de modélisation revêt une importance majeure et nécessaire pour la POO. C'est elle qui permet de transcrire les éléments du réel sous forme virtuelle.

  

Principe de conception > SoC (Separation of Concerns)

La séparation des préoccupations, traduction du concept d'informatique théorique issu de l'anglais separation of concerns (SoC) est un principe de conception visant à séparer un programme informatique en parties, afin que chacune d'entre elle isole un problème précis de la problématique générale.

Une préoccupation (de l'anglais concern) est un ensemble d'information qui affecte le code d'un programme informatique.
Le concept de préoccupation peut recouvrir des aspects informatiques très variés.

Un programme qui intègre les principes de séparation des préoccupations est appelé un programme modulaire, car il sépare son code en différent modules. La modularité, et donc la séparation des préoccupations, est obtenue en encapsulant des informations dans une section de code qui a une interface bien définie. L'encapsulation du code dans des modules amène un masquage de l'information. Les conceptions en couches dans les systèmes d'information constituent un autre mode de réalisation de la séparation des préoccupations (par exemple, couche de présentation, couche logique métier, couche d'accès aux données, couche de persistance.)

L'application du principe de séparation des préoccupations simplifie le développement et la maintenance des programmes informatiques. Quand les préoccupations sont strictement séparées, les différentes parties du code peuvent être réutilisées, étendues ou modifiées indépendamment des autres. Cela permet ainsi d'intervenir sur une partie du code sans avoir de connaissance particulière sur l'ensemble des autres parties

  

Principe de conception > BLL (Business Logic Layer)

In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.

Business logic:
  • Prescribes how business objects interact with one another
  • Enforces the routes and the methods by which business objects are accessed and updated
Business rules:
  • Model real-life business objects (such as accounts, loans, itineraries, and inventories)
Business logic comprises:
  • Workflows that are the ordered tasks of passing documents or data from one participant (a person or a software system) to another.
  

Principe de conception > DAL (Data Access Layer)

A data access layer (DAL) in computer software, is a layer of a computer program which provides simplified access to data stored in persistent storage of some kind, such as an entity-relational database. This acronym is prevalently used in Microsoft environments.

For example, the DAL might return a reference to an object (in terms of object-oriented programming) complete with its attributes instead of a row of fields from a database table. This allows the client (or user) modules to be created with a higher level of abstraction. This kind of model could be implemented by creating a class of data access methods that directly reference a corresponding set of database stored procedures. Another implementation could potentially retrieve or write records to or from a file system. The DAL hides this complexity of the underlying data store from the external world.

For example, instead of using commands such as insert, delete, and update to access a specific table in a database, a class and a few stored procedures could be created in the database. The procedures would be called from a method inside the class, which would return an object containing the requested values. Or, the insert, delete and update commands could be executed within simple functions like registeruser or loginuser stored within the data access layer.
Also, business logic methods from an application can be mapped to the Data Access Layer.
  
So, for example, instead of making a query into a database to fetch all users from several tables the application can call a single method from a DAL which abstracts those database calls.

Applications using a data access layer can be either database server dependent or independent. If the data access layer supports multiple database types, the application becomes able to use whatever databases the DAL can talk to In either circumstance, having a data access layer provides a centralized location for all calls into the database, and thus makes it easier to port the application to other database systems (assuming that 100% of the database interaction is done in the DAL for a given application).

Object-Relational Mapping tools provide data layers in this fashion, following the active record model. The ORM/active-record model is popular with web frameworks.

Principe de conception > FL (Facade Layer)

En génie logiciel, le patron de conception (ou design pattern) façade a pour but de cacher une conception et une interface complexe difficile à comprendre (cette complexité étant apparue "naturellement" avec l'évolution du sous-système en question).

La façade permet de simplifier cette complexité en fournissant une interface simple du sous-système. Habituellement, la façade est réalisée en réduisant les fonctionnalités de ce dernier, mais en fournissant toutes les fonctions nécessaires à la plupart des utilisateurs.

La façade encapsule la complexité des interactions entre les objets métier participant à un workflow.
  • Une façade peut être utilisée pour :
  • rendre une bibliothèque plus facile à utiliser, comprendre et tester;
  • rendre une bibliothèque plus lisible;
  • réduire les dépendances entre les clients de la bibliothèque et le fonctionnement interne de celle-ci, ainsi on gagne en flexibilité pour les évolutions futures du système;
  • assainir une API que l'on ne peut pas modifier si celle-ci est mal conçue, ou mieux découper ses fonctionnalités si celle-ci n'est pas assez claire.
  
Un adaptateur est utilisé lorsque l'on doit respecter une interface bien définie. La façade est utilisée pour simplifier l'utilisation de l'API.