Ocultar la complejidad mediante la construcción de bibliotecas concisas

Question

Estoy desarrollando un producto con un montón de piezas entrelazadas (servidor, cliente, bibliotecas, etc.) y una de las piezas es una pequeña biblioteca que los usuarios vincularán en su propio código del lado del cliente (algo así como Flickr API o la API de Google Maps). Una vez que han incluido esa biblioteca, todos los bits entrelazados se enganchan mágicamente. Entonces, la simplicidad de la API es un objetivo importante e importante.

La API que expongo a los usuarios tiene un total de dos clases y siete métodos públicos. Fácil guisante, exprimido de limón.

Pero la simplicidad es una ilusión cuidadosamente elaborada. La biblioteca que estoy distribuyendo en realidad depende de otra biblioteca, con 136 clases propias (y más de mil métodos públicos). Durante el proceso de compilación, vinculo las dos bibliotecas en un solo entregable, para facilitar la integración y la implementación por parte del consumidor de API.

El problema al que me enfrento ahora es que no quiero que el usuario final (un desarrollador de aplicaciones que integra mi software para mejorar su propia funcionalidad) se moleste con todo ese problema adicional, ahogándose en un torrente de complejidad innecesaria .

Desde el exterior, la biblioteca debería parecer que contiene exactamente dos clases públicas, con exactamente siete métodos públicos.

¿Cómo manejas este tipo de cosas en tus propios proyectos? Estoy interesado en las soluciones agnósticas de idiomas, así como en las diversas técnicas para diferentes idiomas, compiladores y herramientas de compilación.

En mi caso específico, estoy desarrollando para la plataforma flash (AIR / Flex / Actionscript) con archivos de biblioteca SWC. La metodología de compilación es análoga a la plataforma Java, donde todas las clases se agrupan en un módulo de código comprimido con igual visibilidad (un archivo SWC de Actionscript es, conceptualmente, casi exactamente idéntico a un archivo JAR de Java).

¿No tiene .NET un " interno " modificador para clases y métodos? Ese es exactamente el tipo de cosas que estoy buscando, y si alguien sabe de una técnica complicada para ocultar la visibilidad de las clases entre los límites de SWC, me encantaría escucharla.

Answer 1

Es bastante difícil ocultar cosas en AS. Hay un especificador de acceso interno y también hay espacios de nombres. Adobe tiene ayuda en Paquetes y nombres que pueden ser> útil para usted.

Es importante tener en cuenta que los espacios de nombres no limitan el acceso; realmente se utilizan para colocar símbolos en un espacio de nombres diferente ... bueno. Esto podría usarse para tener 2 versiones de la misma biblioteca accedidas en el mismo swf. Supongo que solo hace algunos cambios de nombre detrás de escena antes de insertar definiciones en la tabla de símbolos. Si los usuarios lo desean, pueden importar el espacio de nombres y acceder a cualquier cosa que esté "oculta" Detrás de eso. Lo hice al cortar componentes de Adobe. Dicho esto, si el usuario no tiene la fuente original y no puede determinar el identificador del espacio de nombres, entonces tiene un poco de seguridad a través de la oscuridad.

Los

especificadores de acceso a paquetes (por ejemplo, privados e internos) están más cerca de lo que desea. Pero si usted puede acceder a clases fuera de los límites del paquete, entonces el usuario también puede hacerlo. Incluso hay trucos que he visto alrededor que pueden examinar un swfc y escupir una lista de clases incrustadas en las que uno puede usar getClassByDefinition para crear instancias.

Por lo tanto, puede ocultar la existencia de clases en su documentación, usar especificadores de acceso interno y privado siempre que sea posible y luego usar espacios de nombres para alterar los nombres de clase. Pero no puede evitar que una persona determinada encuentre y use estas clases.

Answer 2

Creo que puedes lograr esto usando espacios de nombres: http: //livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000040.html

Observe que los espacios de nombres no son los mismos en actionscript que en C #, es más como espacios de nombres en xml.

Answer 3

Por cierto, uno de los otros trucos que he usado (ya que no sabía sobre el modificador interno o los espacios de nombres) es ocultar clases declarándolas fuera del paquete actual, así:

package com.example {

   public class A {
      // ...
   }

}

class B {
   // ...
}

class C {
   // ...
}

Aunque he pensado en escribir una pequeña herramienta que analizará toda la "importación" directivas dentro de un proyecto y mover todas las dependencias externas a este tipo de clases privadas ocultas.