La programmation orientée objet modélise-t-elle vraiment le monde réel? [fermé]

Je l'ai souvent vue répéter que la programmation orientée objet est basée sur la modélisation du monde réel, mais l'est-il?

Il me semble que cela n’est vrai pour rien en dehors de la couche affaires. Mes classes d’interface graphique / d’accès aux données ne modélisent rien dans le monde réel. Même dans ma couche métier, j'ai des cours comme des observateurs, des managers, des usines, etc. qui ne sont pas des objets du monde réel. J'essaie de concevoir mes cours pour tirer parti de choses comme l'encapsulation, mais le monde réel est-il encapsulé?

Bien que certains objets que je crée modélisent des objets du monde réel, le code pré-POO ne ferait-il pas de même? Je doute que OO ait été le premier à inclure des concepts tels que Client dans ses bases de code. Mais OO concerne vraiment la manière de modéliser les choses, et cette méthode de modélisation ne me semble pas inspirée par le monde réel.

Alors: la programmation orientée objet modélise-t-elle vraiment le monde réel?

Non pas du tout.

Cependant, c'est une méthodologie qui permet de créer une belle abstraction pour contenir des structures de données complexes avec certaines méthodes agissant sur les structures de données.

Les modèles, de quelque nature qu'ils soient, ne modélisent pas le monde réel, pas tout à fait.

Ils modélisent des portions sélectionnées , celles qui sont pertinentes pour l'application concernée.

Ce dont vous parlez (observateurs, gestionnaires, usines, etc.) est une infrastructure conçue pour vous aider à obtenir l'abstraction correcte et à prendre en charge les fonctions requises telles que la persistance.

Qu’est-ce qu’un modèle, de toute façon:
un modèle est une représentation simplifiée utilisée pour expliquer le fonctionnement d’un système ou d’un événement du monde réel

La programmation orientée objet vous permet -elle de modéliser le monde réel?

Définitivement oui

Il est presque impossible de modéliser le système pour qu'il corresponde exactement au monde réel.

Dois-je toujours modéliser le logiciel exactement d'après le monde réel?

NON

Cela dit, vous pouvez tout modéliser ne signifie pas que vous devez tout modéliser. En fait, l’utilité de la modélisation consiste à présenter une représentation simplifiée. Une simplification suffisante pour exprimer le besoin commercial actuel, et ce qui doit être omis, réside dans un juste équilibre entre l’utilisation réussie de la technique et le fait de ne pas nous perdre ou de ne pas l’utiliser du tout.

Il y a bien sûr des entités qui n'existent pas vraiment, mais nous ne pouvons bien conceptualiser que par la modélisation.

Je pense qu'enseigner qu'il existe une relation entre les noms et les classes provoque le développement de mauvaises habitudes agaçantes qui doivent être écrasées plus tard par un architecte ou un ingénieur en chef impatients.

Ce qu'il faut enseigner, c'est que les classes modélisent des objets abstraits, tout comme votre cerveau. Vous avez dans la tête un concept abstrait de "voiture" qui ne correspond à aucune voiture physique particulière, il est réutilisable, des implémentations spécifiques de voiture peuvent en hériter. Votre cerveau met même des méta-modèles pour vous. Vous avez un modèle mental de ce qu'est la pensée, de ce qu'est un concept.

Si nous apprenions aux gens à identifier les modèles qu’ils génèrent déjà dans votre tête, ils seraient beaucoup mieux préparés à construire de vrais logiciels.

... Le monde est plus riche que ce qui peut être exprimé avec une syntaxe orientée objet.

Considérez quelques concepts courants que les gens utilisent universellement pour comprendre et décrire tous les systèmes - des concepts qui ne correspondent pas au moule de l'objet. Le paradigme "avant / après", ainsi que celui de "cause / effet" et la notion d '"état du système" comptent parmi les exemples les plus frappants. En effet, le processus consistant à «préparer du café», à «assembler un véhicule» ou à «atterrir un mobile sur Mars» ne peut être décomposé en objets simples. Oui, ils sont traités de la sorte dans les langages OO, mais c'est artificiel et contre-intuitif. La séquence de la routine elle-même - ce qui vient avant quoi dans quelles conditions en fonction de quelle causalité - n'a tout simplement pas de représentation significative dans OO , parce que OO n'a pas de concept de séquencement, d'état ou de cause.

Les processus sont extrêmement courants dans le monde réel et dans la programmation. Des mécanismes élaborés ont été mis au point au fil des ans pour gérer les transactions, le flux de travail, l’orchestration, les threads, les protocoles et d’autres concepts intrinsèquement «procéduraux». Ces mécanismes génèrent de la complexité lorsqu'ils tentent de compenser le déficit inhérent invariant dans le temps de la programmation OO. Au lieu de cela, le problème devrait être résolu à la racine en permettant aux constructions spécifiques au processus, telles que "avant / après", "cause / effet" et, éventuellement, "état du système" d'être une partie essentielle du langage ...

source de citation: Victoria Livschitz, la prochaine étape dans la programmation

Oui, OO peut souvent être utilisé pour modéliser des entités du monde réel.

Même dans ma couche métier, j'ai des cours comme des observateurs, des gestionnaires, des usines, etc. qui ne sont pas des objets du monde réel.

Ne confondez pas le développement orienté objet avec les modèles de conception. L'analyse et la conception OO sont un moyen d'approcher la programmation de code maintenable. Couplés à un langage OO, les programmeurs ont le pouvoir de créer du code réutilisable via les piliers de OO: encapsulation, polymorphisme et héritage.

Pour encapsuler une entité, nous pouvons la modéliser d'après son homologue du monde réel. Par exemple, si nous avons une guitare, une classe de guitare encapsule les comportements et les propriétés d'une guitare du monde réel. Nous pouvons en outre abstraire la guitare en tant que, par exemple, IInventoryItempour tirer parti du potentiel de réutilisation du code par polymorphisme et héritage.

D'autre part, nous pourrions constater qu'une usine de guitares pourrait nous aider à maintenir un ensemble de différents types de guitares. Ce n'est pas à cause de OO. Une usine est plutôt un modèle de conception qui a résisté à l'épreuve du temps en tant que moyen éprouvé de créer avec succès un code de maintenance permettant de réaliser de tels objectifs. En d'autres termes, nous, programmeurs, résolvons souvent des problèmes similaires. Nous avons donc trouvé une solution commune pour les résoudre (ne réinventez pas la roue).

Cela ne signifie pas que OO doit modéliser le monde réel, ni que c'est toujours la solution la plus optimale pour le faire. En règle générale, la règle générale «OO modeling the real world» prend tout son sens.

Cela dépend de quel monde réel vous parlez.

Jorge Luis Borges a écrit une histoire intitulée "Tlön, Uqbar, Orbis Tertius", dans laquelle l'un des habitants semble percevoir son monde réel de manière très différente:

[...] les gens de l'imaginaire Tlön [...] soutiennent une forme extrême d'idéalisme berkélien, niant la réalité du monde. Leur monde est compris "non comme une combinaison d'objets dans l'espace, mais comme une série hétérogène d'actes indépendants". Une des langues imaginées de Tlön manque de noms. Ses unités centrales sont des "verbes impersonnels qualifiés par des suffixes monosyllabiques ou des préfixes ayant la force des adverbes". Borges cite un équivalent Tlönic de "La lune se leva au-dessus de l'eau": hlör u fang axaxaxas mlo, signifiant littéralement "haut derrière le onstreaming". [...] Dans une autre langue de Tlön, "l'unité de base n'est pas le verbe, mais l'adjectif monosyllabique", qui, par combinaisons de deux ou plus, forment un nom: "lune" devient "une lumière aérée ronde sombre "ou"

( Copié de l' artice Wikipédia à propos du livre)

Pour moi, le but n'est pas tellement que le monde puisse être perçu différemment que nous, ce qui est un peu un cliché, mais que la perception de la structure de la réalité elle-même dépend de la langue que nous parlons, qu'elle soit naturelle ou en langage de programmation. Les Tlönese pourraient être très satisfaits de Lisp et pourraient considérer Java (AKA, le Royaume des noms ) comme très peu naturelle, alors que la plupart des programmeurs terrans ont tendance à préférer les langages fonctionnels aux objets. J'aime les deux styles, car je pense que c'est principalement une question de perspective. Certains problèmes sont mieux attaqués avec des techniques fonctionnelles, d’autres avec des techniques de programmation orientées objet. Un bon programmeur examine toujours un problème difficile sous différents angles, avant de tenter une solution. Ou, comme Alan Kay l'a dit: Le point de vue vaut 80 points de QI .

Donc, ma réponse à votre question est la suivante: de quel monde réel parlez-vous? Et comment?

Bien que certains objets que je crée modélisent des objets du monde réel, le code pré-POO ne ferait-il pas de même?

Je dirais non. OOP lie la relation entre les choses (propriétés / objets) et ce qu'elles peuvent / peuvent leur faire (méthodes), alors que la programmation procédurale ne le fait pas (sauf, dans une faible mesure, lors de l'utilisation d'un typage strict). Un modèle ne consiste pas uniquement à définir des composants et des processus distincts, il définit également leur association, et la programmation orientée objet est particulièrement efficace dans ce domaine.

Je l'ai souvent vu répéter que la programmation orientée objet est basée sur la modélisation du monde réel, mais l'est-il?

Oui. L'accent est ici basé sur . La programmation orientée objet ne modélise pas le monde réel (si c'est le cas, incidemment) et il n'est pas censé le faire. La programmation orientée objet nous permet de modéliser les problèmes de programmation de la même manière que nous modélisons le monde réel: en tant que système d'entités définies par l'abstraction de leur comportement.

Le code OO ne modélise généralement pas le monde réel - du moins ce n'est pas l'objectif, il vous permet simplement de penser à votre code d'une manière plus naturelle, plus semblable à celle que vous envisagez de la réalité ... c'est ce que la citation tente de dire.

Cela ne modélise pas notre monde, mais cela modélise l'interprétation humaine de notre monde. Les humains séparent naturellement les choses en tant qu'objets. OO est efficace car il permet aux humains de programmer leur façon de penser.

OOP n'est peut-être pas un modèle parfait du monde réel et des objets qu'il contient, mais c'est une méthodologie qui permet de gérer la complexité croissante des logiciels de la vie réelle. Cela permet également de mieux écrire le code, en le décomposant en morceaux liés de manière logique.

Même si les anciennes méthodes orientées vers les procédures produiront certainement aussi des résultats, la POO vous aide à y arriver plus rapidement et avec une relative facilité, même dans le cas de projets volumineux et complexes.

Abstraction et Encapsulation aident à se concentrer sur le cœur du problème tout en masquant toute la tuyauterie qui fait que les choses se passent. Héritage et vous permet d'établir une relation significative et logique entre les différents aspects de votre code. Polymorphisme favorise réutilisation du code et permet de gérer facilement les variations (les « presque même comportement d' un objet existant » catégorie de problèmes qui arrive si souvent) et prolongez le code en étendant la sémantique associée à un objet.

Je pense que la POO est plus une aide éprouvée qui vous permet de gérer efficacement toutes les complexités d'un système de la vie réelle. Ainsi, bien que ce ne soit peut-être pas un modèle très complet du monde réel, il est suffisamment proche et vous aide à accomplir vos tâches, ce qui est tout ce qui compte à la fin.

Je l'ai souvent vu répéter que la programmation orientée objet est basée sur la modélisation du monde réel, mais l'est-il?

Il me semble que cela n’est vrai pour rien en dehors de la couche affaires.

Comme vous l'avez fait remarquer, beaucoup de choses «modélisées» dans un langage POO sont des concepts abstraits comme les files d'attente de messages, les contrôleurs et les piles.

Même dans votre couche métier, vous ne modélisez toujours pas "le monde réel". Supposons que vous avez une classe d'employés. Les employés sont aussi des personnes, qui sont aussi des mammifères, qui sont aussi des animaux, qui sont aussi… (bâillement) Les employés ont des couleurs préférées, ils portent certains vêtements et croient en certaines choses. En bref, il existe dans le monde réel une grande complexité que nous n'essayons même pas de capturer dans la plupart des programmes.

En modélisation, nous nous concentrons uniquement sur les aspects du modèle qui ont un sens pour la tâche à accomplir. Si nous concevons un système de saisie de temps, nous voulons probablement une sorte de classe Employee, mais cette classe n'a pas besoin d'une propriété pour exprimer la couleur préférée de l'employé.

Par conséquent, les modèles ne doivent pas tenter (ou prétendre) de représenter complètement le "monde réel".

Bien que certains objets que je crée modélisent des objets du monde réel, le code pré-POO ne ferait-il pas de même? Je doute que OO ait été le premier à inclure des concepts tels que Client dans ses bases de code.

Vous avez raison. Si vous regardez de gros programmes qui ne sont pas de la POO, ils restent souvent organisés autour de structures de données. Une structure de données et toutes les fonctions manipulées sont définies les unes près des autres, pour des raisons de clarté. (Le projet Subversion en est un bon exemple. Les structures de données et les fonctions sont précédées du nom des modules, ce qui permet d'identifier clairement les structures et les fonctions destinées à être utilisées les unes avec les autres.)

Je ne suis pas un expert en histoire des langages de programmation, mais j'imagine que la POO est née de l'observation fortuite selon laquelle le code était plus clair et plus facile à comprendre lorsqu'il était organisé de cette façon. Les concepteurs de langages ont donc commencé à concevoir des langages où ce type d'organisation plus strictement appliquée.

La plus grande différence entre OOP et non-OOP est que OOP lie le code aux données. Donc plutôt que d’appeler un code comme celui-ci:

verb(noun);

nous faisons cela à la place:

noun->verb();

Bien que cela puisse sembler être une différence grammaticale, la différence est en réalité dans l’esprit. Nous disons aux objets quoi faire, et généralement, nous ne nous soucions pas de l'état ou du fonctionnement interne de l'objet. Pour décrire un objet, il suffit de décrire son interface publique pour pouvoir l'utiliser .

La programmation orientée objet modélise-t-elle vraiment le monde réel?

Pas complètement.

Bien dans le monde réel, nous sommes confrontés à de vrais problèmes. Nous souhaitons résoudre ce problème en utilisant un paradigme qui reproduit le système que nous souhaitons construire et qui devient le modèle.

Par exemple, si le problème était lié à une application de panier d'achat, nous avons différentes entités comme

1. Produit qui est un terme abstrait pouvant avoir plusieurs membres tels que Livres, Gadgets, Voitures, qui peuvent à nouveau être subdivisés.

2. Des critères de taxe tels que (Taxe de vente) dépendent du lieu d'implémentation du logiciel car celui-ci est sujet à modification en fonction des politiques gouvernementales.

3. La taxe est considérée selon que le produit a été importé avec des critères fiscaux.

4. L'utilisateur pourrait avoir un panier avec une liste de produits, etc.

Comme vous pouvez le constater, nous essayons de résoudre les problèmes réels, mais nous les modulons en fonction du paradigme de la programmation orientée objet afin de le rendre aussi proche que possible du système réel.

Je pense que vous lisez trop dans ce qui est censé être une déclaration très prosaïque, historique. De nombreuses idées de programmation OO, de classes, de polymorpisme, de fonctions virtuelles, etc. ont été introduites dans le langage Simula dans les années 1960 (http://en.wikipedia.org/wiki/Simula). Comme son nom l'indique, Simula a été conçu pour être un langage permettant d'écrire des simulations. Donc, historiquement, oui, les idées OO ont été introduites dans le but de modéliser le "monde réel". Qu'ils réussissent plus que d'autres styles est un sujet de débat.

Bien que certains objets que je crée modélisent des objets du monde réel, le code pré-POO ne ferait-il pas de même?

La principale différence entre le code OOP et le code pré-OOP réside dans le fait que l'ancien code modélise une situation réelle en tant que groupe d'entités distinctes qui interagissent les unes avec les autres, chacune avec un "pouvoir" limité sur ce qu'elle peut faire et aussi capable de "réagir" événements externes avec ses propres actions. Ce dernier modélise tout comme un gros bloc de données qui ne fait rien par lui-même, tandis que le calcul représente «des événements» et peut les affecter.

Que cela modélise mieux le monde réel ou non, cela dépend vraiment des facettes du monde que vous modélisez. Une simulation physique, par exemple, dans laquelle vous voulez décrire les effets qu'un feu allumé aurait, par exemple, sur les objets environnants, serait mieux représentée par une approche "traditionnelle", car la lumière et la chaleur sont bien processus définis qui affectent à la fois l'état externe et l'état interne d'autres objets et qui ne varient pas en fonction du comportement de chaque objet particulier, étant uniquement affectés par leurs propriétés.

D'autre part, si vous modélisez différents composants qui interagissent pour produire le comportement souhaité, les traiter comme des agents plutôt que comme des éléments passifs peut permettre de le faire plus facilement sans rien omettre. Si je veux allumer mon téléviseur, j'appuie simplement sur le bouton. Si le cordon d'alimentation est débranché, TV.turnOnje vérifierai pour moi. Donc, il n'y a aucun risque de tourner un rouage et d'oublier de transformer l'autre qui le touche, car le rouage lui-même (s'il est programmé correctement) prendra en charge les interactions secondaires qui découlent de la première.

Mais OO concerne vraiment la manière de modéliser les choses, et cette méthode de modélisation ne me semble pas inspirée par le monde réel.

Je crois que cela a plus à voir avec la façon dont nous percevons le monde que de voir comment le monde l’est réellement. On pourrait dire que tout n’est qu’un groupe d’atomes (ou d’énergie, ou d’ondes, peu importe), mais cela ne nous aide pas à gérer les problèmes auxquels nous sommes confrontés, à comprendre l’environnement qui nous entoure et à prédire les événements futurs ( ou décrivant les passés). Nous créons donc des "modèles mentaux" du monde, et ces modèles mentaux trouvent souvent une meilleure correspondance avec OO que celle des processus data +, qui modélisent sans doute "mieux" le fonctionnement réel du monde réel.

Il est également intéressant de noter que la plupart des gens pensent que la POO est synonyme de "POO classique", où nous créons de manière taxonomique des ensembles et des sous-ensembles de choses et plaçons sans ambiguïté des objets dans un ensemble très spécifique. C'est très utile pour créer de nouveaux types réutilisables , mais pas si génial lorsque l'entité que vous modélisez est à peu près autonome, et même si elle initie des interactions avec d'autres objets, elle est rarement, sinon jamais, la cible d'une interaction. Ou pire, quand il y a peu (peut-être une seule) instance de cette entité, ou que les instances varient énormément dans la composition, le comportement ou les deux.

Cependant, il existe également une "POO prototypique", dans laquelle un objet est décrit en choisissant un objet similaire et en énumérant les aspects où ils diffèrent. Je suggérerais cet essai comme une explication bonne et pas trop technique du processus de réflexion (le post entier est trop gros, même pour les standards de Steve Yegge, alors je pointe vers la section pertinente: P). Encore une fois, cela correspond bien à nos modèles mentaux lorsque nous imaginons des instances inconnues par rapport à un exemple connu, mais pas nécessairement à la façon dont le monde réel "fonctionne" ... (deux vaches sont en réalité des entités complètement distinctes, même si nous les percevons) comme étant "semblables" à bien des égards)

Je pense que "Est" est la partie importante de cette question. Je pense que la programmation orientée objet peut certainement modéliser des "objets" du monde réel, mais c'est de la programmation . Il n'y a pas de méthodologie qui ne peut pas être mal utilisée, donc je ne pense pas qu'il soit juste de dire que "la POO ne modélise pas le monde réel" simplement parce que vous pouvez faire des choses stupides avec Objects. Ce n'est pas plus juste que de dire que les pointeurs ne sont pas sûrs parce que vous pouvez faire des choses stupides avec des pointeurs.

L'article de Wikipedia sur le sujet le résume bien:

La modélisation en mode réel et les relations
OOP peuvent être utilisées pour associer des objets et des processus du monde réel à des homologues numériques. Cependant, tout le monde n'est pas d'accord pour dire que la POO facilite la cartographie directe dans le monde réel (voir la section Critique négative) ou que la cartographie dans le monde réel est même un objectif louable. Bertrand Meyer soutient dans Construction de logiciels orientés objet [21] qu'un programme n'est pas un modèle du monde mais un modèle d'une partie du monde; "La réalité est un cousin enlevé deux fois".

Le problème est que, à moins que votre programme ne soit une simulation d'univers, vous ne vous souciez que de parties du monde réel - d'où le "modèle". C’est à cela que servent les modèles, ils vous fournissent la structure et les fonctionnalités que vous devez afficher.

Dans le monde réel, nous avons des objets (objets) et les objets peuvent effectuer des actions (méthodes). Nous pouvons quantifier les aspects des choses (propriétés). OOP a tout le potentiel pour modéliser des choses du monde réel lorsqu'il est utilisé de manière réductionniste; chaque chose complexe a des sous-classes plus petites ou plus spécifiques et toutes ces choses ont des interactions naturelles via des méthodes.

La POO est une méthode d'abstraction. La pratique consiste donc à savoir si la POO modélise logiquement des objets dans le monde réel. Il est donc moins important de ne pas modéliser toutes les choses possibles que tout puisse jamais faire . Si vous devez faire tout ce qui est possible, vous n'êtes pas vraiment un modèle .

Afin de penser à l'orientation objet dans son contexte, passons d'un niveau d'abstraction à un autre et parlons de la programmation en général, d'accord?

Que vous adoptiez des approches orientées objet ou fonctionnelles, votre programme doit faire quelque chose, n'est-ce pas? Le but du programme est d’exposer certains comportements en fonction d’ un certain ensemble de stimuli. Les programmes existent donc parce qu’ils font quelque chose. Le mot clé ici est le comportement .

En plus de considérer les comportements qu'un programme doit adopter, votre programme doit généralement présenter certaines qualités. Par exemple, il n’est pas suffisant pour un programme de contrôle cardiaque d’avoir les comportements qui lui sont demandés - il doit également être suffisamment performant assez rapidement pour pouvoir fonctionner en temps quasi réel. Les autres qualités qu'un programme peut avoir besoin de présenter sont les suivantes: sécurité, flexibilité, modularité, extensibilité, lisibilité, etc. Nous appelons ces attributs de qualité d'architecture . Nous pouvons donc dire que notre programme doit atteindre certains objectifs comportementaux (fonctionnels) et présenter certaines qualités (non fonctionnel).

Jusqu'ici, rien de tout cela n'a parlé de OO, n'est-ce pas? Faisons cela maintenant.

Une fois que l'ingénieur a compris les exigences (comportemental, AQAs, contraintes, etc.), la question qui se pose est de savoir comment organiser mon code de sorte qu'il fasse tout ce qu'il doit faire tout en présentant les qualités nécessaires pour être un programme utile. La programmation orientée objet est une stratégie permettant d’organiser les fonctionnalités de votre programme en modules cohérents d’objets coopérants. La programmation fonctionnelle n'est qu'une autre stratégie pour organiser les fonctionnalités de votre programme, et cela d'une manière différente. Les deux stratégies ont leurs forces et leurs faiblesses.

Nous avons assisté à une recrudescence récente des concepts fonctionnels, parmi lesquels des atouts très convaincants pour un traitement extrêmement distribué.

Mais revenons à OO, vous pouvez voir maintenant que cela ne modélise pas nécessairement le "monde réel"; il organise le comportement de votre programme de manière à ce qu'il présente les qualités nécessaires pour répondre à un grand nombre d'objectifs commerciaux. Des techniques telles que TDD, DDD et BDD sont les moyens par lesquels nous découvrons la meilleure façon d’organiser nos objets. Des ouvrages tels que Principes, modèles et pratiques , Logiciels grandissants orientés objet guidés par des tests , Spécification par exemple et Conception centrée sur le domaine exposent la théorie et la pratique de l'orientation objet en mettant l'accent sur la conception pilotée par le comportement.

Lorsque vous lisez sur des sujets tels que "observateurs, gestionnaires, usines, etc.", vous appliquez des modèles OO qui aident votre programme à présenter certaines qualités pouvant être nécessaires à son utilité. Ce sont des "recettes éprouvées" qui "ont tendance à fonctionner", étant donné que vos besoins correspondent au problème résolu par le modèle.

J'espère que cela vous aidera à comprendre ce qu'est OO sans paraître trop biaisé entre paradigmes OO et fonctionnels.

OOP crée un beau modèle du point de vue de la programmation, il ne reflète pas le monde réel.

Cependant, il existe de bien meilleures approximations du monde réel, connues sous le terme de langages spécifiques de domaine ( DSL ). Par exemple, Boo vous permet d'écrire du code lisible par l'homme dans un anglais presque simple (exemple tiré de l' article ).

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

Un autre exemple serait les cadres de tests d'acceptation utilisateur automatisés basés sur le langage Gherkin .

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

C'est à vous, enfin. Mais la programmation orientée objet est un moyen précis de le faire par rapport à d'autres méthodologies telles que la programmation structurée ou orientée procédure. Le tact procédural pourrait peut-être résoudre vos problèmes, mais le fait de suivre la POO peut vous rendre la vie plus facile.