Masquer la complexité en construisant des bibliothèques concises

Question

Je développe un produit avec un ensemble de composants imbriqués (serveur, client, bibliothèques, etc.). L’un des composants est une bibliothèque minuscule que les utilisateurs lieront dans leur propre code côté client (un peu comme le API Flickr ou Google Maps). Une fois la bibliothèque incluse, tous les bits imbriqués s’accrochent comme par magie. La simplicité des API est donc un objectif majeur et important.

L'API que j'expose aux utilisateurs comprend un total de deux classes et sept méthodes publiques. Peasy facile, citron-squeezy.

Mais la simplicité est une illusion soigneusement conçue. La bibliothèque que je distribue dépend en fait d'une autre bibliothèque, avec 136 classes (et plus de mille méthodes publiques). Pendant le processus de construction, je relie les deux bibliothèques en un seul produit livrable, ce qui facilite l'intégration et le déploiement par le consommateur d'API.

Le problème auquel je suis confronté à présent est que je ne veux pas que l'utilisateur final (un développeur d'applications intégrant mon logiciel pour améliorer ses propres fonctionnalités) soit dérangé par tout ce qui est cruel, noyé dans un torrent de complexité inutile. .

De l'extérieur, la bibliothèque devrait avoir l’impression de contenir exactement deux classes publiques, avec exactement sept méthodes publiques.

Comment gérez-vous ce genre de chose dans vos propres projets? Je suis intéressé par les solutions agnostiques de langage, ainsi que par les différentes techniques pour différents langages, compilateurs et outils de construction.

Dans mon cas particulier, je développe pour la plate-forme Flash (AIR / Flex / Actionscript) avec des fichiers de bibliothèque SWC. La méthodologie de construction est analogue à celle de la plate-forme Java, où toutes les classes sont regroupées dans un module de code zippé avec une visibilité égale (un fichier SWC Actionscript est, sur le plan conceptuel, presque identique à un fichier JAR Java).

Le .NET n’a-t-il pas un "interne"? modificateur pour les classes et les méthodes? C’est exactement le genre de chose que je recherche, et si quelqu'un connaissait une technique délicate pour masquer la visibilité des classes entre les frontières de SWC, je serais ravi de l'entendre.

Answer 1

Il est assez difficile de cacher des choses en AS. Il existe un spécificateur d'accès interne et des espaces de noms. Adobe a de l'aide sur pseudonymes et de paquets utile pour vous.

Il est important de noter que les espaces de noms ne limitent pas l'accès. Ils sont vraiment utilisés pour placer des symboles dans un autre espace de noms. Cela pourrait être utilisé pour avoir 2 versions de la même bibliothèque accédées dans le même swf. J'imagine qu'il faut simplement modifier les noms en coulisses avant d'insérer des définitions dans la table des symboles. Si les utilisateurs le souhaitent, ils peuvent simplement importer l'espace de noms et accéder à tout ce qui est "masqué". derrière. Je l'ai fait lors du piratage des composants Adobe. Cela dit, si l'utilisateur ne dispose pas de la source d'origine et est incapable de déterminer l'identificateur d'espace de nom, vous disposez d'un peu de sécurité grâce à l'obscurité.

Les spécificateurs d'accès aux packages (par exemple, private et internal) sont plus proches de ce que vous souhaitez. Mais si vous pouvez accéder aux classes en dehors des limites d'un paquet, l'utilisateur peut également le faire. Il y a même des hacks que j'ai vus qui peuvent examiner un swfc et cracher une liste de classes incorporées que l'on peut utiliser getClassByDefinition pour instancier.

Vous pouvez donc masquer l'existence des classes dans votre documentation, utiliser des spécificateurs d'accès internes et privés autant que possible, puis utiliser des espaces de noms pour modifier les noms de classe. Mais vous ne pouvez pas empêcher une personne déterminée de trouver et d’utiliser ces classes.

Answer 2

Je pense que vous pouvez résoudre ce problème en utilisant des espaces de noms: http: //livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000040.html

Notez que les espaces de noms ne sont pas les mêmes en actionscript et en C #, ils ressemblent davantage à des espaces de noms en xml.

Answer 3

Incidemment, une des autres astuces que j'ai utilisées (étant donné que je ne connaissais pas le modificateur "interne" ou les espaces de noms) consiste à masquer des classes en les déclarant en dehors du package actuel, comme ceci:

package com.example {

   public class A {
      // ...
   }

}

class B {
   // ...
}

class C {
   // ...
}

J'ai quand même écrit un petit outil qui analysera tous les " importations " directives dans un projet et déplacez toutes les dépendances externes vers ces types de classes privées masquées.