Quand est abstraction et modularisation une mauvaise pratique dans la programmation?

Question

juste vu ce commentaire dans un sondage « ce que JS lib utilisez-vous »

"@ Xanti - oui, oui, la modularisation et l'abstraction dans la programmation est une terrible pratique des fonctions qui appellent d'autres fonctions gaspilleur.?".

Et qui me reste curieux parce que je suis en utilisant le framework Kohana pour PHP et la bibliothèque JQuery pour javascript.

Pourquoi certaines personnes considèrent l'abstraction et modularisation mauvaises pratiques? Ne sont pas des cadres et des bibliothèques prises pour faciliter et accélérer le développement?

Voici un lien de rel="noreferrer"> le sondage

Answer 1

J'ai trouvé que l'abstraction trop peut être dangereux pour votre productivité:

• Une abstraction mal choisie peut être pire que pas une abstraction du tout.

• Si vous avez besoin de lire quatre ou cinq modules différents afin de comprendre comment un simple algorithme fonctionne, les barrières d'abstraction ne sont probablement pas dans les bons endroits. Peut-être il y a une bonne façon de factoriser le code, ou peut-être il serait plus facile de supprimer les barrières.

• Si l'abstraction ne correspond pas à une idée relativement familière, il peut être difficile pour les nouveaux membres de l'équipe d'apprendre.

L'abstraction est pas une « bonne sans esprit »; il existe pour servir à des fins spécifiques. Parmi les besoins les plus courants sont

• protéger les invariants d'une structure de données

• les décisions de conception encapsuler qui sont susceptibles de changer

Ma plus grande expérience avec l'abstraction de prendre le chemin était avec notre compilateur de recherche pour C-- . Il y avait beaucoup plus abstraction que les étudiants ont été habitués à voir dans la classe du compilateur:

• La machine cible était abstraite
• Le langage assembleur était abstrait
• Les conventions d'appel étaient abstraits
• La mise en page pile-cadre a utilisé un "bloc" inhabituel abstraction

Chacune de ces abstractions ont servi un objectif important pour notre recherche, mais l'effet total était qu'il était très difficile pour les nouveaux élèves à apprendre le compilateur. Donc, même si le commentaire original était en plaisantant, il sont endroits où l'abstraction peut causer des problèmes.

Answer 2

Lorsque vous travaillez sur des ressources limitées, il peut facilement ajouter les frais généraux.

Bien sûr, il y a des choses compilateur va optimiser loin, mais si vous créez quatre objets dans quatre fichiers soignées .c soignées, les compilent quatre fichiers .so soignées puis de les relier avec un éditeur de liens muet, les appels de fonction inter-module qui pourrait être facilement inline sont toujours faites avec plein décharge de l'Etat, des pièces qui pourraient être optimisés disparaître entièrement sont encore exécutés, et ainsi de suite.

Je vous assure que si vous commencez à programmer un microcontrôleur PIC 8 bits avec 4 Ko de RAM et 16K Flash en utilisant les meilleures pratiques des langages orientés objet, en utilisant des modèles de conception avancés et la création de plus d'une couche d'abstraction, votre programme ne fonctionnera jamais. « L'optimisation prématurée est une racine de tous les maux » a été dit par un gars qui n'a jamais programmé pour une plate-forme qui a 128 octets de RAM.

Answer 3

On peut sans doute supposer l'intervenant était pas grave.

Je ne peux pas imaginer que quelqu'un prétendant modularisation et l'abstraction sont mauvaises pratiques et le sens réellement.

Answer 4

abstraction et modularisation en général sont bons et essentiels. Il pourrait y avoir de mauvaises abstractions là-bas, par exemple: les cadres qui ne sont pas pris en charge plus ou coûteux ou tout simplement pas utilisable, ou grand, ou pas à jour, ou 2ème choix, et ainsi de suite. La bibliothèque « marché » en général est énorme. Quel type de bibliothèques que vous vous trouvez à l'aide dépend des circonstances et de préférence personnelle.

  

Pourquoi certaines personnes considèrent l'abstraction et modularisation mauvaises pratiques? Ne sont pas des cadres et   bibliothèques prises pour faciliter et accélérer le développement?

Le changement et l'apprentissage est parfois difficile - pour que les gens se battre. Si vous souhaitez étudier ce genre, vous pouvez commencer votre recherche à: http://thedailywtf.com/ : - ) Je voudrais juste les ignorer et utiliser des bibliothèques et des cadres comme ils vous servir et rendre votre vie meilleure programmeur.

Answer 5

Un développeur prétendra qu'une abstraction ou modularisation est une mauvaise pratique quand ils sont en mesure ou besoin d'interagir avec ladite abstraction ou modularisation et sont incapables de comprendre son objet ou design.

Answer 6

Lorsque toutes les fonctions (et les fonctions d'aide) est dans son propre module?

Answer 7

Il était calme, mais il y a quelque temps un manuel pour un compilateur Fortran recommandé de choisir des identificateurs comme des chaînes de la même longueur et des lettres choisies au hasard.

Explication? et il permet une distribution uniforme des noms dans le Hashtable du compilateur interne et à cause de cela prévoit une compilation plus rapide.

Je pense que le texte que vous citez appartient juste à côté de cette recommandation

Answer 8

Les bonnes abstractions sont souvent utilisés

Les bonnes abstractions sont référencées à 2 ou plusieurs endroits dans votre logiciel.

Exemples:

• Fonctions à partir de 2 sites appel.
• Résumé de classe à partir de 2 classes concrètes.
• Interfaces à partir de 2 implémentations.
• Generics à partir de 2 instanciations
• Les bibliothèques à partir de 2 utilisateurs.
• etc.

Une abstraction qui est référencé à 2 ou plusieurs endroits contribue à réduire la taille du code, par l'affacturage les choses communes, ce qui est une bonne chose.

Mais si vous avez beaucoup d'abstractions qui sont référencées seulement une seule fois, puis il est une bonne chance que l'abstraction est pas nécessaire.

Voici quelques exemples où les abstractions inutiles viennent:

• Objet d'écriture du code heureux (interfaces et classes abstraites partout ayant seulement 1 mise en œuvre ou concrétion). Ces interfaces et classes abstraites ne sont pas nécessaires (à ce moment du développement). principe YAGNI.
• Quelqu'un construit une interface « brillante nouvelle » sur l'ancien, où les nouvelles fonctions après une conversion appel que l'ancienne interface. Vous pouvez imaginer ce qu'est un grand désordre est le résultat, si vous répétez cette opération plusieurs fois. Dans ce cas, les anciennes fonctions auront un seul site d'appel, donc ils ne sont pas nécessaires. Vous devez déplacer le code des anciennes fonctions dans la nouvelle ou ne pas écrire un nouveau et modifier l'ancien.

Voici quelques exemples d'abstractions vraiment bien:

• couche d'abstraction matérielle: fournit une interface unique pour les applications afin qu'ils ne ont pas besoin de développer un code pour chaque type de matériel
.
• Système de fichiers: Peu importe que vous utilisez FAT, NTFS, EXT3 tout. Il vous permet d'utiliser des fichiers et des répertoires, le pilote du système de fichiers fait le reste.
• Langue C: Vous n'avez pas besoin de transférer votre programme pour chaque architecture CPU. Il suffit de le compiler.

Donc, pour répondre à votre question de façon pragmatique: Abstractions sont mauvaises, quand ils sont référencés de moins de 2 places

.

En ce qui concerne la modularisation, son subjective: vous pouvez organiser votre code tout ce que vous voulez. Si le code source de votre bibliothèque est dans un seul fichier source, il ne fait pas pire que si vous mettez exploser plusieurs centaines de fichiers.

Évaluation de vos abstractions comme bonnes ou mauvaises, toujours considérer la grande image:. L'ensemble du projet, toute la gamme de produits, etc