Discussion :

[Paul TOTH]

Le lien entre objet et fonction évite d'avoir à lire toute les fonctions mais qui n'ont rien avoir. Quand je veux Sauvegarder l'objet/structure Eleve , c'est une perte de temps de devoir lire SaveProf, SaveClasse, LoadClasse,LoadProf,... c'est quand même plus pratique d'avoir tout mis dans le fichier Eleve.c que d'avoir MaLib.c avec 500 méthodes dedans


1) Pour une plus grand clarté et lisibilité.
Perso quand je tombe sur des fonctions de 1000 lignes et que je dois parcourir tout pour essayer de trouver le bug, je préferent nettement quand ces 1000 lignes soit découpés sans compter que je dois essayer de déchivrer les requetes SQL pour savoir ce qu'elle font

c'est une des raisons pour lesquelles j'aime le langage Pascal. les unités Pascal sont un source qui comprend une partie Interface (grosso modo un .h mais sans code) et une Implementation (le .c). Tout ce qui est dans l'Interface est public, tout ce qui est dans l'implementation est privé.

Code pascal :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
unit Eleve;
 
interface // partie publique
 
procedure Save; // prototype de la fonction publique
 
var
  Note: Integer; // variable publique
 
implementation // partie privée
 
var
  Chose: Integer; // variable privée
 
procedure SaveProf; // procédure privée
begin
...
end;
 
procedure SaveClass; // idem
begin
...
end;
 
procedure Save; // implémentation de la procédure publique
begin
  SaveProf;
  SaveClasse;
...
end;
 
end.

en fait c'est très proche d'une classe static comme on peut les faire en Java

Code Java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
public class Eleve {
 
  public static int Note;
 
   public static Save() {
    ...
  }
 
  private static int Chose;
 
  private static SaveProf() {
    ...
  }
 
  private static SaveClasse() {
   ...
  }
}

ceci dit en C on se contentera de lire le .h qui s'il est bien écrit ne reprendra que Save ... ou Eleve_Save pour éviter un problème de collision qu'on n'aura pas en Pascal puisque l'unité constitue un espace de nom : Eleve.Save.

[psykokarl]

Le lien entre objet et fonction évite d'avoir à lire toute les fonctions mais qui n'ont rien avoir. Quand je veux Sauvegarder l'objet/structure Eleve , c'est une perte de temps de devoir lire SaveProf, SaveClasse, LoadClasse,LoadProf,... c'est quand même plus pratique d'avoir tout mis dans le fichier Eleve.c que d'avoir MaLib.c avec 500 méthodes dedans

Ce sont la des questions d'organisation de code qui transcendent la question du paradigme: le choix du nom de méthode ou de classe, le classement des méthodes par ordre alphabétique, par fonctionnalités, par type de données manipulées, etc.
La qualité de la documentation est primordiale et c'est souvent la que tout se joue.

1) Pour une plus grand clarté et lisibilité.
Perso quand je tombe sur des fonctions de 1000 lignes et que je dois parcourir tout pour essayer de trouver le bug, je préferent nettement quand ces 1000 lignes soit découpés sans compter que je dois essayer de déchivrer les requetes SQL pour savoir ce qu'elle font

Disons qu'il n'est pas plus compliqué de chercher un bug dans un fichier de 1000 lignes que dans 10 fichiers de 100 lignes voir 100 fichiers de 10 lignes.
Je force le trait pour l'exemple mais c'est pour montrer que découper pour découper est contreproductif il faut qu'il y a de la pertinence derrière chaque découpage.

[BenoitM]

Ce sont la des questions d'organisation de code qui transcendent la question du paradigme: le choix du nom de méthode ou de classe, le classement des méthodes par ordre alphabétique, par fonctionnalités, par type de données manipulées, etc.
La qualité de la documentation est primordiale et c'est souvent la que tout se joue.


Disons qu'il n'est pas plus compliqué de chercher un bug dans un fichier de 1000 lignes que dans 10 fichiers de 100 lignes voir 100 fichiers de 10 lignes.
Je force le trait pour l'exemple mais c'est pour montrer que découper pour découper est contreproductif il faut qu'il y a de la pertinence derrière chaque découpage.

Perso je préfere chercher dans 10 fichiers de 100 lignes qui me permet de lancer les 10 fonctions et devoir laquelle pause problème plutot que du faire du step by step de mettre des breakpoint aléatoirement pour essayer de trouver la ligne de code qui explose tout.
De plus je pense que si tu fais du bon procédurale tu auras plus où moins la même découpe.
L'avantage de la POO c'est vu que tu dois relier logiquement tes fonctions à un objets tu seras plus contraint à mieux découper tes programmes qu'en procédurale.
Mais rien n'empeche dans les 2 cas de faire des méthodes de 1000 lignes en mono block...

[MiaowZedong]

Disons qu'il n'est pas plus compliqué de chercher un bug dans un fichier de 1000 lignes que dans 10 fichiers de 100 lignes voir 100 fichiers de 10 lignes.
Je force le trait pour l'exemple mais c'est pour montrer que découper pour découper est contreproductif il faut qu'il y a de la pertinence derrière chaque découpage.

Un énorme +1

J'appelle ça le code mosaïque, parce que je commence à chercher ce que fait vraiment trois lignes de code, et je me retrouve avec des dizaines de fenêtres ouvertes qui font une mosaïque imbuvable à l'écran.....

C'est le code spaghetti 2.0, découpé en objets mais toujours aussi inmaintenable.

[disedorgue]

Bonjour,

En fait, je ne comprends pas trop le sujet: un développeur ne doit-il pas connaitre tous les concept de programmation (OO,imperatif,fonctionnel,...) ?

La première chose à comprendre pour un futur développeur est l'algorithmique (trouver les différentes taches "unitaire" à effectuer pour résoudre un problème donné) et ceci est le plus difficile à apprendre à quelqu'un (surtout au début).
Après le langage que l'on utilise derrière n'est qu'un support...

[sekaijin]

Je ne remettrais surement pas en cause ce qui marche.

le sujet est que la POO n'est pas toujours la panacée pas plus d'ailleurs que ce que tu considères comme incontournable c'est à dire découper le problème pour résoudre des tâche unitaire.

Même si la POO et l'algorithmique sont des techniques qui on fait leur preuve il en existe d'autre. et mal heureusement cette popularité poussée à outrance masque des voies qui pourraient s'avérer plus prometteuses.

La question est donc en fait doit-on revoir la façon dont on enseigne et appréhende l'informatique.

Les anglais utilise le terme de computer science qui à l'avantage de remonter au source c'est à dire la théorie de la calculabilité dont est directement issue l'algorithmique. mais il existe ben d'autre approche de la calculabilité. certaines sont étonnantes, d'autre séduisante. bref il y a bien d'autre façon de programmer un ordinateur.

A+JYT