Сокрытие сложности путем создания кратких библиотек

Question

Я разрабатываю продукт с кучей взаимосвязанных частей (сервер, клиент, библиотеки и т. Д.), И одна из частей - это крошечная библиотека, которую пользователи будут связывать в свой собственный код на стороне клиента (что-то вроде Flickr API или Google Maps API). Как только они включили эту библиотеку, все взаимосвязанные биты волшебным образом сцепляются друг с другом. Так что простота API - это важная и важная задача.

API, который я предоставляю пользователям, состоит из двух классов и семи открытых методов. Легкая гороховая, лимонно-отжимная.

Но простота - тщательно продуманная иллюзия. Библиотека, которую я распространяю, на самом деле зависит от другой библиотеки, имеющей 136 собственных классов (и более тысячи открытых методов). В процессе сборки я связываю две библиотеки в один конечный результат для упрощения интеграции и развертывания потребителем API.

Проблема, с которой я сейчас сталкиваюсь, заключается в том, что я не хочу, чтобы конечный пользователь (разработчик приложений, интегрирующий мое программное обеспечение для улучшения своей собственной функциональности) когда-либо беспокоился обо всех этих дополнительных затратах, тонущих в потоке ненужной сложности. .

Снаружи библиотека должна выглядеть так, как будто она содержит ровно два открытых класса, с ровно семью открытыми методами.

Как вы справляетесь с подобными вещами в своих собственных проектах? Меня интересуют независимые от языка решения, а также различные методы для разных языков, компиляторы и инструменты сборки.

В моем конкретном случае я разрабатываю для флеш-платформы (AIR / Flex / Actionscript) файлы библиотеки SWC. Методология сборки аналогична платформе Java, где все классы объединены в модуль с заархивированным кодом с одинаковой видимостью (SWC-файл Actionscript, концептуально, практически идентичен Java JAR-файлу).

Разве .NET не имеет "внутреннего" модификатора для классов и методов? Это именно то, что я ищу, и если кто-нибудь знает хитрую технику, чтобы скрыть видимость классов между границами SWC, я бы хотел это услышать.

Answer 1

Довольно сложно спрятать вещи в AS. Существует внутренний спецификатор доступа, а также есть пространства имен. Adobe имеет некоторую справку по пакетам и пространствам имен , которая может быть вам полезна.

Важно отметить, что пространства имен не ограничивают доступ - они действительно используются для помещения символов в другое ... ну пространство имен. Это можно использовать для доступа к 2 версиям одной и той же библиотеки в одном SWF. Я предполагаю, что он просто делает некоторые манипуляции с именами за кулисами, прежде чем вставлять определения в таблицу символов. Если пользователи хотят, они могут просто импортировать пространство имен и получить доступ ко всему, что «скрыто» за ним. Я сделал это, когда взломал компоненты Adobe. Тем не менее, если у пользователя нет исходного источника и он не способен определить идентификатор пространства имен, тогда у вас есть некоторая безопасность благодаря неясности.

Спецификаторы доступа к пакету (например, приватный и внутренний) ближе к тому, что вы хотите. Но если вы можете получить доступ к классам за пределами пакета, то пользователь также может. Я даже видел некоторые хаки, которые могут проверить swfc и выложить список встроенных классов, которые можно использовать для создания экземпляра getClassByDefinition.

Таким образом, вы можете скрыть существование классов в своей документации, по возможности использовать внутренние и частные спецификаторы доступа, а затем использовать пространства имен для искажения имен классов. Но вы не можете помешать определенному человеку найти и использовать эти классы.

Answer 2

Я думаю, что вы можете осуществить это, используя пространства имен: http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000040.html

Обратите внимание, что пространства имен не совпадают в ActionScript с C #, это больше похоже на пространства имен в XML.

Answer 3

Кстати, один из других приемов, которые я использовал (поскольку я не знал о «внутреннем» модификаторе или пространствах имен), - это скрыть классы, объявив их вне текущего пакета, например:

package com.example {

   public class A {
      // ...
   }

}

class B {
   // ...
}

class C {
   // ...
}

Я даже написал о небольшом инструменте, который будет анализировать все директивы import в проекте и перемещать все внешние зависимости в такие скрытые частные классы.