Nascondere la complessità costruendo librerie concise

Question

Sto sviluppando un prodotto con un sacco di pezzi interconnessi (server, client, librerie, ecc.) e uno dei pezzi è una piccola libreria che gli utenti collegheranno al proprio codice lato client (qualcosa di simile al API di Flickr o API di Google Maps). Una volta inclusa quella libreria, tutti i bit di interblocco si agganciano magicamente. Quindi la semplicità dell'API è un obiettivo importante, importante.

L'API che espongo agli utenti ha un totale complessivo di due classi e sette metodi pubblici. Facile, pestato al limone.

Ma la semplicità è un'illusione accuratamente realizzata. La biblioteca che sto distribuendo in realtà dipende da un'altra biblioteca, con 136 classi proprie (e più di un migliaio di metodi pubblici). Durante il processo di creazione, collego le due librerie insieme in un unico deliverable, per facilitare l'integrazione e la distribuzione da parte del consumatore dell'API.

Il problema che sto affrontando ora è che non voglio che l'utente finale (uno sviluppatore di applicazioni che integra il mio software per migliorare le proprie funzionalità) sia mai infastidito da tutta quella extra cruft, affogando in un torrente di complessità non necessaria .

Dall'esterno, la libreria dovrebbe apparire come se contenesse esattamente due classi pubbliche, con esattamente sette metodi pubblici.

Come gestisci questo genere di cose nei tuoi progetti? Sono interessato alle soluzioni agnostiche di lingua, nonché alle varie tecniche per diverse lingue, compilatori e strumenti di costruzione.

Nel mio caso specifico, sto sviluppando per la piattaforma flash (AIR / Flex / Actionscript) con file di libreria SWC. La metodologia di compilazione è analoga alla piattaforma Java, in cui tutte le classi sono raggruppate in un modulo di codice zippato con uguale visibilità (un file SWC di Actionscript è, concettualmente, quasi identico a un file JAR Java).

.NET non ha un " interno " modificatore di classi e metodi? Questo è esattamente il tipo di cosa che sto cercando, e se qualcuno conosce una tecnica complicata per nascondere la visibilità delle classi tra i confini SWC, mi piacerebbe ascoltarlo.

Answer 1

È abbastanza difficile nascondere le cose in AS. C'è un identificatore di accesso interno e ci sono anche spazi dei nomi. Adobe ha qualche aiuto su Pacchetti e nomi che p utile a te.

È importante notare che gli spazi dei nomi non limitano l'accesso: sono davvero utilizzati per posizionare i simboli in uno spazio dei nomi diverso ... bene. Questo potrebbe essere usato per avere 2 versioni della stessa libreria accessibili nello stesso swf. La mia ipotesi è che faccia solo un po 'di manomissione dietro le quinte prima di inserire definizioni nella tabella dei simboli. Se gli utenti lo desiderano, possono semplicemente importare lo spazio dei nomi e accedere a tutto ciò che è "nascosto". Dietro. L'ho fatto quando ho fatto a pezzi i componenti Adobe. Detto questo, se l'utente non ha la fonte originale ed è incapace di determinare l'identificatore dello spazio dei nomi di quanto tu abbia un po 'di sicurezza attraverso l'oscurità.

Gli identificatori di accesso al pacchetto (ad es. privati ??e interni) sono più vicini a ciò che si desidera. Ma se tu riesci ad accedere alle classi al di fuori dei limiti del pacchetto, anche utente può farlo. Ci sono persino hack che ho visto in giro che possono esaminare un file swfc e sputare un elenco di classi incorporate che è possibile utilizzare getClassByDefinition per istanziare.

Quindi, puoi nascondere l'esistenza delle classi nella tua documentazione, utilizzare gli identificatori di accesso interno e privato ove possibile e quindi utilizzare gli spazi dei nomi per manipolare i nomi delle classi. Ma non puoi impedire a una persona determinata di trovare e utilizzare queste classi.

Answer 2

Penso che puoi farlo usando gli spazi dei nomi: http: //livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000040.html

Si noti che gli spazi dei nomi non sono gli stessi in ActionScript come in C #, è più simile agli spazi dei nomi in XML.

Answer 3

Per inciso, uno degli altri trucchi che ho usato (dal momento che non sapevo del modificatore o degli spazi dei nomi "interni") è nascondere le classi dichiarandole al di fuori del pacchetto corrente, in questo modo:

package com.example {

   public class A {
      // ...
   }

}

class B {
   // ...
}

class C {
   // ...
}

Ho anche pensato di scrivere un piccolo strumento che analizzerà tutto il "import" direttive all'interno di un progetto e spostare tutte le dipendenze esterne in questo tipo di classi private nascoste.