2

私は自分のJSライブラリを構築しています。
ライブラリは、主にブラウザの違いを解消するために役立つ、小さな独立したモジュールと、少し大きいユーティリティで構成する必要があるという考え方です。
乾いたままでいるのか、ゆるく結合しているのかを判断できないため、何かを成し遂げるのに苦労しています。

例？与えられた：

  • テンプレートからdom要素を生成する処理を行う小さなライブラリ
  • ダックタイピングの問題を処理するもう1つの問題（is_function、is_array ...）
  • そして最後にモーダルボックスを作成します。最後のものが必要です：
    • いくつかのタイプチェック
    • テンプレートライブラリの1つの関数のみを使用してモーダルを作成します

モーダルボックスライブラリの私のオプション：

  1. 100％乾燥し、他の2つのライブラリに依存します。ただし、モーダルボックスライブラリのみをダウンロードしたいユーザーの場合は、他の2つで作成する必要があります。
  2. ユーザーが開始時にオプションのオブジェクトを渡して、必要な機能を指定できるようにします。デフォルトではライブラリの1つになります。これは優れていますが、実際には、90％の場合、同じシグネチャで関数を作成するのは面倒なので、提供されているライブラリを使用することを意味します。さらに、モーダルボックスコードが複雑になります。
  3. 100％緩く、モーダルボックスライブラリに必要な機能を再現します。よりターゲットを絞っており、エッジケースをチェックする必要がないため、おそらくより効率的です。ただし、バグは2か所で修正する必要があり、ダウンロードサイズが大きくなります。

ですから、私は2つの極端な状況の間で振動する時間を無駄にし、100万回リファクタリングし、決して満足することはありません。
もっと一般的な質問をしようとしていましたが、サイズとパフォーマンスの問題、および広範な使用法のために、それが本当にJSに関係していることに気付きました。

そのような場合に従うべき既知のパターンはありますか？これについて受け入れられている方法は何ですか？どんな考えでも大歓迎です。

[編集：]
これは私の懸念を詳しく説明していると私が見つけた唯一の記事です。記事が言うように、

DRYは重要ですが、[...]低結合度と高凝集度も重要です。[...]すべての[原則]を考慮に入れ、それぞれの状況でそれらの相対的な価値を比較検討する必要があります

私はこの状況でそれらの価値を比較検討することができないと思います。

4

2 に答える 2

3

個人的には、 LooseCouplingはコードに継ぎ目を作成することを指しているという見方を常に取っています。Javaなどの古典言語では、これは具体的な実装を隠すインターフェースを作成することによって実現されます。これは、開発者がアプリケーションの「継ぎ目を選択解除」し、具体的な実装をモックとテストダブル（または実際には独自の実装）に置き換えることができるため、強力な概念です。JavaScriptは動的言語であるため、開発者はインターフェイスではなくダックタイピングに依存しています。何も凍結されていないため、すべてのオブジェクトがコードの継ぎ目になり、置き換えることができます。

あなたの質問に直接答えると、コードをより小さなライブラリに分解してモジュール化することを常に目指すことは、利益をもたらすと思います。コードの繰り返しを避けるだけでなく（多くの理由から良い考えではありません）、ライブラリの一部のみを再利用したい他の開発者による再利用を奨励します。

車輪の再発明をする代わりに、そこにあるより人気のあるJavaScriptライブラリのいくつかを活用してみませんか。たとえば、underscore.jsは、ダックタイプのチェック用の豊富なツールキットを提供する軽量ライブラリであり、Mustache.jsがテンプレートのニーズに対応している可能性があります。

多くの既存のプロジェクトはすでにこのアプローチを使用しています。たとえば、Backbone.jsはunderscore.jsに依存し、jQueryMobileはjQueryに依存しています。RequireJSなどのツールを使用すると、アプリケーションのjavascriptの依存関係を簡単に一覧表示して解決でき、すべてのseparate.jsファイルを単一の縮小されたリソースに結合するために使用することもできます。

于 2012-08-15T13:21:40.397 に答える
1

私はDRYの概念が好きですが、あなたの権利にはいくつかの問題があります。

  1. エンドユーザー開発者は、コンポーネントの依存関係をダウンロードする必要があることを知っておく必要があります。

  2. エンドユーザー開発者は、依存関係（つまり、渡すオプション）を構成する必要があることを知っている必要があります。

1.解決に役立てるために、プロジェクトのWebサイトでダウンロードをその場でカスタマイズできるため、コアコードがオプションのコンポーネントとともにダウンロードされます。モダナイザーのダウンロードページのように。

解決に役立つ2.ユーザーがオプションを渡すことを許可するのではなく、適切なデフォルトを使用して、パッケージのどの部分がブラウザーにロードされているかを検出し、それらを自動的に結び付けます。この緩い結合は、ユーザーがすでにサードパーティのフレームワークをインストールしている場合にもサードパーティのフレームワークに依存する可能性があるという大きな利点をもたらす可能性もあります。たとえば、selectivizrを使用すると、ブラウザにすでにロードされているものに応じて、jqueryやdojoなどを使用できます。

おそらく、requirejsを使用して依存関係の管理を解決することができます。ライブラリが直接使用することを意図しているのではなく、代わりにエンドユーザー開発者が使用することを意図しているという印象を受けます...しかし、それはぴったりかもしれません。

私の答えはあなたの質問に直接答えるものではないことを私は理解していますが、おそらくそれはDRYのいくつかの欠点のバランスをとるのに役立つかもしれません。

于 2012-08-15T13:19:49.027 に答える