簡潔なライブラリを構築して複雑さを隠す

Question

多数の連動部分（サーバー、クライアント、ライブラリなど）を備えた製品を開発していますが、その1つは、ユーザーが独自のクライアント側コード（のようなもの）にリンクする小さなライブラリですFlickr APIまたはGoogle Maps API）。それらがそのライブラリをインクルードすると、インターロックビットのすべてが魔法のように互いにフックします。したがって、APIのシンプルさは主要な重要な目標です。

ユーザーに公開するAPIには、合計2つのクラスと7つのパブリックメソッドがあります。簡単に、レモンを絞る。

しかし、シンプルさは入念に作られた錯覚です。私が実際に配布しているライブラリは、独自の136クラス（および1000以上のパブリックメソッド）を持つ別のライブラリに依存しています。ビルドプロセス中に、APIコンシューマーによる統合と展開を容易にするために、2つのライブラリを単一の成果物にリンクします。

私が今直面している問題は、エンドユーザー（ソフトウェアを統合して独自の機能を強化するアプリケーション開発者）が余分な問題に悩まされ、不要な複雑さでdrれたくないことです。 。

外部から見ると、ライブラリはちょうど2つのパブリッククラスとちょうど7つのパブリックメソッドを含むように見えるはずです。

この種のことを自分のプロジェクトでどのように処理しますか？言語にとらわれないソリューションと、さまざまな言語、コンパイラ、ビルドツールのさまざまな手法に興味があります。

特定のケースでは、SWCライブラリファイルを使用してフラッシュプラットフォーム（AIR / Flex / Actionscript）向けに開発しています。ビルド方法論は、すべてのクラスが同等の可視性を備えた圧縮されたコードモジュールにバンドルされるJavaプラットフォームに類似しています（Actionscript SWCファイルは、概念的にはJava JARファイルとほぼ同一です）。

.NETには「内部」がありません;クラスとメソッドの修飾子？それはまさに私が探している種類のものであり、SWC境界の間にクラスの可視性を隠すトリッキーなテクニックを知っている人がいたら、それを聞きたいです。

Answer 1

ASで物事を隠すのはかなり難しいです。内部アクセス指定子があり、名前空間もあります。アドビは、パッケージと名前空間に関するヘルプを提供しています。あなたに役立つ。

名前空間はアクセスを制限しないことに注意することが重要です-それらはシンボルを別の名前空間に配置するために実際に使用されます。これを使用すると、同じswfで同じライブラリの2つのバージョンにアクセスできます。私の推測では、シンボルテーブルに定義を挿入する前に、舞台裏で名前をマングルするだけです。ユーザーは、名前空間をインポートして、「非表示」になっているものにアクセスできます。その背後。アドビのコンポーネントを個別にハックするときにそれをやった。つまり、ユーザーが元のソースを持たず、名前空間識別子を決定できない場合は、あいまいさによるセキュリティが少しあります。

パッケージアクセス指定子（プライベートおよび内部など）は、必要なものに近くなります。ただし、あなたがパッケージ境界外のクラスにアクセスできる場合、ユーザーもアクセスできます。 swfcを調べて、getClassByDefinitionを使用してインスタンス化できる埋め込みクラスのリストを吐き出すことができるハックもあります。

したがって、ドキュメント内のクラスの存在を非表示にし、可能な限り内部およびプライベートアクセス指定子を使用してから、名前空間を使用してクラス名をマングルできます。しかし、決心した人がこれらのクラスを見つけて使用するのを防ぐことはできません。

Answer 2

名前空間を使用してこれを実現できると思います： http： //livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000040.html

名前空間はC＃のactionscriptと同じではなく、xmlの名前空間に似ていることに注意してください。

Answer 3

ちなみに、（＆quot;内部＆quot;修飾子または名前空間について知らなかったので）私が使用した他のトリックの1つは、次のように現在のパッケージの外側でクラスを宣言することでクラスを非表示にすることです：

package com.example {

   public class A {
      // ...
   }

}

class B {
   // ...
}

class C {
   // ...
}

すべての＆quot; import＆quot;を分析する小さなツールを書くことについても、プロジェクト内のディレクティブを作成し、すべての外部依存関係をこれらの種類の非表示のプライベートクラスに移動します。