Comment les cours vous aident-ils à gérer de grandes applications?

Question

Cela est venu dans une conversation que j'avais en ligne et je me suis dit que je ne comprenais pas comment cela était supposé fonctionner: bon nombre de programmeurs semblent prendre pour acquis - il est évident que les cours sont une fonctionnalité linguistique nécessaire à la gestion de gros projets logiciels.

Ce n'est pas évident pour moi comment ils font cela.

Ma question est la suivante: comment le savez-vous? Quelles sont les mesures objectives qui montrent que les classes augmentent la productivité, la réutilisation de code et réduisent la complexité de la production d'un programme? Quels sont les aspects des cours qui les rendent idéales pour la collaboration de grandes équipes?

Et maintenant, il y a une question que j'aimerais poser, qui est un peu difficile à exprimer. Je suis désolé si je me trompe et que je finis par semer la confusion ou la colère de quiconque:

Objectivement, comment savez-vous que l'utilisation de classes n'est pas la cause de la grande taille de l'application? C'est-à-dire, est-il possible qu'un programme ayant une fonction équivalente ait été écrit, avec beaucoup moins de code, suffisamment petit pour ne nécessiter aucune mesure spéciale pour "gérer" le, en utilisant une autre stratégie de réutilisation de code? (Il y a beaucoup de choix, comme ceux dans les paradigmes de programmation fonctionnels ou la programmation orientée aspect).

Steve Yegge a fait allusion à ce dernier commentaire sur son blog. Mais je suis un peu sceptique quant aux deux côtés de l'argument, en raison d'un manque réel de données concrètes de la part de qui que ce soit, et du manque d'expérience pour pouvoir conclure seul.

Qu'en pensez-vous?

edit: En particulier, beaucoup de programmeurs pensent que l’héritage de style prototypique n’est pas à la hauteur de la tâche quand il s’agit d’applications volumineuses. Je suis désolé de cette question est vague - c'est un produit de mon manque de compréhension sur ce sujet.

edit2: il semble y avoir une certaine confusion quant à ce que je veux dire par programmation fonctionnelle. (Je ne pense pas qu'aucune version de VB ait jamais été fonctionnelle, certainement pas les anciennes versions). Veuillez vous référer à l'article de Wikipedia. http://fr.wikipedia.org/wiki/Functional_programming

edit3: et laissez-moi souligner le fait que je recherche des mesures objectives. Pas d'avis subjectif.

Answer 1

La théorie de l'encapsulation fournit une raison objective pour laquelle les classes sont meilleures que de ne pas en avoir du tout.

L’Organisation internationale de normalisation définit l’encapsulation comme étant 'La propriété selon laquelle les informations contenues dans un objet ne sont accessibles que par le biais d’interactions aux interfaces prises en charge par l’objet.'

Ainsi, certaines informations étant accessibles via ces interfaces, certaines informations doivent être cachées et inaccessibles dans l’objet. La propriété que de telles informations présentent s'appelle masquer des informations, ce que Parnas a défini en faisant valoir que les modules devraient être conçus de manière à masquer les décisions difficiles à prendre et les décisions susceptibles de changer.

Notez ce mot: changez. La dissimulation d'informations concerne des événements potentiels, tels que le changement de décisions de conception difficiles à l'avenir.

Considérez une classe avec deux méthodes: la méthode a (), qui est une information cachée dans la classe, et la méthode b (), qui est publique et donc directement accessible aux autres classes.

Il existe une certaine probabilité qu’une modification future de la méthode a () nécessite des modifications de méthodes dans d’autres classes. Il existe également une certaine probabilité qu'un changement futur de la méthode b () nécessite des changements de méthodes dans les autres classes. La probabilité que de tels changements se produisent pour la méthode a () sera toutefois généralement inférieure à celle de la méthode b () simplement parce que la méthode b () peut être dépendante d'un plus grand nombre de classes.

Cette probabilité réduite d’impacts sur les ondulations est l’un des principaux avantages de l’encapsulation.

Considérez le nombre potentiel maximal de dépendances de code source (MPE - l'acronyme provient de la théorie des graphes) dans tout programme. En extrapolant les définitions ci-dessus, nous pouvons dire que, étant donné que deux programmes offrant des fonctionnalités identiques aux utilisateurs, le programme dont le MPE est le plus bas est mieux encapsulé et que, statistiquement, le programme le mieux encapsulé sera moins coûteux à maintenir et à développer, car le coût de la modification potentielle maximale sera inférieure à la modification potentielle maximale du système moins bien encapsulé.

Envisagez en outre un langage avec juste des méthodes et pas de classes et donc pas de moyen de cacher des méthodes les unes aux autres. Disons que notre programme a 1000 méthodes. Quel est le MPE de ce programme?

La théorie de l'encapsulation nous dit que, dans un système de n nœuds publics, le MPE de ce système est n (n-1). Ainsi, le MPE de nos 1000 méthodes publiques est de 999 000.

Divisons maintenant ce système en deux classes de 500 méthodes chacune. Comme nous avons maintenant des classes, nous pouvons choisir d’avoir certaines méthodes publiques et d’autres privées. Ce sera le cas à moins que chaque méthode ne dépende en réalité de toute autre méthode (ce qui est peu probable). Disons que 50 méthodes dans chaque classe sont publiques. Quel serait le MPE du système?

La théorie de l'encapsulation nous dit que: n ((n / r) -1 + (r-1) p) où r est le nombre de classes et p le nombre de méthodes publiques par classe. Cela donnerait à notre système à deux classes un MPE de 499 000. Ainsi, le coût potentiel maximum d’une modification de ce système à deux classes est déjà nettement inférieur à celui du système non encapsulé.

Supposons que vous divisiez votre système en 3 classes, chacune comprenant 333 classes (l'une d'elles en aura 334), et à nouveau chacune avec 50 méthodes publiques. Quel est le MPE? En utilisant à nouveau l'équation ci-dessus, le MPE serait d'environ 482 000.

Si le système est divisé en 4 classes de 250 méthodes chacune, le MPE sera de 449 000.

Si l’on peut penser que l’augmentation du nombre de classes de notre système diminuera toujours son MPE, mais ce n’est pas le cas. La théorie de l'encapsulation montre que le nombre de classes dans lesquelles le système doit être décomposé pour minimiser l'EMP est le suivant: r = sqrt (n / p), ce qui pour notre système est en réalité de 4. Un système & # 233; m avec 6 classes, par exemple, aurait un M

Answer 2

C'est une très bonne question. Organiser le code en classes est un moyen pour une équipe de développement de créer de petits modules réutilisables. De plus, ces modules ont des interfaces expressives et limitées qui n'expriment que ce dont la classe est capable et non comment elle le fait. Chaque classe est orthogonale aux autres et est donc hautement testable et modulaire en cas d’erreur.

Maintenant, ce que je viens de décrire est une scène étrange d’un monde parfait. Mais tout bon développeur qui travaille dans le domaine de la programmation orientée objet doit s’efforcer de parvenir à un résultat similaire.

La POO est une reconnaissance du fait que nous, les développeurs, sommes simplement humains et ne pouvons pas comprendre un système entier à la fois. Nous divisons donc le système en minuscules pièces réutilisables et nous nous concentrons sur celles-ci.

Prenons l'exemple d'un numéro de téléphone américain à dix chiffres. Il est difficile de se rappeler un nombre à dix chiffres dans votre tête, nous faisons donc ce que les psychologues appellent "chunking". Cela signifie que nous décomposons mentalement les nombres en morceaux dont nous pouvons mieux nous souvenir.

Donc, 1234567890 devient 123-456-7890 . Heureusement pour nous, les compagnies de téléphone décomposent également ces numéros de la même manière et attribuent la signification aux morceaux. 123 est l'indicatif régional, 456 est le préfixe et 7890 est le numéro de la ligne. Chacun de ces morceaux est comme une classe, ils ont tous des responsabilités individuelles, des formats et des significations.

En conclusion, la meilleure chose que je puisse dire est que la POO nous permet de construire de grands systèmes évolutifs dotés de fonctionnalités centralisées et encapsulées. Cela nous permet de ne pas avoir à voir la situation dans son ensemble tout le temps et de pouvoir nous concentrer sur une chose et la bien faire.

Answer 3

Je ne suis nullement partisan de tout paradigme de programmation, mais je fonctionne de manière OO depuis un certain temps.

Personnellement, j'ai eu beaucoup de 'a-HA!' Les moments que les cours m'ont directement aidés à comprendre le domaine dans lequel je travaille mieux.

Plus particulièrement, dans les cas où il existe une confusion quant à la raison pour laquelle un système fonctionne mal ou ce qu’un système est censé faire, les classes m’ont souvent obligé à réfléchir à ce que cet élément distinct de l’ensemble devrait être en train de faire, et plus souvent. que ne conduisent pas à refactoriser les classes / méthodes sous la main.

En bref, l’encapsulation fait de moi une personne plus heureuse. ;)

L’espoir que cela aide.

Answer 4

Je pense que les classes peuvent aider, car elles correspondent au concept cognitif très général de la la catégorisation . et peut donc aider à décrire naturellement les grandes applications.

Answer 5

Je préfère les cours pour pouvoir diviser un gros problème en éléments faciles à gérer et testables individuellement. IMHO, la réutilisation de code est surestimée - je l’ai à peine vue arriver là où je travaille. Pour moi, ce que je tire le plus d'un bon OO, c'est une bonne testabilité.

L'autre extrême consiste à utiliser un ensemble de variables globales et à brouiller toute votre logique dans public static void main (ou Page_Load dans ASP.NET) et à appeler des méthodes statiques. cet appel d'autres méthodes statiques et ainsi de suite ... (Je suis étourdi à la fin de la dernière phrase.)

Si je travaillais avec un langage purement fonctionnel, la seule chose qui briserait mon mentalité d'OO serait de ne pas y penser depuis la fin de mes études, malheureusement.

Answer 6

Il est probablement possible de sur-résoudre un problème simple en le rendant inutilement complexe (OO tout en bas). Cependant, pour un problème suffisamment important, je ne pense pas qu'il soit probable que le paradigme OO soit à l'origine de sa taille. Prenons un système d’exploitation, par exemple, il est difficile d’imaginer qu’il est facile à gérer (au niveau du code) s’il n’est pas écrit de manière orientée objet.

Answer 7

Si vous avez un groupe de " nus " fonctions dans une grande application, il est difficile d’apporter des modifications à ces fonctions.

• plus difficile de voir qui utilise la fonction ("si je change cela, qui est concerné?")
• difficile de modifier les fonctions sans casser le code d'autrui.

Si vous encapsulez les fonctions dans des classes, vous aiderez à isoler la portée du code. Ce n'est pas une solution miracle, mais ça aide.

Answer 8

Deux choses.

La première est l'idée qu'une classe est une entité de domaine opaque . Une fois cela fait correctement , les programmes orientés objet introduisent une couche d'abstraction: au niveau suivant, vous organisez les objets pour qu'ils fassent ce que vous voulez, plutôt que de traiter avec des détails. Vous n'avez pas besoin de savoir comment fonctionnent les objets et les classes: seulement ce qu'ils font. C’est une sorte de dissimulation d’informations qui réduit la complexité qu’une équipe doit garder à l’esprit pendant le travail.

La seconde est que la programmation OO permet un type de réutilisation de code: vous pouvez définir des classes qui surchargent certains comportements dans d’autres classes (héritage), ou des classes dont les instances incluent des instances d’autres classes, en les utilisant pour atteindre leurs objectifs (encapsulation). et composition).

Utiliser correctement les techniques OO peut réduire la quantité de code que vous devez gérer et le nombre d'éléments à prendre en compte lors de votre travail ou de la maintenance du système. En pratique, cette approche ne fonctionne pas toujours.

Answer 9

  

Objectivement, comment savez-vous que le   l'utilisation de classes n'est pas la cause de la   demande étant grande pour commencer?

Prenez n'importe quel programme / application volumineux qui n'a pas été écrit dans un langage OO (par exemple, C, COBOL, même en SQL simple) et vous devriez être en mesure de constater que la taille du code n'est pas directement attribuée au paradigme du langage. Pour chaque nombre de composants C # ou Java réutilisables bien conçus et hautement raffinés, il existe également un nombre égal de DLL C réutilisables bien conçus et hautement raffinés. Inversement, il y a un nombre égal de codes horribles et gonflés.

Le fait est que de bons programmeurs sont en mesure d’affiner la conception de leurs systèmes indépendamment de la langue / de la plate-forme.

En ce qui concerne la POO, du moins pour moi, cela apporte à la table un "potentiel" - une vision du monde de la programmation un peu plus proche de notre monde réel. Nous connaissons tous notre monde et cet univers de la matière regorge d’objets composés d’objets plus petits . Continuez à effectuer des zooms depuis les systèmes étoiles galatiques jusqu’à la molécule, l’atome et les particules subatomiques, il est vraiment étonnant de constater à quel point la matière est très différente de la même manière, combinées de manière très différente. Regardez notre propre biologie même, il est parfois ahurissant de penser que 60% de notre corps est en réalité juste de l'eau lorsqu'il est décomposé au mieux. Pourtant, regardez tous les différents systèmes et organes en place qui brûlent de chimie pour nous maintenir en vie et continuer à fonctionner.

Lorsque nous apprendrons à comprendre la simplicité (oh vraiment ... ha ha) des éléments constitutifs des systèmes du monde réel que nous observons dans la nature quotidienne, nous devrions alors être en mesure de comprendre que concevoir et construire Les systèmes compliqués ou sophistiqués doivent commencer avec de petits composants qui ne font que très peu eux-mêmes. Et en les combinant lentement et en les combinant dans des composants toujours plus volumineux, nous pouvons obtenir plus de fonctionnalités et de capacités. Jusqu'à ce que nous atteignions le système souhaité, nous avions envisagé.

L’utilisation (correcte) des classes est de décomposer un système en son meilleur. Comme possible. Pour que vous puissiez regarder quelque chose à la fois et à un niveau d'abstraction particulier sans vous laisser submerger par des buts et une logique qui ne traitent pas de votre sujet de préoccupation actuel. Chaque fois que vous concevez un système, pensez à votre propre anatomie; Pensez comment vous concevriez le corps humain. Chaque fois que vous concevez un système, pensez à démarrer une nouvelle société ; Quelles sont les principales divisions, les départements dont vous avez besoin pour exploiter votre entreprise? Qui sont le type de personnel requis pour gérer ces départements. Les divers équipements dont ils ont besoin pour utiliser et interagir avec eux. Comment divisez-vous les activités de votre entreprise pour mieux la comprendre?

Lorsque vous comprendrez le principe de base selon lequel un objet est simplement constitué d'objets plus petits, vous êtes sur le point de créer des cellules ou des molécules hautement réutilisables.

Answer 10

Les cours m'ont été très utiles car je peux travailler simultanément sur un petit aspect d'un projet complexe. Pouvoir découpler un aspect du code du grand projet est très utile pour ne pas être submergé. Au final, la cohésion entre ces classes peut vous donner un aperçu rapide du fonctionnement d’un programme sans avoir à vous soucier des entrailles.

En ce qui concerne la maintenabilité, il est beaucoup plus facile de regarder un diagramme de classes UML et de comprendre comment tout est présenté que de consulter une liste de fonctions, à mon avis.

Answer 11

Je pense qu'en disant classes, vous devriez parler d'objets. Les classes ne sont rien d'autre qu'un lieu où vous pouvez insérer vos objets. Le paradigme de la POO a tant de succès pour une raison. Une fois que vous avez ce 'aha!' Au moment où vous pensez avoir enfin compris le concept de la programmation orientée objet, vous pouvez commencer à programmer de manière beaucoup plus organisée.

Je suis programmé depuis longtemps dans Visual Basic 3, donc j’avais beaucoup d’expérience en programmation fonctionnelle, puis venir à VB5 et découvrir des objets était un immense soulagement, car je pouvais relier des entités réelles à mon code, et cela a beaucoup aidé.

C’est l’essentiel, recréer des entités du monde réel dans votre code. Cela facilite la lecture et le travail, car vous pouvez ramasser quelque chose et le manipuler.