Сокрытие сложности путем создания кратких библиотек
-
10-07-2019 - |
Вопрос
Я разрабатываю продукт с кучей взаимосвязанных частей (сервер, клиент, библиотеки и т. д.), и одна из частей - это крошечная библиотека, которую пользователи будут связывать в свой собственный код на стороне клиента (что-то вроде Flickr API или Google Maps API). Как только они включили эту библиотеку, все взаимосвязанные биты волшебным образом сцепляются друг с другом. Так что простота API - это важная и важная задача.
API, который я предоставляю пользователям, состоит из двух классов и семи открытых методов. Легко гороховый, лимонно-отжимной.
Но простота - тщательно продуманная иллюзия. Библиотека, которую я распространяю, на самом деле зависит от другой библиотеки, имеющей 136 собственных классов (и более тысячи открытых методов). В процессе сборки я связываю две библиотеки в один конечный результат для упрощения интеграции и развертывания потребителем API.
Проблема, с которой я сейчас сталкиваюсь, заключается в том, что я не хочу, чтобы конечный пользователь (разработчик приложений, интегрирующий мое программное обеспечение для улучшения своей собственной функциональности) когда-либо беспокоился обо всех этих лишних затратах, тонущих в потоке ненужной сложности. . р>
Внешне библиотека должна выглядеть так, как если бы она содержала ровно два открытых класса и ровно семь открытых методов.
Как вы справляетесь с подобными вещами в своих собственных проектах? Меня интересуют независимые от языка решения, а также различные методы для разных языков, компиляторы и инструменты сборки.
В моем конкретном случае я разрабатываю для флеш-платформы (AIR / Flex / Actionscript) файлы библиотеки SWC. Методология сборки аналогична платформе Java, где все классы объединены в модуль с заархивированным кодом с одинаковой видимостью (SWC-файл Actionscript, концептуально, практически идентичен Java JAR-файлу).
.NET не имеет " внутреннего " модификатор для классов и методов? Это именно то, что я ищу, и если кто-нибудь знает хитрую технику, чтобы скрыть видимость классов между границами SWC, я бы хотел это услышать.
Решение
Довольно сложно спрятать вещи в AS. Существует внутренний спецификатор доступа, а также есть пространства имен. Adobe имеет некоторую помощь по именам и именам пакетов полезно для вас.
Важно отметить, что пространства имен не ограничивают доступ - они действительно используются для помещения символов в другое ... ну пространство имен. Это можно использовать для доступа к 2 версиям одной и той же библиотеки в одном SWF. Я предполагаю, что он просто делает некоторые манипуляции с именами за кулисами, прежде чем вставлять определения в таблицу символов. Если пользователи хотят, они могут просто импортировать пространство имен и получить доступ ко всему, что "скрыто". за этим. Я сделал это, когда взломал компоненты Adobe. Тем не менее, если у пользователя нет исходного источника и он не способен определить идентификатор пространства имен, тогда у вас есть некоторая безопасность благодаря неясности.
Спецификаторы доступа к пакету (например, приватный и внутренний) ближе к тому, что вы хотите. Но если вы можете получить доступ к классам за пределами пакета, то пользователь тоже может. Я даже видел некоторые хаки, которые могут проверить swfc и выложить список встроенных классов, для создания которых можно использовать getClassByDefinition.
Таким образом, вы можете скрыть существование классов в своей документации, по возможности использовать внутренние и частные спецификаторы доступа, а затем использовать пространства имен для искажения имен классов. Но вы не можете помешать определенному человеку найти и использовать эти классы.
Другие советы
Я думаю, что вы можете осуществить это, используя пространства имен: http: //livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000040.html р>
Обратите внимание, что пространства имен не совпадают в ActionScript с C #, это больше похоже на пространства имен в XML.
Между прочим, один из других приемов, которые я использовал (поскольку я не знал о модификаторе или внутренних пространствах имен), - это скрыть классы, объявив их вне текущего пакета, например так:
package com.example {
public class A {
// ...
}
}
class B {
// ...
}
class C {
// ...
}
Я даже написал о небольшом инструменте, который будет анализировать весь " импорт " директивы внутри проекта и перемещают все внешние зависимости в такие скрытые частные классы.