Conception Logicielle

Un article de MonWiki.

En construction...

Voir aussi : GRASP, C++

Sommaire 1 Principes 1.1 Architecture 1.2 Object Oriented Design 1.3 Refactoring 1.3.1 Code Smells 1.4 Lexical Reproduction 1.5 Getting Things Done 2 Jeux Vidéo 2.1 Le framework 2.2 L'éditeur de niveaux 2.3 Les scripts 3 Références

Principes

Architecture

• Architecture should be base on the problem domain, and not on the problem being solved (Cf. C++ FAQs, FAQ 4.03).
• The only software that never changes is software that no one uses.
• Understanding the problem domain is the key to planning for change (FAQ 4.07).
• But don't focus on supporting change to the point that the project won't finish on time (FAQ 4.13).
• Don't try to create a software that's like a rubber band - flexible in every direction. Instead, identify a few specific places where the system needs be flexible and do a good job with those places (FAQ 4.14)
• Build a reuse culture (FAQ 4.15).

Object Oriented Design

• To a programmer, an object is a region of storage with associated semantics. To a designer, an object is any identifiable component in the problem domain (FAQ 5.06).
• Move complexity from the many to the few (FAQ 5.07).
• When creating a class, the first step is to write down its roles and responsabilities (FAQ 5.07).
• Polymorphism and dynamic binding allow old code to call new code in a substitutable fashion (FAQ 5.11).
• Non-member non-friend functions improve data encapsulation: it can't access to an object's private data. You can keep them in the same namespace but organize them in different header files (cf. STL) (Effective C++, Third Edition - Item 23).

Refactoring

"Be suspicious if less than 10 percent of the previous code is discarded each time."

• Do not refactor a program and add functionnality to it at the same time.
• Make sure you have good tests in place before you begin refactoring.
• Take short, deliberate steps.

See also: What Is Refactoring, Refactoring, Martin Fowler's Refactoring Home Page.

Code Smells

Martin Fowler & Kent Beck's code smell list:

• Duplicate Code
• Long Method
• Large Class
• Long Parameter List
• Divergent Change
• Shotgun Surgery
• Feature Envy
• Data Clumps
• Primitive Obsession
• Switch Statements
• Parallel Inheritance Hierarchies
• Lazy Class
• Speculative Generality
• Temporary Field
• Message Chains
• Middle Man
• Inappropriate Intimacy
• Alternative Classes with Different Interfaces
• Incomplete Library Class
• Data Class
• Refused Bequest
• Comments

Lexical Reproduction

I have an ongoing thesis at the moment which I'm exploring in the programming language literature, which is that programming language features do well (all other things being equal) when they eliminate either distant or dynamic state and replace it with either close or lexical state. the underlying point being that we may favour language features that facilitate copying and modifying small bits of code -- fragments which work in their new context -- as a fundamental programming activity.

-Graydon Hoare, author of Monotone, now working for Mozilla[1].

Getting Things Done

Forster explains why some of the other famous methods don't work. Remember that one about "process each piece of paper only once"? Who can do that? Certainly not me. I don't even know where to put the darn thing. Forster describes why these approaches don't work for us and then helps put them in context.

The idea I like best: when you've got a task before you that is daunting, make a checklist of things that make up that task. First item too daunting? Break it down some more. Kind of reminds me of writing User Stories. Sooner or later you reach one where you say "oh, I could do that", and you're off.

-- Ron Jeffries [2]

Jeux Vidéo

Le framework

Commun à plusieurs jeux, il doit permettre de réaliser facilement les tâches indispensables.

• Charger une scène.
• À chaque frame :
  • interpréter des commandes,
  • animer la scène,
  • dessiner la scène.
• Afficher des images.
• Afficher du texte.
• Jouer des sons.
• Collecter et afficher des mesures permettant d'analyser les données internes du jeu (aide au développement).

L'éditeur de niveaux

C'est la base du jeu. Commencer par l'éditeur, et tout réaliser à partir de lui.

Les scripts

Tous les réglages du jeu seront fait à partir de scripts.

Références

• CLINE (M.) LOMOW (G.) GIROU (M.) - C++ FAQs, 2^e éd. Addison-Wesley, États-Unis, 1999, 587 p.
• FOWLER (Martin) - Refactoring - Improving the Design of Existing Code, éd. Addison-Wesley, coll. "Object Technology Series", États-Unis, 1999, 431 p.
• FOWLER (Martin) - UML Distilled, 2^e éd. Addison-Wesley, coll. "Object Technology Series", États-Unis, 2000, 185 p.
• MEYERS (Scott) - Effective C++, 3^e éd. Addison-Wesley, coll. "Professional Computing Series", États-Unis, 2005, 297 p.