Discussion :

[AlainTech]

Bonjour,

Dans le cours de Philippe Lasserre, je lis ces 2 lignes:

P. 975

On évitera les modules standards qui ne sont pas dans l'esprit 'Objet'.

P. 986

Quand on programme avec une approche Objet, on crée des classes, on n'utilise pas de modules standard ni de Sub et de Fonction.

Comme je suis dans ma quête du "travailler de la manière la plus propre possible", je me demande comment procéder pour écrire mon programme.

Si j'ai bien compris l'utilité des classes pour tout ce qui est objet (avec ses méthodes et propriétés) je vois mal comment ça se passe pour l'écriture de petites routines ou fonctions.

A moins que j'aie mal regardé, il me semble que dans le cours, cette partie ne soit pas approfondie.

Avez-vous des exemples ou des endroits où je pourrais en trouver?

[AlainTech]

Bonjour,

Près d'un an après...

Personne pour me répondre?

[Sankasssss]

(Re) Bonsoir Alain,

Lors de mon apprentissage en Java, il n'y avait pas de module et pour arriver à faire la même chose il fallait passer par des classes Shared ce qui est aussi le cas en C# si je en me trompe pas.

En faisant une petite recherche sur google avec "module vs shared class" tu trouveras plein d'article sur ces questions.

P.S. : Ca c'est du fameux UP

[Jean-Marie Grave]

Bonjour.

Propreté n'est pas soumission aveugle. Utilisez un module chaque fois que vous avez une bonne raison de le faire. Autrement faites des classes (majoritairement). Au passage, notez que les sub et les fonctions existent dans les classes, en ce sens qu'elles s'écrivent exactement de la même manière que lorsqu'elles sont dans des modules.

Je sens que je vais me faire excommunier.

Cordialement.

[AlainTech]

Merci pour les réponses mais (c'est probablement moi qui suis obtus) elles ne m'aident pas beaucoup.

J'ai commencé un livre sur les Design Patterns me disant que ça m'éclairerait sur les classes autres que "objets réels" (un client, un fichier, un bâtiment, ...) telles que les Interfaces et... je n'y ai rien compris.

Je ne désespère pas de découvrir, quelque part, des exemples de codes implémentant des Interfaces et autres classes abstraites...

[Sankasssss]

Il est vrais qu'au début ce n'est vraiment pas évident de comprendre les avantages de l'orienté objet. Mais une fois qu'on commence à découvrir et comprendre les différentes possibilités, notamment avec les design Patterns, on en revient pas de la puissance que cela apporte.
L'avantage que j'ai eu en apprenant l'orienté objet, c'est que je l'ai fait avec mon prof de Java qui nous montrait des exemples concret venant directement de l'implémentation de Java, et avec ce dernier on peut voir le code des classes du framework que l'on utilise.
On peut aussi le voir en .net dans l'aide MSDNmais sans les sources. Si tu vas voir le composant textBox, tu verras que ce composant est une class qui hérite d'un tas d'autres class qui remonte jusqu’à la class object qui est la base de toutes les class :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
System.Object 
  System.Windows.Threading.DispatcherObject
    System.Windows.DependencyObject
      System.Windows.Media.Visual
        System.Windows.UIElement
          System.Windows.FrameworkElement
            System.Windows.Controls.Control
              System.Windows.Controls.Primitives.TextBoxBase
                System.Windows.Controls.TextBox
                  System.Windows.Controls.Primitives.DatePickerTextBox
                    System.Windows.Controls.Ribbon.RibbonTextBox

Cela veut donc dire qu'il a toutes les méthodes / fonctions et propriétés des class héritées mais qu'il est en plus capable de rajouter son comportement sur certaine de ses fonctions dont il hérite et en plus il peut avoir de nouvelles méthodes propre à lui que d'autre class pourront hérité de lui.

Il est important de savoir qu'on ne peut hériter que d'une seul class mais qu'en revenche on peut implémenter autant d'interface que l'on veut.

Pour les interfaces, si on regarde la déclaration de FrameworkElement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
'Déclaration
<RuntimeNamePropertyAttribute("Name")> _
<UsableDuringInitializationAttribute(True)> _
<StyleTypedPropertyAttribute(Property := "FocusVisualStyle", StyleTargetType := GetType(Control))> _
<XmlLangPropertyAttribute("Language")> _
Public Class FrameworkElement _
	Inherits UIElement _
	Implements IFrameworkInputElement, IInputElement, ISupportInitialize, IQueryAmbient

On peut voir qu'il implémente plusieurs interface car ces dernières ne contiennent pas de directement du code, elles obligent simplement la class à implémenter sa définition, c'est une sorte de contrat. Cela permet de s'assurer que la class qui l'implémente à bien ces méthodes / propriété et donc si on déclare une variable du type de l'interface, on a accès uniquement à ces méthodes / propriété de l'interface. Comme cela on dirait que c'est restrictif, mais ça permet de recevoir n'importe quelle objet qui implémente l'interface dans cette variable.

Cela doit rester flou pour voir comment on peut employer cela j'en convient

Je te conseille deux bons livres qui m'ont bien aidé à comprendre ces mécanismes qui font partie de la collection "Tête la première" :

• Analyse et conception orientées objet — Tête la première : Critique de dvp
• Tête la première Design patterns : Critique de dvp

Avantage de cette collection :

Là où je ne tiens pas 10 minutes après une longue journée éprouvante, je me suis surpris à lire jusqu'à 1 heure ce livre sans me déconcentrer ou perdre le fil.

Bienvenu dans le magnifique monde de Object ville

[AlainTech]

Grand merci pour les liens.

Je m'y plongerai dès que j'en aurai fini avec une application en cours.

Elle sera "mal" codée mais, au moins, elle tourne correctement.