2

私は連動する部品 (サーバー、クライアント、ライブラリなど) を多数備えた製品を開発しています。そのうちの 1 つは、ユーザーが独自のクライアント側コード (Flickr API のようなもの) にリンクする小さなライブラリです。 Google マップ API)。そのライブラリを組み込むと、連動するすべてのビットが魔法のように接続されます。したがって、API の簡素化は主要かつ重要な目標です。

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

しかし、そのシンプルさは注意深く作られた幻想です。私が配布しているライブラリは、実際には別のライブラリに依存しており、独自の 136 のクラス (および 1000 以上のパブリック メソッド) があります。ビルド プロセス中に、API コンシューマによる統合と展開を容易にするために、2 つのライブラリを 1 つの成果物にリンクします。

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

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

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

私の特定のケースでは、SWC ライブラリ ファイルを使用してフラッシュ プラットフォーム (AIR/Flex/Actionscript) 用に開発しています。ビルド方法は Java プラットフォームに類似しており、すべてのクラスが同じ可視性を持つ zip コード モジュールにバンドルされています (Actionscript SWC ファイルは、概念的には Java JAR ファイルとほぼ同じです)。

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

4

3 に答える 3

1

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

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

パッケージ アクセス指定子 (private や internal など) は、必要なものに近いものです。ただし、パッケージの境界外のクラスにアクセスできる場合は、ユーザーアクセスできます。swfc を調べて、getClassByDefinition を使用してインスタンス化できる組み込みクラスのリストを吐き出すことができる、私が見たハックさえあります。

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

于 2009-08-03T12:16:42.857 に答える
1

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

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

于 2009-08-02T10:21:16.657 に答える
0

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

package com.example {

   public class A {
      // ...
   }

}

class B {
   // ...
}

class C {
   // ...
}

プロジェクト内のすべての「インポート」ディレクティブを分析し、すべての外部依存関係をこれらの種類の非表示のプライベート クラスに移動する小さなツールを作成することも検討しました。

于 2009-08-03T15:30:37.513 に答える